Linking Evidence for Every Request and Tool Call into One Agent Run Record

What a run record has to prove

When an agent handles a task, it issues many model requests and tool calls, some of them to MCP servers. Each interaction usually produces its own evidence in a separate system, with no shared identifier and no common schema. When an auditor or incident responder asks what the agent was allowed to do and what it actually did, someone has to rebuild the sequence by hand. That work is slow, and the result is often incomplete.

Treat this as an evidence design problem rather than a logging or observability exercise. Observability tooling answers whether a system is behaving. A run record has to answer a different set of questions: which actions occurred, in what order, under which identity, governed by which policy, and with what enforced outcome. The last two are where reconstructed records are weakest. Application logs can show that a tool call happened. They rarely show which policy version applied to it or whether the decision was allow, redact, block, rate limit or escalate.

The practical test is simple. Given only a run identifier, can you retrieve every interaction in that run, in order, with the policy and decision attached to each? If the answer requires joining records across systems, the run record does not yet exist.

A minimum evidence schema per enforcement point

No standard agent run record schema exists, so the following is a proposed minimum derived from what auditors and incident responders need. Trace logging guidance from OWASP calls for capturing which tools were called, in what sequence, with what parameters, and what they returned. NIST material adds that agent actions should be linkable to the initiating human or entity. The fields below combine those requirements with the policy and decision evidence an enforcement point can produce.

Keep the schema identical across enforcement points, with a small number of type-specific fields. A uniform core lets one query return the whole run and keeps reviewers from learning a new format per tool.

• Run ID and sequence position: A shared run identifier plus an explicit sequence number assigned per run, so order does not depend on timestamps alone.
• Timestamp: Event time for each record. Start and end time of the run itself are useful for use-period reporting.
• Identity and delegation: The agent identity, the initiating human or entity, and the delegated scope under which the action ran.
• Target: The model, tool or MCP server addressed, and the operation requested.
• Policy and decision: Policy identifier and version, and the decision enforced: allow, redact, block, rate limit or escalate.
• Inputs and outputs handled: Parameters and returns as they were after enforcement, with a note of what was redacted or withheld.

Correlation, ordering and where they break down

A run identifier is only useful if it is present on every record. It should be created when the task starts and propagated to each model request and tool call, including those made through MCP servers. The most common failure is propagation: a tool or intermediate service drops the identifier, and the interaction becomes an orphan that cannot be attached to any run.

Ordering is the second concern. Timestamps from different systems can disagree, and parallel tool calls can complete in a different order than they started. An explicit sequence number assigned at the enforcement point removes that ambiguity. Where calls run in parallel, record both the sequence value assigned at request time and the completion time.

Delegation is the third. When an agent hands work to a sub-agent or downstream service, the receiving side needs a reference to the parent run and the parent scope. Without it, you can see that actions occurred but not under whose authority. NIST material notes that delegated scopes should attenuate, so a downstream entity cannot claim more authority than its parent. A parent reference makes that checkable in the record.

Be explicit about what this gives you. It ties each enforced interaction to one run and one initiator. It does not, by itself, describe the business outcome of a task or follow work that leaves the enforcement points.

Integrity, retention and regulatory considerations

Evidence is only useful if it can be trusted. NIST work on agent identity asks how to ensure agents' actions and intent are recorded in a tamper-proof and verifiable way, and how to bind actions back to human authorization. Treat tamper evidence as a design decision to validate: append-only storage, signed records or hash chaining, and restricted write access for the systems being governed. The goal is that a reviewer can tell whether a run record was altered after the fact.

On regulation, Article 12 of the EU AI Act, as of November 2026, states that high-risk AI systems shall technically allow automatic recording of events over the lifetime of the system. The logging must enable traceability appropriate to the system's intended purpose, and one listed event type is the period of each use, with start and end date and time. Whether a given agent deployment is a high-risk system is a legal determination. The article's text does not turn your run record into compliance on its own.

Retention periods and data residency should be set with legal and compliance teams for each framework that applies to you, not copied from a generic template. What the engineering team controls is whether retention and residency are configurable, and whether the evidence store can be deployed where the data must stay.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, at the level of individual interactions and tool calls. It produces audit-ready evidence from that enforcement, mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. It is self-managed in the customer cloud, with configurable retention and data residency.