The Agent Passport: Identity and Authority for AI Systems

Giving an AI agent a user’s long-lived API key is not delegation. It is credential sharing with an unpredictable caller. Once the key reaches a tool, the resource server may know the user account but not which agent acted, which task justified the action, who approved it, or whether the authority should still be valid.

A production system needs an agent passport: a verifiable identity for the running workload, a delegation chain from a responsible principal, a narrowly described permission, and evidence that the permission was valid at the moment of action. The passport is not one token or a new universal standard. It is an architectural pattern built from established identity, authorization, policy, and audit controls.

Separate the actors before writing policy

An agent transaction can involve several distinct principals:

• resource owner: the person or organization whose data or money is affected;
• delegator: the principal authorizing a task;
• agent instance: the logical agent run assigned to the task;
• workload: the specific process, container, device, or service executing it;
• operator: the organization running the service;
• approver: a person or policy service authorizing a consequential step;
• tool and resource server: the systems enforcing access and changing state.

These identities must not collapse into one “service account.” Authentication answers who or what is presenting a credential. Authorization answers whether that principal may perform this action on this resource under current conditions. Delegation explains why the agent may exercise some authority belonging to another principal.

The model’s self-description is not identity. Text such as “I am the finance assistant” can be generated or injected. Identity must be bound cryptographically or through a trusted execution and issuance path to the workload making the request.

Give the workload its own short-lived identity

Assign a stable logical identity to each agent class and a traceable instance identity to each run. The executing workload should obtain short-lived credentials at runtime, not read a shared secret embedded in source code, an environment image, or a prompt.

SPIFFE is one open standard that can support this layer. A SPIFFE ID uniquely identifies a workload within a trust domain, while SVIDs provide cryptographically verifiable identity documents. SPIFFE does not decide business authorization and assumes adequate workload isolation; it is therefore a useful identity primitive, not a complete agent-security solution.

Cloud-native service identities, hardware-backed device identities, or a carefully operated internal certificate authority can serve similar roles. Whichever mechanism is chosen, require:

• attestation before issuance;
• automatic rotation and short validity;
• audience or destination binding;
• key isolation from model context and logs;
• distinct production, staging, and development trust domains;
• immediate disablement of a compromised workload class.

Do not let all agent replicas share one untraceable bearer token. An incident responder must be able to answer which workload received which credential and which calls it made.

Express authority as a constrained task

Roles such as admin or finance-agent are too broad for autonomous execution. Define an authorization envelope with at least:

The envelope should be machine-readable and enforced at the resource boundary. OAuth 2.0 Rich Authorization Requests, RFC 9396, provides a standard authorization_details structure for carrying fine-grained authorization data. It does not define your domain’s action vocabulary or automatically make a request safe; the authorization server and resource server must agree on semantics and enforce them.

At every handoff, authority must stay equal or shrink. A research sub-agent may receive permission to read selected files, not the parent agent’s permission to send mail. A scheduler may receive a request to hold a slot, not a transferable user credential.

Preserve delegation instead of impersonating the user

RFC 8693 defines OAuth token exchange, including delegation and impersonation semantics. In delegation, the actor can remain visible as acting on behalf of another subject. In impersonation, the downstream system may treat the intermediary as the subject. Agent systems should prefer explicit delegation when the downstream architecture supports it because the audit trail retains both the user and the actor.

A useful delegated token or equivalent capability should carry:

• subject and actor identities;
• intended audience and resource;
• narrow action scope or authorization details;
• task or case identifier;
• issuance and expiry;
• parent delegation identifier;
• assurance or approval reference when needed.

Token exchange is not a complete trust model. RFC 8693 leaves local policy, revocation behavior, and many trust decisions to the deployment. Do not assume that exchanging a token automatically prevents authority amplification.

Use sender-constrained access tokens for high-value paths. RFC 9449 DPoP binds a token to a public key and requires proof of possession on requests, reducing the usefulness of a stolen bearer token. Mutual TLS is another established option. Sender constraint does not stop an authorized but compromised agent from misusing its valid authority, so action policy remains necessary.

Put policy enforcement at every consequential tool

Prompt instructions are not an enforcement point. The model can propose an action, but a deterministic gateway and the resource server must decide whether to execute it.

A robust path has:

1. policy information: subject, actor, tenant, record state, risk, approval, time, and task;
2. policy decision: allow, deny, or require an additional control;
3. policy enforcement: the gateway blocks the tool call unless the decision and context match;
4. resource enforcement: the target API validates the token, audience, operation, limits, and record version again.

This follows the zero-trust principle in NIST SP 800-207: do not grant implicit trust based on network location; protect resources and make authorization decisions for access. For multi-cloud application identities, NIST SP 800-207A adds guidance around identity-tier policies. Neither publication is an AI-agent-specific authorization standard, but both provide applicable architecture.

Reauthorize at commit time. A plan approved five minutes ago may be stale because the user revoked permission, the amount changed, another process edited the record, or the credential expired. The final write should bind the approved preview to a content hash or expected version. See Designing Tool Permissions for AI Agents for the broader tool boundary.

Concrete example: an agent issuing a customer refund

Suppose a support agent proposes a 1,200,000 IRR refund:

1. The employee signs in and opens case CASE-934.
2. The orchestrator creates agent run refund-review/7f2a with its own workload identity.
3. A token service exchanges the employee’s session authority for a 15-minute, audience-bound capability that can read one order and propose a refund up to 1,500,000 IRR.
4. The agent retrieves the order. The resource server validates tenant, audience, actor, subject, and order scope.
5. The model produces a typed proposal with the reason, amount, and evidence. It cannot issue the refund.
6. The employee reviews an immutable preview. Approval records the exact order version, amount, destination payment method, and policy version.
7. A new one-use capability permits refund.execute only for that approved tuple.
8. The payment service rechecks that the order is not already refunded and consumes an idempotency key.
9. The ledger records subject, actor, approver, delegation chain, request hash, policy decision, and authoritative result.

If the employee changes the amount after approval, the order version moves, the capability expires, or revocation arrives, the payment service denies execution. The agent cannot “explain” its way around the check.

Defend against confused deputies and identity laundering

Common failure modes include:

• prompt injection: untrusted content asks the agent to use its real credentials;
• confused deputy: a tool with authority acts for an attacker who lacks it;
• token passthrough: one service forwards a token to an unintended downstream audience;
• identity laundering: delegated actions appear as if the human performed them directly;
• authority amplification: a child agent receives broader rights than its parent;
• replay: an intercepted approval or token is reused;
• cross-tenant leakage: a correct action is applied to the wrong customer boundary;
• orphaned agents: identities remain active after a project, employee, or deployment ends.

Validate token audience at every resource server and never use an upstream token as a generic downstream credential. Bind approvals to exact parameters, enforce tenant context independently of model output, and make delegation graphs queryable. The IETF’s RFC 9700, OAuth 2.0 Security Best Current Practice, recommends restricting token privileges and audience and using sender constraints to reduce replay of stolen tokens.

Make revocation and incident response operational

Short lifetimes reduce exposure but do not replace revocation. Design several kill switches:

• revoke one task capability;
• terminate one agent run;
• disable a workload identity or deployment version;
• remove one connector or tool;
• block an action class across the tenant;
• suspend all agent writes while preserving read-only investigation.

Measure the time from revocation decision to denial at every enforcement point. Cached decisions, offline workers, queued actions, and long-running workflows must receive the change. On restart, a workflow should reacquire authority rather than reuse an expired credential from persisted state.

Keep secrets out of prompts, transcripts, traces, and durable histories. Store references to a credential broker, not raw refresh tokens. Rotate keys after suspected leakage and retain enough evidence to identify affected actions without retaining unnecessary personal data.

Audit decisions, not hidden reasoning

An effective audit record captures:

• authenticated subject, actor, workload, and tenant;
• task and delegation parent;
• requested action and normalized parameters;
• policy input identifiers and version;
• decision, reason code, and required approval;
• approval identity, time, and bound request hash;
• tool response, record version, and idempotency key;
• revocation status at commit time.

Do not require or store private chain-of-thought. It is neither a reliable authorization control nor necessary audit evidence. Record externalized plans, typed proposals, policy decisions, and system effects. Audit-Ready AI covers evidence design in more depth.

Release gates for an agent identity plane

Before permitting production writes, require:

• 100% of agent calls use a distinct workload identity; no shared human API keys;
• 100% of resource servers validate issuer, signature, expiry, audience, tenant, and permitted action;
• no child delegation can exceed its parent in automated policy tests;
• one-use or idempotent enforcement for consequential writes;
• approval replay and changed-parameter tests fail closed;
• revocation reaches every online and queued enforcement path within the documented objective;
• expired credentials cannot resume a paused workflow;
• all privileged decisions produce complete, privacy-reviewed audit events;
• no critical prompt-injection, confused-deputy, cross-tenant, or token-exfiltration findings;
• an inventory owner and expiry date exist for every agent identity.

Track denial rate, policy-decision latency, expired-token attempts, revocation propagation, orphan identity count, scope-escalation test coverage, and actions without a complete delegation chain. A successful call rate alone can reward over-permissioning.

Standards status and uncertainty in 2026

NIST launched its AI Agent Standards Initiative in February 2026 and identified agent authentication and identity as active research areas. Its related NCCoE identity and authorization document was published as a draft concept paper, not a final agent-identity standard. This is useful evidence that the problem is receiving formal attention, but it should not be marketed as certification or settled consensus.

OAuth, DPoP, SPIFFE, and zero-trust standards supply mature building blocks. Agent-specific delegation vocabularies, cross-vendor policy exchange, identity for ephemeral sub-agents, and portable revocation are still evolving. Architect for explicit versions and interoperability tests rather than claiming one protocol has solved the entire stack.

Frequently asked questions

Does every agent run need a new identity?

The workload class can have a stable identity, but each run should have a unique traceable identifier and task-scoped authority. Higher-risk or cross-tenant runs may warrant distinct credentials.

Is role-based access control enough?

Usually not for consequential agent actions. Roles are useful coarse gates; add resource, action, purpose, value, time, task, tenant, and approval conditions.

Can an agent keep the user’s OAuth refresh token?

Avoid persisting it in the agent state. Use a credential broker or token service to issue short-lived, audience-restricted capabilities, and store only references needed to reacquire authority.

Who is accountable when the agent acts?

The organization must assign a responsible owner and preserve the delegator, actor, approver, policy, and outcome. Technical identity makes accountability inspectable; it does not transfer legal or managerial responsibility to the model.

Source notes

Sources reviewed and current as of July 30, 2026:

• RFC 8693: OAuth 2.0 Token Exchange — standards-track delegation and impersonation token-exchange semantics.
• RFC 9396: OAuth 2.0 Rich Authorization Requests — fine-grained authorization details; domain policy remains deployment-specific.
• RFC 9449: OAuth 2.0 Demonstrating Proof of Possession and RFC 9700: OAuth 2.0 Security BCP — sender constraint, replay reduction, audience and privilege restriction.
• NIST SP 800-207: Zero Trust Architecture — resource-focused authentication and authorization architecture.
• SPIFFE standards — open workload identity specifications; not business-authorization policy.
• NIST AI Agent Standards Initiative — 2026 program and draft work on agent identity; deliverables remain in development.