By the end of the weekend, most of it was gone. Coordinated free-trial abuse had burned through the credits.

The painful part was that our internal guardrail bot had noticed the pattern. It could gather the evidence and tell us that something looked wrong. It simply did not have a safe path to act.

I am Bobb Kim, co-founder of Runbear. This is our account of the incident and the gap we found in our internal guardrail workflow.

The signup graph looked like growth

A few days earlier, we had made our trial easier to start. We removed the upfront credit-card requirement and reduced the number of steps between signup and a working product.

That was intentional. We wanted legitimate teams to reach a working evaluation quickly, without adding a card or extra verification up front.

Then signups jumped to about 30 times their normal level.

For a few minutes, the dashboard looked great. Signups were up. Usage was up. The trial appeared to be working.

Then we looked at the accounts more closely.

This was not growth. It was farming.

A promotion had become an abuse playbook

A Runbear trial link had been shared in an online community. It was not presented as a product to evaluate. It was presented as a way to farm access to paid AI models.

The trial was being shared as a source of credits rather than as a product evaluation.

Some people created fake business identities, worked around basic checks, and submitted prompts that were clearly outside the spirit of the trial. Once the instructions spread, new accounts arrived in waves.

A stream of subscription events initially resembled a successful acquisition spike.

We did not want to make the trial painful again for every legitimate team. The useful problem was narrower: keep the happy path open for real evaluators while making coordinated farming difficult to scale.

Our guardrail bot had already noticed

We were not starting from zero. An internal guardrail bot was already watching for suspicious new organizations and usage patterns.

It could:

• identify odd signup patterns,

• collect the relevant evidence,

• summarize why new users looked suspicious, and

• put that evidence in front of the team.

That saved time. A person did not have to begin with raw logs and reconstruct the incident manually.

But the bot stopped at detection.

The internal report reduced the investigation work, but it did not yet provide a complete response workflow.

It could say, "These new users look suspicious." It could not apply a response rule, block a high-confidence case, escalate an ambiguous one, or leave a report trail for the decision.

So it waited for a human to wake up.

Credit farmers did not.

By the time we paused trials and banned the obvious farming accounts, they had consumed around $1,000 in credits. That was almost exactly the amount of Anthropic credits we had just received for placing third in the hackathon.

Winning credits and then immediately losing them was not the launch story we had planned.

Detection and response are different systems

The incident exposed a distinction that dashboards tend to hide.

Time to detection mattered, but time to action was the expensive metric. In an abuse incident, every minute between those two stages can have a dollar value.

That does not mean every anomaly detector should be allowed to ban users. A false positive can block a real buyer and damage trust. The system needed two paths:

1. High-confidence cases could follow a narrowly defined response rule.

2. Ambiguous cases had to be escalated with enough context for a person to decide quickly.

The automation boundary was not "let the bot decide everything." It was "do not make a human repeat work that the system can perform safely and explain."

The response workflow we added

We used Runbear to convert the guardrail from a reporting step into a scoped response workflow:

1. Detect suspicious organizations and usage patterns.

2. Gather and summarize the supporting evidence.

3. Apply the current response rule.

4. Block high-confidence abuse.

5. Escalate uncertain cases to the team.

6. Leave a report trail showing what happened.

The useful change was operational, not magical: a rule the team already understood became a workflow with clear actions, escalation, and review.

When the farming pattern changes, we can update the response rule without changing the broader detect, escalate, act, and review loop.

After the blocks started working, we saw messages in abuse channels saying that the method no longer worked overnight.

The response was visible from the other side: the farming path had stopped working.

Someone even joked that because the community had promoted us, we should pay them. I respected the audacity. I did not respect the invoice.

What we would do differently

The credits were already gone, but the incident changed how we think about operational agents.

1. Treat response latency as part of the threat model

A detector that produces a good summary overnight is helpful. If nobody can safely act on it until morning, the delay is still part of the system.

2. Define the automation boundary before the incident

The middle of an abuse spike is a bad time to decide which evidence is sufficient for a block, which action is reversible, and which cases require a person. Those rules should exist before the alert fires.

3. Preserve the evidence and the action

A response needs more than a final account status. The team should be able to see what signals were used, which rule applied, what action occurred, and which cases were escalated.

4. Do not punish legitimate users for the easiest control

Adding friction everywhere would have reduced abuse. It also would have made the trial worse for every real team. The better control targeted coordinated farming while keeping the intended evaluation path open.

The lesson we kept

If a product offers free trials, usage credits, or access to expensive AI models, abuse prevention cannot be only a dashboard someone checks later.

Detection matters. But detection without a path to action is still a delay, and that delay has a cost.

I do not think every bot should be free to swing a ban hammer. I do think a carefully scoped operator can verify known signals, execute conservative rules, escalate edge cases, and preserve an audit trail while the team sleeps.

That incident is now part of how we design Runbear. The goal is not to replace judgment. It is to turn clear operational rules into fast, reviewable action while reserving ambiguous cases for people.

Losing our hackathon credits was an expensive way to learn that lesson.

Originally published on the Runbear blog.