How to write an AI cost governance policy that can be enforced at runtime

What makes a cost policy enforceable

Most AI spend policies are written as statements of intent: use approved models, stay within budget, get approval for high-impact actions. Those statements are reasonable, but nothing in them can be evaluated when an agent makes a tool call or a coding assistant sends a prompt. The policy is then reviewed after the fact, and the owner cannot show which rules were in force when a limit was reached.

An enforceable policy keeps the same structure but writes each requirement so a system can test it. Start with six sections: scope (which models, agents, tools and assistants are covered), ownership (who is accountable for the policy and for each threshold), approved resources, usage and budget thresholds, exception and escalation paths, and review cadence.

Anchor the policy to the organization's existing policies and stated risk tolerance. NIST AI RMF Govern 1 expects policies and procedures for managing AI risk to be in place, transparent and implemented effectively, and Govern 1.3 ties the level of risk management activity to risk tolerance. The framework is explicit that its actions are not a checklist, so treat it as a source of governance framing rather than a template to copy.

Step 1: Translate each clause into a testable rule

A rule is testable when two people reading it would reach the same decision on the same event. Use one format for every clause: subject, condition, threshold, action at the limit, and evidence produced. Where a threshold is not yet known, record the placeholder and the owner who will set it, rather than leaving the clause vague.

The action at the limit is part of the clause. A clause that says usage must stay under a limit but does not say whether the next call is stopped, slowed or sent to a person is not yet a rule.

• Approved resources: If the requested model, tool or MCP server is not on the approved list for this user or agent, block the call.
• Token budget: If cumulative tokens in a session or for a user exceed the defined limit, block further model calls or escalate for approval.
• Per-call and per-minute cost cap: If estimated inference cost for a call, or spend per minute, exceeds the cap, block or rate limit.
• Loop controls: If retries or tool-chain depth exceed the limit, stop the chain. This addresses unbounded agent loops that drive excessive API and compute spend.
• High-impact tool calls: If an action is classified as high risk, require an approval identifier before execution.
• Spike circuit breaker: If cost, latency or tool-call volume spikes abnormally, trip a circuit breaker or kill switch.

Step 2: Decide what is enforced at runtime and what stays procedural

Sort every rule into one of two groups. A clause belongs at runtime if the system can evaluate it from information available at the moment of the interaction or tool call: the identity, the resource requested, the running token or cost count, the retry count, the risk classification, the approval state. These map to four outcomes: allow, block, rate limit, or escalate for human approval. Where the same enforcement point also handles sensitive content, redact is a fifth outcome, though it is less often a spend control.

Three design points matter. First, the decision belongs to a policy service or execution component that is separate from the agent. An agent can propose an action, but scope, privilege and approval state should be validated independently before it runs. Second, thresholds should be enforced deterministically, outside the prompt and outside model output behavior. A system prompt that tells a model to stay within budget is not a control. Third, the enforcement point should fail closed. If risk classification, approval validation, policy lookup or decision recording fails, the action does not proceed. That puts policy lookup and recording on the critical path, which is a latency and availability decision to make deliberately.

Human review is the boundary for cases the automated rules cannot resolve. Automated rules set the floor, and escalation handles the ambiguous middle.

Some clauses cannot be tested per interaction and should remain procedures: setting risk tolerance, deciding the review frequency, approving a new use case, and assigning ownership. Writing them as procedures is not a weakness. The weakness is leaving a procedural clause unowned or undated.

Step 3: Define ownership, exceptions and review

Assign named responsibility for the policy as a whole and for each threshold. Governance checklists consistently call for documented, assigned responsibility for AI risk, risk assessment and governance, and an unowned threshold tends to be one that is never revisited.

Treat exceptions as rules too. An exception should name the requester, the approver, the specific resource or limit affected, an expiry date and the reason, so that the enforcement point can apply it and the record shows it was applied. A permanent verbal exception is indistinguishable from a policy failure when someone later reviews the spend.

Set the review cadence in the policy. The NIST AI RMF Playbook suggests establishing the frequency and level of detail for monitoring, auditing and review, and regularly evaluating the qualitative and quantitative costs of AI system failures. In practice this means a scheduled review of thresholds and approved resources, plus a trigger-based review when a new model, agent or tool enters scope. Because models, agents and tools change often, a clause that lists approved resources is the first one to go stale.

Where runtime enforcement infrastructure fits

You can draft and test this policy structure without any particular product. What you need from an enforcement layer is a decision point in the execution path, deterministic rules, fail-closed behavior and durable records tied to the policy version.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, with allow, redact, block, rate limit and escalate for human approval applied to individual interactions and tool calls. The audit-ready evidence is generated by that enforcement, so the record of what was permitted comes from the same decision that permitted it. Trussed does not attribute cost at the business transaction level or trace agentic workflows end to end, so policy clauses should be written at the interaction and tool-call level.

As a next step, take your current spend policy, rewrite five clauses in the subject, condition, threshold, action and evidence format, and mark each as runtime or procedural. The clauses you cannot rewrite are the ones that need an owner and a decision before any enforcement is possible.