AI Agent Delegation Audit: Who Approved That Action?

An AI agent delegation audit checks, for every action an agent took, which person it acted for, which delegation allowed it, whether that delegation was still valid, and who approved anything sensitive.

Updated Nov 14, 2026

Request More Info

The short answer. A token’s actor chain shows who claimed to act for whom when the token was issued. It does not prove the delegation was enforced, still valid at the moment of use, or approved by the person.

The fix. Enforce delegation at the issuer, make it revocable by the person, and keep one tamper-evident record per action. That record is the delegation receipt an auditor reads.

What does an AI agent delegation audit check?

A delegation audit checks five questions for each action an agent performed for a person. For AI agent accountability, every answer must come from evidence, not from the agent’s own log. The table maps each question to the NIST SP 800-53 control an auditor tests.

Question	Evidence the auditor asks for	NIST SP 800-53 Rev. 5
Which agent acted?	A unique, authenticated agent identity	IA-9, AU-3
For which person?	The person and the agent, both named in the record	AU-3, AU-10(1)
Under which authority?	The delegation: scopes, resources, expiry	AC-3
Was it still valid?	A check at use time, not only at issue time	AC-3
Who approved the risky step?	The person’s decision, recorded with a time	AU-10

AU-3 requires each record to establish the event, time, place, source, outcome and every identity involved. AU-10 asks for evidence that a person, or a process acting for a person, performed the action.

Why a recorded token chain is not enough

A token chain is a history, not a control. RFC 8693, the OAuth token exchange standard, records delegation in the act claim. Our guide to OAuth token exchange shows the format. The RFC itself sets three limits that matter in an audit.

Prior actors do not count. Section 4.1 says nested act claims “are informational only and are not to be considered in access control decisions.” Only the current actor is checked.
No link between tokens. Section 2.1 says an exchange “does not create a tight linkage between the input and output tokens.”
No revocation by default. The same section says propagating revocation “is not a general property” of the protocol. Withdrawing consent may leave exchanged tokens alive.

A token is also a snapshot. It shows what was true when it was issued, not when the agent used it. A chain that a downstream service simply logs proves the claim was made, not that anyone checked it.

Recorded delegation compared with enforced delegation

Enforced delegation moves the decision to the issuer and the gateway, and keeps the person in control. Each row below compares one property.

Property	Recorded chain	Enforced
Authority	Whatever the token says	A stored grant the person approved
Scope	Set at issue, never narrowed	The narrowest of agent, grant and person
Revoking	Not passed on by default	Withdrawal stops issuing at once
Risky actions	Covered by the general consent	A fresh approval for each use, valid briefly
Evidence	Logs in each service, if any	One record per decision, chained

The Model Context Protocol (MCP) authorization specification points the same way. MCP servers “MUST NOT accept or transit any other tokens” than those issued for them, so a chain cannot simply be passed along.

What a delegation receipt per action contains

A delegation receipt is one audit record written at the moment of the decision. It ties the action to the delegation that allowed it. A receipt should name these items:

The parties. The agent, the person it acted for and any earlier agent in a hand-off.
The authority. The delegation, the resource and the scope or tool requested.
The decision. Allowed or refused, with the reason and the time.
The approval. For a sensitive step, the person’s decision and when it was made.
No secrets. No token, key or message text, so the record is safe to export.

Records should be chained so a removed or altered entry is detectable (NIST AU-9 protects audit information). Our SSO audit log page explains hash chains and daily digests.

Worked example: the Acme invoice assistant

Maria Lopez, an accounts payable clerk at Acme Corp, lets Invoice Assistant read invoices for her. The agent calls an invoice tool server at mcp.acme.example. The table shows what each step leaves on record.

Step	What happens	What the record shows
Consent	Maria approves “Read invoices” for 7 days	Delegation: Maria, Invoice Assistant
Read call	The agent calls `get_invoice`	Allowed: agent, Maria, scope, tool
Risky call	The agent asks to change bank details	Approval requested, then approved by Maria
Out of scope	The agent calls `approve_payment`	Refused: no granted scope
Revoke	Maria withdraws access	Delegation revoked; further calls refused

An auditor who asks “who approved that?” reads one record per row, each naming Maria and the agent.

How SSOGEN enforces delegation and records each decision

SSOGEN treats delegation as a stored, enforced record, not a claim inside a token. SSOGEN enforces each property below.

Consent first. The person signs in under the application’s own policy, then approves on a consent screen. The delegation covers only the scopes shown and lasts at most 30 days.
Intersected access. Effective access is the agent’s grant, the delegation and the person’s current access, checked every time a token is issued.
Consented hand-offs. An agent can pass work to another agent only when the person saw that hand-off on the consent screen. Each identity in the chain must pass policy.
Short, bound tokens. The token names the person as sub and the agent in act. It lasts about four minutes and is bound to the agent’s key with DPoP.
Approval for sensitive scopes. Sensitive scopes are never part of a delegation. The person approves each use on their Approvals page after a recent strong sign-in (OpenID CIBA).
Revocable by the person. People withdraw access in My Account, and administrators can revoke it. Issuing stops at once; access already issued ends within 5 minutes.
One record per call. The MCP Gateway records every allowed or refused tool call with the agent, the person, the resource, the scope, the tool and the result.

The audit log chains events with hashes and seals a daily digest. See AI agent identity for the full model and the MCP Gateway for per-call checks.

Questions people ask

What is on an AI agent delegation audit checklist?

The checklist confirms each agent has its own identity and a named owner. Each delegation must show the person, the scopes and an expiry. Sensitive actions need a recorded approval by the person. Withdrawal must stop the agent quickly. Every call needs a record naming the agent, the person, the scope and the result, in a log that shows tampering.

Who is accountable when an AI agent acts for a person?

Two people share accountability. The person who delegated answers for what they allowed, and the agent’s owner answers for how the agent behaves. The record must name both the person and the agent, as NIST SP 800-53 AU-3 requires. A log that names only the person makes the agent’s action look like the person’s own work.

Does the act claim prove who approved an action?

No. The act claim in RFC 8693 names the current actor, and nested entries are informational history. It shows that a token was issued for a delegation. It does not show that the person approved this specific action, or that the delegation was still valid when the agent used the token.

How fast should revoking a delegation take effect?

Revocation should stop the issuer from issuing tokens at once. Tokens already issued stay valid until they expire, so short lifetimes set the real limit. With tokens that last a few minutes, access ends within minutes. With long-lived tokens and no revocation check, an agent can keep acting for hours after consent is withdrawn.

Where to go next

ERP access. Letting AI agents into Oracle EBS covers policy and approvals for ERP owners.
Leavers. Offboarding AI agents explains what happens to agents when their owner leaves.
More explainers. The Learn hub lists related pages.

Sources, all read 2026-11-14:

RFC 8693, OAuth 2.0 Token Exchange, sections 2.1 and 4.1 (IETF).
NIST SP 800-53 Rev. 5, controls AC-3, AU-3, AU-9, AU-10, AU-10(1) and IA-9 (NIST OSCAL catalog, release 5.2.0).
MCP authorization specification, revision 2026-07-28, “Token Handling” (Model Context Protocol).
OpenID Connect Client-Initiated Backchannel Authentication Flow, Core 1.0 (OpenID Foundation).