How to Prove AI Spend Was Authorized

What counts as evidence that AI spend was authorized

Most regulated enterprises can produce invoices and usage totals for models, agents, tools and coding assistants. The harder question from an auditor is whether each interaction that incurred spend was permitted by policy at the time it ran. Answering that from billing data alone requires reconstruction, and reconstruction rests on attestation.

It helps to treat authorization as an evidence problem rather than a reporting problem. Reporting summarizes what occurred. Evidence shows that a specific decision was made, under a specific rule, about a specific action, before the action proceeded. The test is whether the record was produced by the control that made the decision, or assembled later from separate systems where approvals, budget owners and policy rules are held apart.

This distinction separates two categories. Evidence reconstructed after the fact includes invoices, usage logs and periodic reviews. Evidence produced by enforcement in the execution path is written at the moment of the decision, as a by-product of applying policy.

Where common sources of proof stop

Each common source answers a real question. The gap appears when it is used to answer a different one: was this action authorized when it happened?

• Provider invoices: Show volume and charges by account or key. They do not show which policy applied to an individual call or who approved it.
• Gateway or application logs: Show that a request occurred. Unless a policy decision is written into the record, they do not show why it was permitted.
• Access-control lists: Show who could use a resource. They describe standing permission, not a decision about a particular interaction.
• Periodic usage reviews: Show that someone examined activity later. They evidence review, not authorization at execution time.
• Separate approval records: Show that approval existed somewhere. Without a shared identifier they are not linked to the specific interaction.

Why enforcement in the execution path changes the evidence

When a control decides before an action proceeds, the decision record and the action share a moment. That removes the reconstruction step. The record exists because the control had to resolve the request, not because someone later went looking.

The design also changes behavior when a check cannot complete. OWASP guidance on AI agent payments, a different use case but a useful analogy, says an incomplete or unavailable check should be treated as unresolved, never as clearance, and that execution should be withheld until it resolves. The fallback may be bounded retries, manual review or rejection, according to approved policy. For AI spend, the equivalent decision is made in advance: if the policy check fails, does the call proceed or stop?

Two cautions apply. First, record integrity is not decision correctness. The same OWASP guidance notes that signatures provide origin and integrity assurance but do not prove the underlying check was performed correctly. A tamper-evident record of a wrong decision is still wrong, so policies need periodic validation against the intended authorization rules.

Second, human approval needs tuning. NIST describes risk thresholds that trigger human review of agentic actions, supported by technology that escalates to the correct authority. It also warns of consent fatigue, where escalations become so frequent that approvals turn habitual. Thresholds should send only consequential actions to people, so an approval remains a deliberate decision.

Where interaction-level evidence ends

An interaction-level record establishes that a particular call or tool invocation was permitted under a particular policy, by a particular identity, with a particular outcome. It does not by itself say which business process, transaction or budget owner the call belongs to. That is transaction-level or workflow-level attribution, and it is a separate scoping question.

Risk leaders should keep the two apart in audit conversations. Interaction-level evidence is the foundation: without it, higher-level attribution has nothing reliable to attach to. But a claim such as "this spend belonged to this budget owner's approved project" needs a join between interaction records and whatever system holds ownership and approval of the business activity. Be explicit about which layer each artifact supports.

Trussed is one way to produce the interaction-level layer. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, with decisions to allow, redact, block, rate limit or escalate for human approval, scoped to individual interactions and tool calls. Audit-ready evidence is generated by that enforcement and mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. Deployment is self-managed in the customer cloud, with retention and data residency configurable. Business transaction identity and tracing of agentic workflows are outside current shipped scope.