An append-only chain of sealed audit log blocks.

Audit trails for agents: what to log

An audit trail is the answer to “what did this agent do, on whose authority, and how do you know?” For an agent, that question has two halves the classic application log does not separate: the actor (the agent) and the subject (the principal it acted for). Log only the actor and you cannot explain the action to the person it affected; log only the subject and you cannot hold the specific agent to account. The record has to carry both, plus the authority that made the action allowed.

This guide covers the fields an agent audit record should capture, how to correlate a task across many calls, how to make records tamper-evident, how long to keep them, and how to judge evidence that comes from a system you do not control. It follows the seven-step verification checklist and the scoping model in How to scope an agent’s permissions.

What an agent audit record captures

A single record should let an investigator reconstruct one action without fetching three other systems. At minimum:

FieldWhat it answersNotes
Agent identityWhich agent acted?The verifiable identifier (e.g. SPIFFE ID), not a display name
PrincipalOn whose behalf?The accountable person or organisation
Delegation / mandate referenceUnder what authority?Token ID, mandate ID or grant reference — not the token itself
Scoped actionWhat was requested?Action name plus resource, amount and conditions
DecisionAllowed, denied, or gated?Include the reason and policy that produced it
Tool callsWhat did it invoke?Tool/server name, parameters (with secrets redacted), result status
ApprovalWho authorised a gated step?Approver identity, timestamp, what they saw
OutcomeWhat actually happened?Success/failure, side effects, downstream references
Correlation / trace IDWhich task is this part of?Ties the record to the whole run
Credential referenceWhich credential was presented?A reference or fingerprint, never the secret
TimestampWhen?Trusted time where available

The OWASP MCP Security Cheat Sheet puts the practical bar simply: log all tool invocations with full parameters, user context and timestamps; redact secrets and PII; and feed logs into detection. Two cautions run through all of it: log a reference to a credential rather than the credential, and never write tokens or secrets into log payloads in cleartext.

Actor and principal are the load-bearing pair. Delegation semantics exist so that both are visible — RFC 8693’s token exchange carries the acting agent and the principal it acts for. Your audit record should mirror that, so the same action is attributable from either direction.

Correlation IDs

An agent rarely does one thing. A single task — “book the trip” — may fan out into search, price lookup, booking and payment calls across several services, possibly through sub-agents. Without a correlation identifier, those calls are unrelated rows in unrelated logs.

Use a trace ID minted once when the task is created, propagated on every downstream call, and recorded on every audit entry. Where the platform supports it, add the parent span (which sub-task triggered this call), so a chain of delegated actions can be reconstructed. This is the difference between “an agent transferred money at 14:02” and “in the course of the October invoice run, the procurement agent, on behalf of Alice, submitted this approval and paid this invoice.”

Correlation also exposes the failure that per-call logging hides: a gap in the chain. If the trace claims five steps and the log shows four, that is a signal, not a rounding error.

Tamper-evidence

An audit trail you can quietly edit is not evidence. The usual building blocks:

  • Append-only storage — records can be added but not modified or deleted by the component that produced them.
  • Hash chaining — each record includes a hash of the previous one (and its own contents), so any later change breaks the chain and is detectable.
  • Independent witnessing — the strongest form: an observer that collects event data independently of the agent, kept where the agent and its supplier cannot rewrite it. A recorder fed only by the agent preserves the agent’s own account of events.
  • Time evidence — a trusted timestamp, or a signed challenge (nonce) that proves a record was produced after the challenge was issued.

A signature proves who made an assertion, not that the assertion is true. The OWASP “Verifying Third Party Agent Execution Evidence” cheat sheet makes this distinction sharply: evidence is either independently re-checkable, a supplier assertion, or no information, and a valid signature or a log inclusion proof should not be treated as proof that an action occurred. Where you cannot corroborate an agent’s record with a boundary you control, classify it as a supplier assertion and limit the decisions you base on it.

Retention

Retention is a trade-off between cost, privacy and the need to answer questions later. Two forces set the floor:

  • Regulatory — where an agent is part of a high-risk AI system under the EU AI Act, Article 12 requires the system to “technically allow for the automatic recording of events (logs) over the lifetime of the system”. Article 19 requires providers to keep those logs, to the extent under their control, for a period appropriate to the intended purpose and at least six months, and Article 26(6) places a parallel duty on deployers for logs under their control. (This is transparency and record-keeping, not a KYA identity standard; see the note below.)
  • Investigative — an incident may surface weeks after the action, so retention should match how long the consequences of an action can persist (a payment can be disputed long after the token expired).

Balance retention against data-protection law: keep what you need, redact what you must not retain, and prefer references to raw secrets over copies of them.

Logging versus deciding

The most common architectural mistake is putting the audit trail inside the component being audited, with the same privileges. Split the roles: the enforcement point (gateway, policy engine, or tool server) decides and emits the record; the audit store accepts and protects it. Then corroborate the agent’s own record against calls recorded at a boundary you control. A record produced by the component is the component’s account; a boundary record is independent evidence of what crossed the boundary — and only of that.

Checklist

  • Every record names the agent, the principal and the mandate reference
  • The scoped action, decision and reason are recorded, not just the call
  • Tool calls, parameters (secrets redacted) and result status are captured
  • A correlation/trace ID ties every call to the task
  • Approvals record who approved, when, and what they saw
  • Credentials are referenced, never copied into logs
  • Records are append-only and hash-chained (or otherwise tamper-evident)
  • An independent observer corroborates records where the stakes justify it
  • Retention meets regulatory floors and investigative need, within privacy limits
  • Missing records are treated as possible gaps, not as proof nothing happened

FAQ

Can I just reuse my application logs?

Partly. Web/application logs usually have the actor but not the principal or the mandate reference, and rarely capture the policy decision. Add the missing fields rather than bolting a second system on top; the KYA-specific fields — principal, delegation reference, decision reason — are the ones that make an agent action explicable.

What if the agent runs inside a vendor’s platform?

You may not control the agent’s internals, but you control the boundary where its calls reach your systems. Log there, demand the vendor’s record alongside yours, and keep the two separable. Treat the vendor’s record as a supplier assertion until an observer you control corroborates it.

Is a hash-chained log enough for compliance?

Hash chaining gives tamper-evidence; it does not by itself satisfy any specific regime. Record-keeping duties (for example the EU AI Act’s Article 12 logging capability and Article 19 retention) are about capabilities and periods, and intersect with data-protection law. Use the technical controls here as inputs to a compliance assessment led by qualified advisers.

Should I log the prompt?

Log enough to reconstruct the decision — the instruction, the relevant context and the tool calls — while respecting privacy and minimising sensitive content. Prompts can contain personal data and secrets; store what the investigation needs, redact the rest, and keep the record referenceable rather than raw where possible.

Not legal advice. Retention periods, records duties and data-protection constraints depend on your jurisdiction and risk classification. This guide describes technical logging practice; confirm your legal obligations with qualified counsel.

Primary sources

Know Your Agent (KYA) explains agent identity, verification and accountability. This is an explainer, not legal or compliance advice — see our Sources & methodology. New to KYA? Start with What is Know Your Agent? and the glossary.