Back to Blog
Tai Tran 8 min read

Token Spend Is a Potential Signal for a Rogue Agent

Token Spend Is a Potential Signal for a Rogue Agent

Now in Public Preview

Certiv Cost is now in public preview. See abnormal token usage, set budgets, and protect against runaway sessions.

Token consumption is one of the first surprises organizations run into as they put AI agents into production. Sometimes the cause is ordinary: a user burns through an allocation, or a workload costs more than expected. Other times it’s harder to see. An agent heads down the wrong rabbit hole and keeps going. It doesn’t crash or fail authentication. It simply keeps doing what it was allowed to do, consuming tokens for hours or days before anyone notices.

That’s why we built Certiv Cost: visibility into all of your agents’ token spend, and the budgets that protect against runaway sessions.

Unpredictable agents are why token visibility and budgets matter

Traditional software is fairly predictable. A function costs what it costs. If your spend doubles overnight, someone probably deployed something.

Agents don’t work that way. Give one the same task twice and it may take two different paths, make a different number of tool calls, or use a very different amount of context. That variability is part of what makes agents useful. It’s also why cost is no longer purely an accounting problem.

Customers tell us the same thing: they know their agent spend is growing, but not which part is real work and which part is an agent that stopped doing anything useful a week ago.

When an agent operates outside what it was meant to do, consumption may be the first sign your team notices. Not always, and not by itself: a spike can just as easily mean someone gave the agent a harder problem. Certiv Cost shows the spend, who generated it, when, and how it changed, so your team can spot unusual usage and decide whether it’s worth investigating.

Different root causes leave the same consumption pattern

High-token-usage scenarios usually get sorted into two buckets: operational incidents and security attacks. In the usage data, they can look identical. What separates them is the root cause, and that’s exactly what you often can’t see at runtime.

Runaway agent loops can burn budget without tripping a conventional control. An agent hits an API error it doesn’t recognize. With no backoff strategy, it retries, and keeps retrying. Over a weekend, an agent with no stopping condition can burn a meaningful chunk of a monthly budget while doing nothing but failing. An attacker who can influence its inputs can force the same loop on purpose: a denial-of-wallet attack, with no downtime, no availability alert, just a bill weeks later.

Context bloat makes every action more expensive. A long-running agent never trims its context window, so every turn carries the full history of every turn before it. The task hasn’t gotten harder, but the cost per action keeps climbing. Injected instructions create the same pattern by widening what the agent does: read more, call more tools, pull more context.

Unfamiliar consumption can expose orphaned agents or compromised keys. Someone builds an agent, schedules it, and leaves the company. It keeps running, keeps consuming, keeps holding credentials, and nobody owns it. Or an API key leaks: the key is valid, so the requests are valid, and nothing fails authentication. What you see is consumption at the wrong hours, against the wrong model, or at the wrong volume.

You can’t reliably tell intent from consumption alone. Certiv Cost makes usage visible and lets you cap how far it can go while your team investigates.

Runaway spend can become an availability incident

It’s easy to file this under budget overrun. A large invoice is painful, but it gets absorbed. The harder part: replacing the tokens a runaway agent consumed means buying more capacity just to finish what you already planned.

Tokens are also a shared, finite resource. When one runaway agent eats the capacity you provisioned, it’s spending the budget your legitimate agents needed. Rate limits get hit. Quotas run out. Requests start failing for everyone on the account.

At that point a cost problem has become an availability problem. Your engineers can’t ship. Your support agents can’t respond. Your incident response tooling, increasingly agentic itself, may be degraded right when you need it most. One agent stuck in a retry loop can take down every other agent sharing that quota, with no attacker involved.

That’s why both notification and enforcement matter. A notification buys time to investigate while work continues. A blocking budget stops future prompts at the endpoint before a runaway session drains the pool.

Complete visibility and budgets turn consumption into a control

Certiv Cost brings four capabilities together.

Session-level attribution shows where every token was spent

Token usage is tracked over time, broken out by model, and attributed down to the agent session: which agent, on which endpoint, under which user, against which model. The per-model view matters, since usage and pricing vary substantially across models.

Certiv Cost overview: total spend and monthly run rate for the last seven days, a per-model cost trend, and total cost by model split across input and output tokens

Historical trend shows how consumption changes over time. Certiv Cost presents the data; your team decides what level of spend is appropriate for each environment.

Certiv Cost breakdown: spend per endpoint, expanded to show every provider and model behind the endpoint's total

Budgets protect shared capacity from runaway sessions

Set a dollar budget per endpoint, over the period that fits how you operate, and decide what happens when it’s reached:

  • Report: the overage is recorded and shows up in reporting. No alert, no interruption.
  • Notify: alerts fire, work continues. The right default while you’re learning how your teams use tokens.
  • Block: future prompts are stopped at the endpoint, before the request ever leaves.

Enforcement happens at the endpoint rather than in a downstream report, so blocking really blocks. The prompt doesn’t go out.

A per-endpoint ceiling is also how you contain blast radius: it keeps one misbehaving agent from eating the capacity everyone else needs. Using historical usage, you can simulate how often an endpoint would have hit a proposed budget, which makes a practical threshold easier to pick before you enforce it.

Creating a budget in Certiv Cost: a weekly dollar cap scoped to each endpoint, with an Impact panel replaying six weeks of history to show how many endpoint-weeks would have landed under, at warn, or over

Contract-accurate rates keep thresholds trustworthy

List pricing is not what most organizations pay. If you’ve negotiated rates with a model provider, Certiv Cost lets you enter those rates per model, so usage is priced using what you actually pay.

That sounds like an accounting detail. It isn’t. If your thresholds are computed against list pricing but you pay something else, your ceilings are wrong, and a threshold that fires at the wrong number is worse than none: people learn to ignore it.

End users see their own spend in Scout

Cost visibility isn’t just for administrators. Scout shows each user their own consumption on their own endpoint, broken out by hour, so the person actually running the agents can see what they cost.

That matters for how quickly a runaway session gets caught. The engineer who kicked off an agent is usually the first to notice that an ordinary task has turned into an unusual bill, and they don’t need to file a ticket to find out.

Scout's Usage view: spend per hour for a single endpoint over two days, with the total token count and dollar spend for the period

Unbounded API consumption is where the security risk lives

One deliberate scoping decision: Certiv Cost is built for API-based usage, not seat-based plans.

Seat licenses have a natural ceiling: you buy a fixed number and pay for that number. The worst case is wasted spend on unused seats, which is a procurement problem, not a runaway-agent problem.

API consumption has no natural ceiling. It’s metered, it’s unbounded, and an agent caught in a loop at night keeps going until something stops it. If your agents call model APIs directly, this is built for you.

Attribution lets you rebalance capacity before buying more

Most organizations hand out token budgets evenly, having no basis for anything else. Some people hit the ceiling constantly and ask for more; others never get close. Without per-user visibility, the only response to a heavy user is to buy more capacity.

Per-session and per-user attribution changes that. If a third of your allocations are consistently underused, the first move isn’t procurement, it’s rebalancing what you own: take headroom from users who never approach their limit and give it to the ones doing the work.

It’s a simple tactic, and it can cut spend. But it’s a side effect of the visibility and control we built to stop agents that run long after they should.

Start with budget notifications, then enforce the limits that matter

We’d suggest starting in notify mode. Most teams find their consumption patterns less predictable than expected, and it’s worth a clear read on how tokens are used across your endpoints before you set ceilings that block work. Once you know the limits that fit each environment, switch the budgets that matter to block mode.

We’re excited to open this up in public preview to all of our existing users. It’s also where we learn what teams need next: if you’ve had an incident that looked like an outage or a cost overrun but was really a runaway agent, we’d like to hear about it. If you’re new to Certiv and are interested in trying it out, reach out here and we’ll show you what your agents are spending, on which models, and where a budget would have caught it.

- Tai, VP of Product, Certiv