Preventing AI Coding Agents from Running Up Uncontrolled Token Costs by Enforcing Policy in the Execution Path

How coding agents consume tokens without anyone noticing

In this guide, tokens are the units a model provider bills for, not security credentials. A coding agent turns one developer request into many model calls and tool calls. Each call can carry the accumulated conversation, file contents, and tool output, so consumption depends on agent behavior as much as on what the developer typed.

Six behaviors account for most uncontrolled consumption: recursive tool calls, retry loops, oversized context windows, repeated file reads, unbounded sub-agent spawning, and unapproved model selection. None requires an attacker. They are ordinary outcomes of an agent that keeps working toward a goal without a limit on how long, how often, or at what size it may act. Resource exhaustion is also a recognised failure category: NIST's AI Metrology Center lists testing whether a system can be degraded, delayed, or denied through repeated token attacks, sponge examples, and input overflows.

The operational problem is timing. Billing dashboards and usage reports show the result of these behaviors after the fact. By the time a threshold alert reaches a person, the loop has already run. Controls therefore have to sit where the behavior becomes a request, and they have to be evaluated per tool, because control effectiveness can vary with the agent scaffold, tool use, and multi-agent setups. A control validated for one coding assistant should not be assumed to carry over to another.

Map each cause to a runtime control

The method is the same for every cause. Identify the point where the behavior turns into a model request or tool call, then place a decision there. This applies the idea of binding AI services in context and time: each interaction has a bounded size, rate, and scope, rather than a single budget checked later. Human approval fits where a limit is better treated as a decision than a hard stop, such as a request for a more expensive model or a large sub-agent fan-out.

• Recursive tool calls: Cap calls per interaction and rate limit per agent and per tool. Block or escalate when the cap is reached.
• Retry loops: Rate limit repeated or near-identical requests per user and agent. Block after repeated failures instead of allowing indefinite retry.
• Oversized context: Enforce request size and context limits on each interaction. Block or redact payloads above the limit before they reach the model.
• Repeated file reads: Apply per-tool rate limits to file-read and search tools so one task cannot re-read the same material without bound.
• Sub-agent spawning: Limit how many sub-agents may be started and narrow the child's scope so it cannot exceed its parent's authority.
• Unapproved model selection: Apply a model allow-list per user or team. Block requests that name a model outside it, or escalate for approval.

Execution path or after the fact: how to tell the difference

A control is in the execution path if the request or tool call cannot proceed until the control has made a decision. A control is observational if it records or reports usage while the call proceeds regardless. Both are useful, but only the first can stop a runaway loop. Billing alerts, usage dashboards, and scheduled reports belong in the second group, however fast they refresh.

The distinction is not always visible in product descriptions, so test it. Trigger a limit deliberately in a non-production environment and observe whether the next call is stopped, delayed, or simply counted. Ask what happens to a call in flight when the limit is crossed, and whether the decision is made before the call or after it returns.

Limits set inside a coding assistant's own settings apply to that assistant. Enforcement applied independently of the tool can apply one policy across several assistants, agents, and tools. Whichever you use, confirm who can change the setting, whether a developer can override it locally, and whether the decision is recorded outside the tool being controlled.

Design decisions and tradeoffs

Fail-open or fail-closed behavior is the first decision. Failing closed protects against unbounded consumption but stops developers when the policy service is down. Failing open preserves availability but removes the limit at the moment it may be needed. Regulated teams often choose differently by tool or action, and the choice should be explicit and recorded. Any in-path control also adds latency, so measure it under realistic agent load rather than assuming it is negligible.

Apply controls at every step, not only at session start. Commenters on NIST's agent identity work raised concern that agents aggregate authorizations as task chains execute, and that static entitlements are insufficient given how probabilistic agents are. The same reasoning holds for usage limits: a check made once at the start of a long task does not bound what happens in the hundredth call.

Grant each agent only the tools and permissions the task needs, and attenuate scope when it delegates to a sub-agent so the child can never claim more authority than the parent. Prefer short-lived access acquired when a task starts over long-lived static credentials. This also lets you stop one agent workflow without freezing others.

Finally, test before and after change. Include repeated-input and input-overflow scenarios in pre-deployment testing, and re-test whenever the model, agent scaffold, or tool set changes.

Evidence to retain, and where runtime enforcement fits

A regulated enterprise needs to show not only that limits existed but which ones applied to a given interaction or tool call. For each enforcement decision, retain the time, the user or entity that initiated the task, the agent, the model or tool requested, the policy and version that applied, the limit that triggered, and the outcome: allowed, redacted, blocked, rate limited, or escalated. For escalations, add the approver and the time of approval or rejection. Linking each action to the initiating individual or organisation is what makes an outcome attributable to a responsible party. Record when a credential or permission was revoked as well.

This evidence is most reliable when the enforcement point produces it, because the record then reflects what the control decided rather than a later reconstruction. It is also bounded: records at the interaction and tool-call level do not by themselves reconstruct an entire multi-agent workflow, and they should not be described as doing so.

Trussed is one example of this approach. It enforces policy in the execution path across models, agents, tools, MCP servers, and coding assistants, with allow, redact, block, rate limit, and escalate for human approval applied to individual interactions and tool calls. Enforcement generates audit-ready evidence mapped to frameworks including NIST, and it can be self-managed in the customer cloud with configurable retention and data residency.