What Evidence for Every Request and Tool Call Actually Contains: The Anatomy of Audit-Ready Runtime Evidence

Evidence is produced by enforcement, not reconstructed from logs

Regulated enterprises running models, agents, tools and MCP servers have to show an auditor what their AI was allowed to do and what it did. Application logs and after-the-fact reviews tend to answer a different question: what the application chose to write down. They often omit the policy that applied, the decision reached and the result for each individual interaction.

The distinction is architectural. When policy is enforced in the execution path, the same component that evaluates the request also makes the decision and observes the result. The record is a by-product of the decision rather than a reconstruction. Observability traces and application logs are assembled afterward from whatever each service emitted, so completeness depends on every service logging consistently. This is analysis rather than a regulatory definition, but it explains why the two outputs differ in structure and completeness.

This guide is scoped to individual interactions and tool calls. It does not address transaction-level governance, end-to-end tracing of agentic workflows, or model and dataset provenance. Those are separate problems with separate evidence.

The evidence record, field by field

No regulation prescribes a single schema for AI interaction records, so the field set below is a practical design derived from what auditors ask: what was permitted, what was attempted, what was decided and what resulted. NIST's design tenets for agent identity point the same way. Evidence should cover identity, delegated intent and resulting actions, and each tool invocation, API call or resource access should be verified at runtime against current state, environmental context and risk profile.

Each record should carry the following groups of fields.

• Interaction context: The requesting user, agent or application identity, the target model, tool or MCP server, the operation requested, and the delegated intent or session context known at that moment. Attribution established at the time should be preserved even if the call is later denied.
• Policy evaluated: An identifier and version of the policy that applied, so a reviewer can tell which rule set governed this call and not only today's rule set.
• Enforcement decision: One of allow, redact, block, rate limit or escalate for human approval, with the rule that triggered it. For escalations, the approver and the approval result belong in the record.
• Outcome: What happened after the decision: the call completed, the payload was modified, the call was stopped, or approval was granted or refused. Redaction records should state that content was altered and which category was affected.
• Integrity and time: A trustworthy timestamp, a record identifier and a sequence position, so ordering can be checked and gaps detected.

Decision points and what each one writes

A record exists for every decision, not only for permitted calls. NIST's guidance treats evidence of denied or out-of-scope attempts as in scope. A store holding only successful calls cannot show that a control worked, because blocked attempts are the main proof that a boundary was enforced.

An allow record shows that a call matched policy and proceeded. A redact record shows the original request was permitted only after modification, and what kind of content was removed. A block record shows the call never reached the tool or model. A rate-limit record shows a threshold was applied to a permitted actor. An escalation record shows the call was held for human approval, and should be followed by a second entry capturing the approval decision.

One caution applies to the outcome field. A recorded decision is a claim about behaviour. Independent observation, such as canary values or checks on what actually left the system, can confirm that the recorded decision matches the real effect. That kind of test is how a security team distinguishes a model's response from a security-relevant action.

Integrity, retention, residency and self-managed deployment

Evidence is only defensible if the store holds up. NIST SP 800-53 Revision 5 requires that audit record handling not alter the original content or time ordering of records. It also notes that storing records in a repository separate from the audited system helps ensure that a compromise of that system does not also compromise the records. NIST's agent identity tenets add that evidence should be append-only and tamper-evident, with historical records remaining verifiable after credential rotation, expiry or agent retirement, without the agent being online.

Three practical requirements follow. First, write access should be limited to the enforcement component, and read access should be controlled and itself recorded. Second, verification should not depend on the original agent or credential still being active. Third, retention and data residency must be configurable to the obligations of the organization, because evidence can contain sensitive request content and may need to stay in a defined region.

This is where deployment model matters. A self-managed deployment in the customer cloud lets the regulated enterprise keep evidence in its own environment, under its own retention settings and residency boundaries, separate from the AI systems being audited. Trussed supports self-managed deployment with configurable retention and data residency, and has run continuously in production in a regulated enterprise for more than 18 months, generating more than 30 GB of audit evidence per day. That volume is a reminder to plan storage, indexing and retrieval before the first audit.

Mapping evidence to frameworks

Mapping should happen at the field level. For high-risk AI systems, the EU AI Act requires that the system technically allow automatic recording of events over its lifetime, and providers must keep the automatically generated logs to the extent those logs are under their control. As of November 2026, whether a given deployment is high-risk, and who controls the logs, must be determined for each system. NIST SP 800-53 Revision 5 adds expectations on audit record content, time ordering, protection from alteration and storage separate from the audited system. Planning for control assessment evidence should happen during control selection and implementation.

Trussed produces continuous audit-ready evidence from enforcement, mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. Whatever product is in use, the useful test is whether each field in a record can be traced to a specific control requirement. A mapping that names a framework without naming the controls and fields behind it is a label, not evidence.