What to log so an agent's audit trail survives an incident
What to log so an agent's audit trail survives an incident
Most teams that ship an agent already have logs. What they usually don't have is an audit trail — and the difference matters the day something goes wrong and someone asks "why did it do that, and who let it."
Application logs aren't agent audit trails
A standard app log tells you a request came in and a response went out. An agent audit trail has to answer a harder question: given what the agent believed at the time, why did it take this action instead of another one. That means capturing the reasoning that led to a tool call, not just the call itself — the prompt, the retrieved context, which tool was chosen, what it returned, and whether a human signed off before it ran.
This isn't a hypothetical distinction anymore. Regulators are starting to write it into law, and the cloud vendors are starting to ship for it.
Regulation is catching up faster than most teams expect
The EU AI Act's Article 12 requires high-risk AI systems to "technically allow for the automatic recording of events (logs) over their lifetime," with retention of at least six months and — critically — identification of the natural persons involved in each event. That obligation lands on both providers and deployers, and it takes full effect for high-risk systems on August 2, 2026, per the regulation's implementation timeline.
In the US, NIST's Center for AI Standards and Innovation announced a formal AI Agent Standards Initiative on February 17, 2026 — the first US government program aimed specifically at interoperability and security standards for agentic systems, separate from the broader AI-safety evaluation work that preceded it. Alongside it, NIST's National Cybersecurity Center of Excellence put out a concept paper on adapting existing identity and authorization frameworks to agents, aimed at a problem most audit trails still get wrong: agent identity itself.
The service-account blind spot
That identity problem is the most common gap in practice: an agent accesses regulated data under a shared service account or API key, and the resulting log shows the agent acted — but not which person directed it to. HIPAA's unique-user-identification rule, GDPR's accountability principle, and the EU AI Act's Article 12 all assume you can name a natural person behind an action. A service-account log can't do that, which means the audit trail is incomplete even when the logging pipeline looks thorough on paper.
The fix isn't exotic: propagate the human's identity (or the delegating agent's, in a multi-agent chain) through every downstream call as a first-class field, not something reconstructed after the fact from a correlation ID.
What the platforms are actually capturing
Cloud vendors are starting to build this in rather than leaving it to each team to bolt on. Amazon Bedrock AgentCore now writes an agent's traces, prompts, and structured logs into a single CloudWatch log group per agent, in OpenTelemetry-compatible format, so a reviewer can walk one agent's execution path end to end instead of stitching together traces from separate systems. That's a reasonable floor: trace ID, agent identity and version, the triggering event, inputs and outputs, and a timestamp, all in one place and queryable after the fact — see AWS's observability docs for the current field set.
That covers the "what happened" half of the trail. The harder half — "who approved it, and how do you prove it" — is where payments protocols have gotten furthest, because they had no choice.
Signed consent: the payments world's answer
AP2, Google's agent payments protocol, treats a human's approval as a cryptographically signed artifact — a mandate — rather than a dialog box that gets dismissed and forgotten. The mandate records exactly what the agent was authorized to do, and the signature makes it verifiable after the fact, not just logged. It's a narrow slice of the audit-trail problem (one action type, one industry), but it's the clearest existing example of an authorization step that survives being audited months later, because the proof of consent is the artifact itself rather than a log line asserting consent happened.
That's the direction general-purpose agent audit trails are heading, even outside payments: an approval isn't fully logged until the record of it is independently verifiable, not just present.
A reasonable baseline to log
Pulling from the regulatory requirements above and how AgentCore and AP2 handle this, a workable minimum field set per agent action looks like:
| Field | Why it's there |
|---|---|
| Trace/session ID | Ties one action to the full run it belongs to |
| Agent identity + version | Which agent, which build — behavior changes across versions |
| Authorizing human (or delegating agent) | Closes the service-account gap above |
| Triggering input | What the agent was reacting to |
| Reasoning summary | Why this action, not an alternative — the part plain app logs skip |
| Action + parameters | What it actually did, not just what it decided |
| Result | Success, failure, or partial — including downstream side effects |
| Timestamp (UTC) | Non-negotiable for cross-system correlation |
None of this is exotic engineering. It's mostly discipline: treat the reasoning step and the authorization step as data worth keeping, not as ephemeral context that gets thrown away once the action completes.
Where it's still unsettled
Retention periods diverge by industry — the EU AI Act sets a six-month floor, while sector rules like HIPAA and SOX run much longer — so "how long" has no single answer yet. And nobody has standardized how a reasoning summary should be captured or redacted before storage, which matters once that trail itself becomes a record subject to discovery or a data-subject access request. Treat today's logging setup as a first draft, not a finished compliance artifact.
If you're deciding whether to build this now or wait, the regulatory dates above are a decent forcing function: six months of runway before the EU AI Act's high-risk obligations bite is not a lot of time to retrofit identity propagation into an existing agent stack.