LLM Spend Control Audit Evidence: What Auditors and Examiners Expect

Treat spend control as a control objective

LLM spend control is often discussed as a financial topic. For an auditor or examiner it is a control objective: a defined limit on what a user, application or agent may consume, with a mechanism that makes the limit hold. The question is not how much was spent. The question is whether the organization can show that its stated boundaries were enforced on real traffic.

Audit regimes generally separate two tests. Design effectiveness asks whether the control, as documented, would meet its objective if it operated as described. Operating effectiveness asks whether it actually operated over the period under review, usually tested by sampling individual instances. The text of 2 CFR Part 200, although written for Federal awards and not for AI, illustrates the pattern: recipients must establish, document and maintain effective internal control, records must be supported by source documentation, and auditors must understand and test those controls.

For LLM usage, this means a policy document satisfies only the first test. The second requires source-level records of individual interactions that an auditor can select and trace back to a policy, an identity and an outcome. Summaries and dashboards are not enough on their own, because they cannot be sampled.

Runtime enforcement evidence versus reconstructed evidence

Evidence differs in how it is created. A record written at the moment a policy decision is made carries the decision itself. A record assembled later from invoices and logs carries an inference about what probably happened. Auditors test the linkage between identity, policy and outcome, and reconstructed evidence usually has to be shown to hold that linkage before it is accepted.

• Policy applied: Runtime record: names the policy and version that produced the decision. Reconstructed: policy is inferred by comparing usage to a document.
• Attribution: Runtime record: identity of the user, application or agent captured with the request. Reconstructed: often limited to an API key or account-level total.
• Outcome coverage: Runtime record: includes limited, blocked and escalated requests. Reconstructed: invoices show only what was consumed, not what was stopped.
• Timing: Runtime record: timestamped at the decision. Reconstructed: reflects billing periods or log ingestion times.
• Integrity: Runtime record: can be written to an append-only, tamper-evident store. Reconstructed: depends on how mutable the source systems are.
• Sampling: Runtime record: each interaction can be selected and traced. Reconstructed: samples are rebuilt by hand for each request.

Mapping evidence to frameworks and regimes

No single framework prescribes an LLM spend-control evidence format, so the mapping is done control by control. NIST publishes the AI Risk Management Framework (AI RMF 1.0, January 2023) and a Generative AI Profile (July 2024), and describes the AI RMF as a living document. COSO and the GAO Green Book are the internal-control frameworks that 2 CFR 200 points to, and they are commonly used as the structure into which AI controls are mapped.

Two items are useful as design references. A NIST cybersecurity blog on agent identity, published in October 2026, lists immutable evidence as a design tenet: an unbroken, tamper-evident chain of custody and an append-only body of evidence covering an agent's identity, the delegated intent and the resulting actions. It also describes signed mandates that downstream services can verify to support authorization, auditing and accountability. This is guidance, not a binding requirement, but it describes properties an auditor will recognize as reliable. The same post notes that LLMs do not separate data from the instructions given to them, which is a reason to enforce limits outside the model.

The EU AI Act (Regulation 2024/1689) is in force as of October 2026, and a consolidated version incorporates successive amendments. A recital stresses that records and technical documentation support assessment of compliance and post-market monitoring. The practical reading is to keep policy definitions and enforcement records as linked artifacts. For NYDFS, NAIC and HIPAA, take the requirement text from the regulator or the applicable official source, and keep a record of the framework versions used in each mapping.

Evaluating tooling that produces the evidence

Start with where enforcement happens. If limits are applied in the execution path before a request reaches the model, the decision and its record come from the same event. If limits are observed afterward, the control is monitoring, and the evidence will be a report about consumption, not proof of prevention. Ask the vendor or internal team which artifact demonstrates each.

Then test the record itself. Each entry should identify the user, application or agent, the policy applied and the outcome, whether allowed, limited, blocked or escalated. Ask how an auditor can verify that the store is append-only or tamper-evident, and whether this is enforced technically or only by procedure. Confirm that retention periods and data residency are configurable and documented for the regimes that apply to you.

Finally, ask for a sample evidence export and the control mapping behind it, with the mapping source identified. Tradeoffs are real: enforcement in the path adds a dependency on traffic, so availability and failure behavior (fail open or fail closed) should be documented and tested as part of the control design. Evidence volume also grows quickly, which makes retention and storage planning part of the control, not an afterthought.

How Trussed produces audit-ready evidence

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Actions are allow, redact, block, rate limit and escalate for human approval, applied to individual interactions and tool calls. Because the decision is enforced at runtime, not reviewed after the fact, the audit-ready evidence is generated by enforcement itself and mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST.

Trussed is deployed self-managed in the customer cloud, with configurable retention and data residency. It has run continuously in a regulated enterprise for 18+ months, brings 100+ models under one policy plane, and generates 30+ GB of audit evidence per day. Mapping to a given regime should still be confirmed by your compliance team against the current official text.