AI Cost Governance Maturity Model

What the model measures

Most organizations running several models, agents, tools and coding assistants manage AI spend through billing exports and periodic reviews. That is a reasonable starting point, but it does not distinguish between knowing what was spent and controlling what can be spent. A maturity model makes that distinction explicit so that an architect can define a target state, sequence the work and say what each stakeholder should be able to see.

The model below is an architect's framework, not a published standard. It aligns with outcomes in the NIST AI Risk Management Framework, which is voluntary. Govern 1 expects policies, processes and practices to be in place, transparent and implemented effectively, and Govern 1.3 ties the depth of risk management activity to organizational risk tolerance. The word "implemented" is the useful part here. A written spending policy that nothing enforces is documented, but it is not implemented in any technical sense.

Scope is deliberate. The model covers controls on individual interactions and individual tool calls. It does not address transaction-level governance or governance of whole agentic workflows, and it makes no claim about how much any stage reduces spend.

The five stages by control mechanism and evidence

Stages are separated by what the control does and what record it leaves, not by which tools are deployed. Two organizations with the same tooling can sit at different stages.

• 1. Ad hoc: Control: none beyond provider-level account limits and manual review. Evidence: billing reports and invoices, with no link to a specific interaction.
• 2. Attributed: Control: every request carries an identity, such as user, team, application or agent. Evidence: usage attribution records that finance can allocate.
• 3. Defined: Control: written budgets, approved model lists and approval rules, applied by manual process. Evidence: policy documents and review minutes.
• 4. Enforced: Control: quotas, token rate limits, model and tool allow-lists and approval escalation act before a request completes. Evidence: enforcement outcomes per request.
• 5. Evidence-backed: Control: Stage 4 controls plus periodic verification that they work. Evidence: policy decision records, approval records and retention settings that audit can retrieve.

Control points at each stage

Attribution is the foundation. Stage 2 requires that identity travels with each request, including requests made by agents and coding assistants on behalf of a person. Without it, quotas cannot be assigned and spend cannot be allocated to an owner. Attribution at this stage is still a measurement: it produces records, but it blocks nothing.

Stage 3 adds the policy content: budgets per team, a list of approved models, rules about which tools an agent may call, and a defined route for exceptions. The limitation is that humans apply these rules after the fact. A team can exceed its budget or call an unapproved model, and the organization learns about it in the next review cycle.

Stage 4 moves the same policy into the request path. Token rate limits cap consumption over a time window. Quotas stop usage at a defined threshold. Model and tool allow-lists reject calls to anything not approved. Requests that exceed policy can be held for human approval rather than simply refused. This is the stage where the control acts on the interaction itself.

Stage 5 adds proof. Each decision, whether allowed, limited, blocked or escalated, is recorded with the policy that produced it, and approvals record who decided and when. Retention is set deliberately rather than inherited from a default. The depth of control can follow risk tolerance, so stricter limits and approvals apply to higher-risk usage, consistent with the intent of Govern 1.3.

Testing whether a control is enforced or only reported

The most useful evaluation question is simple: does the control act on the interaction before it completes, or does it describe the interaction afterward? A budget alert that emails a manager is reporting. A quota that rejects the next request is enforcing. Both have value, but they belong to different stages and should not be scored the same.

This test is an architectural inference rather than something NIST defines, but it follows from the expectation that policy is implemented effectively. Apply it to each control separately. It is common for an organization to enforce a model allow-list while only reporting on token volume.

Two limits apply to any control at this level. First, a per-interaction control sees one request or one tool call at a time, so it cannot reason about the purpose of a multi-step workflow. Second, enforcement depends on coverage: a control only counts if every path to a model or tool passes through it, including direct provider keys held by individual teams.

Architectural requirements for advancing

Moving from Stage 1 to 2 requires a consistent identity on every call. In practice this means routing model and tool access through a shared path or requiring identity propagation, so attribution does not depend on each application's own conventions.

Moving from Stage 2 to 3 is mostly organizational: agree on the policy, its owners and its exceptions. Keeping policy definition separate from any single model or tool integration is a sound design choice, since governance in the NIST framework is treated as a cross-cutting function rather than something belonging to one component. The same principle suggests policy should be expressed once and applied across providers.

Moving from Stage 3 to 4 is the largest architectural step. A component must sit in the execution path, evaluate policy on each interaction and tool call, and take an action: allow, limit, block or hold for approval. It must also be highly available, because a control in the path becomes a dependency. Approval gates for deployment decisions have precedent in NIST AI 600-1, which describes go/no-go deployment approval policies. Applying approval to individual requests is a design extension of that idea, and it needs clear routing, timeouts and a defined default when no approver responds.

Moving from Stage 4 to 5 requires treating evidence as a designed output. Decide which fields each decision record holds, how approvals are captured, where records are stored and how long they are kept. Then verify on a schedule that the controls still work, in line with the general expectation that safeguards are reassessed rather than assumed.

Where runtime enforcement fits

Stages 4 and 5 are where a runtime enforcement layer applies. Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, with actions to allow, redact, block, rate limit or escalate for human approval. Its scope is individual interactions and tool calls, and the enforcement generates audit-ready evidence as it operates. It supports self-managed deployment in the customer cloud, with configurable retention and data residency.

Trussed runs more than 100 models under one policy plane and has operated continuously in production at a regulated enterprise for more than 18 months. The Stage 1 to 3 work described above does not depend on it, and the assessment questions apply to any implementation.

For finance, risk and audit stakeholders, the practical outcome of Stage 5 is that a request for evidence can be answered from records produced at the time of each decision, rather than reconstructed from billing data and interviews.