How to Cap AI Agent Spend Per Tenant

What a per-tenant cap measures

A cap is a limit on a measured quantity, for a named tenant, over a defined period. Before choosing tooling, decide which quantities the cap covers. Most platform teams need several at once, because agents consume in different ways.

Input and output tokens bound model consumption. Request counts bound call volume regardless of size. Tool call counts bound the actions an agent can take, which matters when a single prompt fans out into many downstream calls. Concurrency bounds how many agent runs or calls a tenant can have in flight, which limits the speed of a runaway loop. Time windows (per minute, per day, per billing period) decide how quickly a limit resets and whether a burst allowance exists.

Keep measurement and enforcement separate in your design. Measurement produces counts and alerts. Enforcement changes what happens to the next call. NIST describes agent-specific metrics, thresholds and monitoring that produce detection and warnings, and that is a different function from stopping a request. A dashboard that reports a tenant over its allowance after the fact has measured the problem, not capped it.

Set each allowance against a documented risk tolerance or contracted allowance, not an informal estimate. A cap that nobody can trace to an approved figure is hard to defend to a customer or an auditor.

Where to enforce: comparing enforcement points

The enforcement point determines what the cap can see and whether it can act in time. The comparison below is a general characterization. Verify the behavior of any specific product against your own requirements.

• Application code: Full access to tenant context and flexible logic. Each service must implement it correctly, counters drift between services, and a missed code path leaves a call uncapped.
• Provider quotas: Enforced by the model provider, but typically scoped to an account or key rather than your tenant, and they cover only that provider's calls, not tool calls.
• Gateway or proxy: A central point for model traffic and rate limits. Coverage depends on whether tool and MCP calls also route through it and whether it carries tenant identity.
• Runtime policy enforcement in the execution path: Evaluates each interaction and tool call before it proceeds, with tenant context available to the policy. Scope is the individual interaction or call.

Design threshold behavior and failure modes

Decide what happens at the threshold before an incident forces the question. The common behaviors are allow with an alert, throttle, block, and escalate for human approval. They suit different cases. A contracted hard allowance may call for a block. A premium tenant may warrant escalation so a person can approve additional consumption. A tenant approaching its limit may be throttled so interactive users keep working while batch agent runs slow down. Make the behavior configurable per tenant and per dimension.

Failure modes need equal attention. If the policy or counter service is unavailable, the system either fails open and risks uncapped spend, or fails closed and risks an outage for every tenant. Choose deliberately, and consider different answers for different actions. A read-only lookup and a tool call that triggers an external side effect do not carry the same risk.

Watch for three operational hazards. Counters shared across distributed instances can lag, so a tenant can overshoot by the amount in flight across instances. Retries can amplify load, since a blocked call that the agent immediately retries becomes a loop of denials unless the response tells the agent to stop. Fan-out multiplies calls from a single instruction, which is why tool call counts and concurrency limits matter alongside token limits. NIST's description of containing or revoking an agent's authority on anomalous behavior is a useful model for the strongest response: stop the agent, not just the call.

Evidence, and the limits of per-call enforcement

A usage log or billing report states what was consumed. Evidence of an enforced cap states what rule applied and what the system did about it. For each enforcement decision, the record should include the policy applied, the tenant identifier, the threshold, the action taken and a timestamp. That record lets a customer or auditor confirm that the limit was in force, not merely that usage stayed below it.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers. Its actions are allow, redact, block, rate limit and escalate for human approval, applied to individual interactions and tool calls. Policy is enforced at runtime, not reviewed after the fact, and the enforcement itself generates continuous audit-ready evidence. It can be deployed self-managed in the customer cloud, with configurable retention and data residency.

Be clear about scope. Per-interaction and per-tool-call enforcement is not transaction-level governance across tasks and agents. A cap applied to each call does not, by itself, tie together a multi-step business transaction or trace a workflow end to end. If your allowance is defined per business transaction, you will need additional design outside call-level enforcement.