AI Agent Attribution and Non-Repudiation Guide

When an AI agent changes a record, moves money or deletes a resource, most organisations can show that "a credential" did it, but not which agent, which run, which human authorised it, or that the record has not been altered since. Attribution answers "who acted and for whom"; non-repudiation makes that answer hard to deny later, for the agent operator, the user who delegated, and the organisation itself. This guide goes beyond logging: it covers how to make each agent action cryptographically bound to a distinct agent identity, a delegating principal and an approval, and how to keep that evidence verifiable outside the agent's control. It is written for identity architects, platform engineers and security teams who need agent activity to stand up in an investigation, a dispute or an audit. For what regulators expect a log to contain and how long to keep it, read the AI Agent Audit Trails for Regulators Guide first; this page assumes it.

Key takeaways

Attribution is only as fine as the identity model. If several agents share one API key or service principal, no amount of logging can say which agent acted; one identity per agent (and ideally per run) comes first.
Prove the delegation, not just the call. Use token flows that carry both identities, such as the RFC 8693 act claim, so the evidence shows the agent acting for a named user rather than the agent silently becoming that user.
Bind evidence with keys the agent cannot misuse. Proof-of-possession tokens (DPoP), signed requests (HTTP Message Signatures) and signed approval records turn "a token was used" into "the holder of this agent key sent this exact request".
The agent's own narrative is not evidence. Authoritative records must be written by the gateway, identity provider and target systems, then sealed with hash chains, trusted timestamps or a transparency log.
Non-repudiation lands on people and organisations. An agent cannot be held accountable; the record must always resolve to an accountable owner, a delegating principal and the policy that allowed the action.

Attribution and non-repudiation: what each means for agents

NIST SP 800-53 Rev. 5 control AU-10 asks for "irrefutable evidence that an individual (or process acting on behalf of an individual) has performed" defined actions. That phrase fits agents well: an agent is a process acting on behalf of someone, and the control's enhancements spell out the parts you need to build.

Property	Question it answers	What it takes for an agent	Related control
Identification	Which agent and which instance acted?	A distinct, registered agent identity, versioned, with a run or session identifier	IA-9, IA-4
Delegation attribution	On whose authority?	The human or job principal carried through every hop, not replaced by the agent	AU-10(1) Association of Identities
Integrity binding	Is this exactly what was sent and done?	Signatures or MACs over the request, the approval and the log record	AU-10(2), AU-9(3)
Chain of custody	Who reviewed or released it, and has anyone touched it since?	Reviewer credentials kept with the record; sealed storage with verifiable history	AU-10(3), AU-10(4)
Time	When, in an order everyone agrees on?	Synchronised clocks and, for high-value records, third-party timestamps	AU-8
Cross-boundary evidence	What happened in the partner's or provider's system?	Agreed correlation IDs and shared audit data across organisations	AU-16, AU-16(2)

Two limits are worth stating plainly. First, cryptography proves that a key was used, not that the key holder intended the outcome: a prompt-injected agent signs its malicious request just as cleanly as a legitimate one. Second, a model's reasoning is not reproducible on demand, so evidence must capture inputs, configuration and outputs at the time, rather than relying on replaying the run later. The OWASP Agentic AI Threats and Mitigations guide lists this problem as T8 Repudiation and Untraceability, and recommends comprehensive logging, cryptographic verification, enriched metadata and signed, immutable AI-generated logs.

Where attribution breaks today

Shared credentials: a team-wide model or SaaS API key used by several agents, notebooks and people. The target system sees one caller.
Borrowed credentials: the agent picks up whatever token is in its workspace. In the PocketOS database deletion, a coding agent used an account-scoped token it found in an unrelated file, and the provider honoured the delete as it would from any authenticated caller. Nothing in the request said "agent", let alone which task.
Impersonation flows: the agent exchanges the user's token for one that simply is the user. RFC 8693 is explicit that under impersonation the actor is given the subject's rights and the issued token keeps no separate record of the actor.
Self-reported activity: transcripts and "what I did" summaries written by the agent. In the PocketOS case the agent's explanation was its own account; investigators still needed platform records.
Broken correlation: the model call, the tool call and the downstream API call each have their own IDs, and nothing joins them.

Attackers rely on the same gaps. Stolen agent tokens map to ATT&CK T1528 Steal Application Access Token and are replayed as T1550.001 Application Access Token; when the stolen material is a cloud identity the activity looks like T1078.004 Cloud Accounts. Each looks legitimate unless the credential is bound to something the thief does not hold.

Layer 1: distinct identities for agent, run and principal

Design the identifiers first, because every later control signs or records them.

Identifier	Granularity	Where it comes from	Why it matters for evidence
Agent identity	One per agent definition (name, owner, purpose, version)	Agent registry; workload identity or dedicated client registration	Names the accountable owner; appears in sign-in and audit logs of target systems
Agent instance or run	One per execution	Orchestrator; short-lived credential issued per task	Separates two runs of the same agent; a credential issuance event with a task ID links run to downstream effects
Delegating principal	The user, service or schedule that started the work	Original user token subject, ticket ID, scheduler job ID	Answers "on whose authority"
Conversation or session	A multi-turn interaction	OpenTelemetry `gen_ai.conversation.id`	Joins model calls and tool calls across turns
Tool call	One per tool invocation	`gen_ai.tool.call.id` where the model or provider supplies one	Ties the model's decision to the specific action

Agent versus session identity: keep a stable agent identity for ownership and recertification, and issue session-scoped credentials for each run. See Agent Identity vs Agent Session Identity.
Telemetry vocabulary: the OpenTelemetry GenAI semantic conventions (now maintained in their own repository, status Development) define create_agent, invoke_agent and execute_tool spans with gen_ai.agent.id, gen_ai.agent.name and gen_ai.agent.version. gen_ai.tool.name is required on tool spans. Pin the version you emit, since Development conventions can change.
Owner of record: every agent identity needs a named human owner. Non-repudiation in practice means the owner cannot later claim the agent was "nobody's".

Layer 2: evidence of delegation and approval

RFC 8693 OAuth 2.0 Token Exchange distinguishes delegation from impersonation. With delegation, the agent keeps its own identity and the issued token shows it acting for the subject: the sub stays the user and the act claim names the agent. The outermost act is the current actor and nested act claims record prior actors, which gives a verifiable user to agent to sub-agent chain. The RFC treats prior actors as informational, so access decisions use the top-level claims and the current actor, but for evidence purposes the nested chain is exactly what an investigator wants. The may_act claim lets the user's token state in advance which party may act for them, and the authorisation server can check it at exchange time.

Log decoded claims, not tokens: record sub, the act chain, aud, scopes and token ID (jti) at the gateway; never store the bearer token itself.
Attenuate at each hop: each exchange should narrow scope and audience, so the evidence also shows what the agent was allowed to do. See Delegation Chains and Attenuated Authority for AI Agents and the OAuth Token Exchange and Delegation Guide.
Bind approvals to the action: a human-in-the-loop approval should record the approver's authenticated identity, the time, and a hash of exactly what was shown (the proposed tool name and parameters). Then the executed request can be checked against the approved hash. An approval that only says "approved run 4411" proves little.
Record the policy decision: keep the policy engine's decision, the policy version and the reason. "Allowed by rule X version 12" is the organisational half of non-repudiation.

The NIST NCCoE concept paper on software and AI agent identity and authorisation (February 2026) asks the same questions as open problems: how to ensure non-repudiation for agent actions with binding back to human authorisation, and how agents can log actions and intent in a tamper-proof, verifiable way. Treat current designs as good practice that will evolve, and keep an eye on the IETF Agent Identity and Authorisation Drafts Tracker.

Layer 3: cryptographic binding of each request

Bearer tokens prove possession of a string, which anyone who copies it shares. Binding the request to a private key held by the agent runtime raises the evidential value considerably.

Mechanism	What it binds	Evidence value	Limits
Bearer token with `act` chain	Identities and scopes, signed by the authorisation server	Shows delegation and authority	A stolen token can be replayed by anyone
DPoP (RFC 9449)	Access token to a client key via `cnf.jkt`; each proof JWT carries `htm`, `htu`, `iat`, `jti` and `ath`	Only the key holder could have sent that method to that URI at that time; `jti` supports replay detection	Does not sign the request body; the key must be protected
Mutual TLS with workload certificates	The connection to a workload identity	Strong caller authentication per connection	Integrity is per TLS connection, not end to end through proxies
HTTP Message Signatures (RFC 9421)	Chosen components such as `@method`, `@target-uri`, selected headers and a content digest, with `created`, `expires`, `nonce` and `keyid`	A storable signature over the request itself that survives intermediaries	Needs agreement on covered components; a keyed MAC does not provide non-repudiation, an asymmetric signature does
Signed action records	A canonical record of the tool call, signed by the gateway or tool server	The executing system attests what it did	Trust rests on the signing service and its key custody

Asymmetric where it matters: RFC 9421 supports both digital signatures and keyed MACs. Only an asymmetric signature lets a third party verify without being able to forge, which is what non-repudiation needs.
Keys outside the agent's reach: sign in the runtime or sidecar using a key in a KMS, HSM or platform keystore, never a key file the model's tools can read. If the agent can read its own signing key, a prompt injection can exfiltrate it.
Request body coverage: RFC 9421 does not cover message content directly and relies on a content digest field; include it for state-changing calls.

See the DPoP Guide for implementation detail.

Layer 4: sealing and preserving the evidence

The regulator-facing guide covers write-once storage and retention. For non-repudiation, add mechanisms that let an outsider verify the record without trusting your administrators.

Hash-chain records at the point of collection: each record includes the hash of the previous one, so deletion or reordering is detectable. Protect the chain head with a signature (AU-9(3)).
Trusted timestamps for high-value records: an RFC 3161 Time-Stamping Authority signs a token over a hash of your record (the messageImprint) with a UTC genTime and a unique serial number. The TSA sees only the hash, so record contents stay private. Timestamp batch roots hourly, and individual records for payments or destructive actions.
Transparency logs where several parties must agree: RFC 9943, the SCITT architecture (Proposed Standard, June 2026), defines signed statements registered with a transparency service that returns a receipt verifiable offline, over an append-only, non-equivocating log. It is written for supply chains, but the pattern fits agent attestations shared between an operator, a customer and a model provider. RFC 9943 is clear that transparency holds issuers accountable but does not prove a statement is accurate.
Separate custody: the team that runs agents should not be able to rewrite the evidence store. Use a separate account or tenant with its own administrators.
Verify routinely: a seal nobody checks fails silently. Run scheduled verification of chains, signatures and timestamps, and alert on gaps.

How to implement

Inventory and split credentials (weeks 1 to 4): list every credential agents use, then replace shared keys with one identity per agent. Measure how many agent actions are attributable today; this is your baseline.
Route actions through a gateway (weeks 3 to 8): put tool and API calls behind an agent or MCP gateway that authenticates the agent, records decoded claims and emits OpenTelemetry spans with agent, conversation and tool call IDs.
Switch impersonation to delegation (weeks 6 to 12): move on-behalf-of flows to token exchange with act claims. Pilot with one agent and one downstream API; confirm the target system's own audit log shows both identities.
Add proof of possession (weeks 8 to 16): enable DPoP or mTLS-bound tokens for high-risk tools first (payments, deletes, privilege changes). Run in log-only mode to find clients that fail, then enforce.
Bind approvals and seal records (weeks 10 to 20): hash approved parameters, compare at execution, and add hash chaining plus timestamps for the evidence store.
Test it as an investigator would: pick a past action at random and reconstruct agent, run, principal, approval, policy and outcome using only platform records. Time it.
Rollback: keep the previous token flow available behind a feature flag per agent during enforcement; if a downstream system rejects bound tokens, revert that agent, not the whole estate, and record the exception with an expiry date.

Decision guidance

Situation	Minimum evidence	Add when
Read-only internal agent, low impact	Distinct agent identity, gateway logs with correlation IDs	It starts reading personal or regulated data
Agent acting for a named user in SaaS or internal APIs	Token exchange with `act`, decoded claims logged, target system audit logs retained	Actions are disputed or customer-facing
Destructive, financial or privilege-changing actions	Proof-of-possession tokens, approval bound to parameter hash, signed action record, timestamp	Always for this tier
Agents acting across organisations	Shared correlation IDs, signed requests (RFC 9421), agreed audit sharing (AU-16)	Multiple parties may need to prove their side; consider a transparency service

Small organisations: start with one identity per agent, a single gateway and the target platforms' native audit logs stored in a separate locked account. That alone fixes most attribution gaps. Large or regulated organisations: add proof of possession, signed approvals and an independent evidence store, and agree evidence formats with key suppliers and model providers in contracts.

Detection and measurement

Unattributed action alerts: any state-changing call from an agent identity with no run ID or delegating principal.
Delegation anomalies: tokens with unexpected act chains, chains longer than your design allows, or an agent appearing as sub where it should be the actor.
Replay signals: repeated DPoP jti values, proofs from a key that does not match cnf.jkt, or valid tokens used from new networks.
Approval mismatches: executed parameters whose hash differs from the approved hash.
Seal failures: broken hash chains, signature verification failures or missing timestamp intervals.

Metric	Target direction
Share of agent actions attributable to agent, run and principal from platform records alone	Towards 100% for state-changing actions
Agent credentials shared by more than one agent or person	Zero
High-risk tool calls using sender-constrained tokens	100% after enforcement
Median time to reconstruct a sampled agent action end to end	Falling; under one hour
Evidence store verification failures unresolved after 24 hours	Zero

See Detection Engineering for AI Agents Guide for building these detections.

Framework mapping

Framework	Reference	How it applies
NIST SP 800-53 Rev. 5	AU-10, AU-10(1) to AU-10(4)	Non-repudiation, association of identities, validating bindings, chain of custody
NIST SP 800-53 Rev. 5	AU-3, AU-8, AU-9(3), AU-16	Record content, timestamps, cryptographic protection of logs, cross-organisational logging
NIST SP 800-53 Rev. 5	IA-9, AC-6(9)	Authenticating services and agents; logging privileged functions
NIST CSF 2.0	PR.AA-01, PR.AA-03, PR.PS-04, RS.AN-03	Managed identities, authentication, log generation, incident analysis
ISO/IEC 27001:2022 Annex A	5.16, 8.15, 8.17	Identity management, logging, clock synchronisation
CIS Controls v8.1	5.5, 8.2, 8.4, 8.5	Service account inventory, audit log collection, time synchronisation, detailed logs
OWASP Agentic AI Threats and Mitigations	T8, T9	Repudiation and untraceability; identity spoofing and impersonation
MITRE ATT&CK v20	T1528, T1550.001, T1078.004	Token theft and replay that attribution controls must expose

Common failure patterns

One key, many agents: a single model or SaaS key shared by a team. Every action resolves to the key, not the agent. See AI Agent Identity vs Service Account.
Credentials found, not issued: agents that can read tokens from repositories or environment files will use them, as the PocketOS case showed, and those actions are attributed to whoever created the token.
Impersonation by default: on-behalf-of flows that issue a plain user token, so the target system records the human as the actor.
Signing keys inside the sandbox: keys the agent's tools can read, so a successful injection both acts and signs as the agent.
Approval without content: human approvals that record "yes" but not what was approved, making later disputes unresolvable.
Unverified seals: hash chains and timestamps generated but never checked, discovered broken only during an investigation.

Practitioner checklist

Give every agent its own identity with a named owner, and issue per-run credentials where the platform supports it.
Remove shared and human-owned credentials from agent workspaces and repositories.
Use token exchange with act claims for on-behalf-of actions; ban impersonation flows for agents unless an exception is recorded.
Log decoded token claims, policy decisions and approval hashes at the gateway, never raw tokens.
Emit OpenTelemetry GenAI spans with agent, conversation and tool call identifiers, and pin the convention version.
Sender-constrain tokens (DPoP or mTLS) for destructive, financial and privilege-changing tools.
Keep signing keys in a KMS, HSM or keystore the agent's tools cannot read.
Hash-chain and timestamp evidence records in a store the agent operators cannot modify, and verify seals on a schedule.
Run a quarterly reconstruction drill on a random agent action and track the time taken.

AI Agent Attribution and Non-Repudiation: Proving Which Agent Acted and on Whose Authority