Audit trails: attributable to agent, principal, and task

Lesson 5 of 5 in Agent Identity, Auth, and Secrets.

Identity design pays off exactly once: at 02:00, when someone asks what did it do, whose authority did it use, and what else did it touch? If the answer requires reading model transcripts and guessing, you did not have identity — you had a login.

The bar is a single sentence, reconstructable from structured data alone: agent invoice-triage version 14, acting for user Dana (subject) as itself (actor), on task 8821, called erp.postJournal with these arguments at 01:58:04, authorized by a delegated token issued at 01:57:59 and expiring at 02:02:59. Every clause is a field. Every field has to be written at call time, because none of it is recoverable later.

The OWASP agentic threat taxonomy names this failure directly — Repudiation & Untraceability — alongside Privilege Compromise and Identity Spoofing & Impersonation. Repudiation is the quiet one: no data is stolen and nothing breaks, you simply cannot prove who did what. That is enough to sink a regulated deployment, and it is the default outcome of shared identity.

The attribution record — every field, and the question it answers
Field	The question it answers	Where it comes from	What breaks without it
Agent id + version	Which agent, running which build of its prompt, tools and model?	Per-agent identity plus the deployment’s version pin. Foundry versions agents automatically and serves an administrator-selected active version; AgentCore Runtime emits runtime metrics and structured logs per agent.	You cannot tell whether a fix landed, cannot correlate a regression to a release, and cannot say which agents share the defect.
Actor principal	Who performed the action?	The agent identity itself — an ARN or object id, not a shared account name.	"svc-ai-automation did it." Investigation becomes archaeology and revocation becomes an outage.
Subject principal	On whose behalf was it done?	The delegated token’s subject claim, from the on-behalf-of exchange.	You cannot answer per-user data-access requests, cannot detect an agent acting for a user who never asked, and cannot honour a consent revocation.
Task / session id	Which unit of work, and what else happened inside it?	Assigned at invocation and propagated through every span. AgentCore Observability documents a session → trace → span hierarchy using OpenTelemetry GenAI conventions and W3C Trace Context.	You see isolated tool calls with no story. The one bad call cannot be linked to the poisoned document that caused it.
Tool + arguments (redacted)	What exactly was requested, against which resource?	The runtime at the point of the call — never reconstructed from model text.	You know a write happened but not what it wrote. Also the place secrets leak into telemetry if redaction is missing.
Authorization decision + credential reference	Why was this allowed, and with which credential?	The authorizer and token broker: token id or hash, scopes granted, issue and expiry times. Never the token itself.	You cannot answer "was this within policy?" or scope revocation to the right credentials.
Denials, not just successes	What did it try that we refused?	The same enforcement point, logging both outcomes.	You lose the best early signal there is: a burst of denials from one agent is the visible edge of an injection attempt.
Human approvals	Who approved this, seeing what, and how long did they look?	The approval gate itself, recording reviewer, payload shown, and decision latency.	Accountability evaporates into "the system approved it", and you cannot detect a gate that has decayed into a reflex click.

Two logs, two jobs — and you need both

The control-plane log is your platform’s audit trail: identities created, roles granted, agents registered and published, credentials issued. On AWS, CloudTrail — the Agent Registry documents CloudTrail audit trails, and AgentCore’s stated security capabilities include comprehensive audit logging. This log is tamper-resistant, retained on your compliance schedule, and outside the agent’s reach.

The agent trace is the reasoning-level record: prompts, tool calls, tool results, spans, latencies. Rich, huge, and not an audit log — it lives in a telemetry store with short retention and looser access, and it can contain attacker-controlled text.

Two rules follow. Attribution facts belong in the control-plane log, so an incident narrative does not depend on telemetry retention. And never treat trace content as evidence of intent — it is partly written by whoever fed the agent its inputs. Join the two on task and session ids; do not merge their trust levels.

The fifteen-minute test — five questions your identity design must answer as queries

Run this against your own system today; it is the whole lesson as a checklist.

Which agent, and which version, performed this action? A query on the actor principal and a version field — not a Slack thread.
On whose behalf, and did that person consent? Subject claim plus the consent record.
What else did that identity do in the last 24 hours? Filter by actor principal. If your filter also returns four other agents’ work, you have a shared account.
What can I revoke right now, and what breaks? Name the exact identity, credential and consent grants, and the systems that lose access. Rehearse it.
What did it try and get refused? Denials over the same window. This is where you find the attempt you never noticed.

Why version matters as much as identity

An agent is not a fixed program. Change the system prompt, add a tool, swap the model, and behaviour changes without a code review in the traditional sense. "Agent X did this" is therefore ambiguous: agent X on Tuesday may be a materially different system from agent X on Monday.

Platforms are converging on versioning as a first-class concept — Foundry snapshots agent versions automatically, supports rollback and comparison, and can pin or split traffic across versions with selector rules. Pin the version in the audit record and your incident narrative becomes falsifiable: you can rerun that version against the same input.

Registries: inventory is a security control, not paperwork

You cannot audit agents you do not know exist, and shadow agents are the norm — anyone with a model endpoint and a laptop can create one. Both clouds now ship catalogues: AWS Agent Registry (GA August 2026) with approval workflows for publishing, IAM and OAuth access control, CloudTrail audit trails and Organizations auto-detection of AgentCore Runtimes and Gateways; Microsoft’s Entra Agent Registry, converging with Microsoft Agent 365 as the unified inventory, with Entra Agent ID providing identity and access management for discovered agents.

The question to ask of either is the one from the platform checklist: is it authoritative? Auto-detection and publish approval move a registry from "list" toward "control". A registry that merely records what someone remembered to add tells you about your best-behaved agents only.

What "unrevokable" costs in practice

Consider the sequence in a shared-account design: an anomaly appears at 01:58, the on-call engineer cannot tell which agent is responsible, disabling the account would stop payroll integration and three other agents, so the decision escalates. Every minute of that escalation is a minute the anomaly continues.

Now the per-agent design: the actor principal is in the alert, that one identity is disabled, one agent stops, and the remaining question is scope of impact — which the audit record already answers. Same incident, two different lengths, and the difference was decided months earlier at identity design time. That is the argument to make to whoever owns your IdP.

Tool: Agent Incident Tabletop — Run the fifteen-minute test under pressure: the Incident Tabletop simulator hands you an agent anomaly and asks who acted, on whose authority, and what you can revoke without a second outage.

Interactive flashcard deck.

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.