Executive briefThree agents used one key and no one owned the action

A research agent, scheduling agent and payment-preparation agent all called enterprise tools with one service-account key. When a supplier record changed, the audit trail could show the shared account and little else. Security could revoke the key, but only by stopping every agent. The team could not prove which runtime acted, which user or workflow supplied the mandate, whether the model had only prepared an action, or which tool committed it.

A registry name is discoverability, not identity. A model name is provenance, not the executing subject. A user's login proves a user session, not every later action in a multi-agent chain. A shared API key authenticates possession of one secret, not the business authority, case, purpose, audience or transaction that should govern a request. Downstream services need a verifiable subject and enough correlated context to decide whether this specific action is permitted now.

The correct starting point is mature workload and federated identity, not a novel legal category for agents. SPIFFE, OAuth, OpenID Connect, short-lived workload credentials, resource-specific policy and transaction authorisation provide much of the substrate. The new operating work joins an ephemeral task to a principal mandate, delegation chain, model and tool provenance, time and transaction envelope, revocation state and external effect.

This paper proposes a fourteen-field Agent Identity Envelope, six-part Identity Separation Map, Delegation Narrowing Law and Identity Receipt. Together they make an agent request attributable and rejectable at the relying service. They implement runtime evidence for enterprise decision rights without repeating a rights ledger or pretending authentication is authorisation.

The strongest rival: use existing service identity

Most enterprises do not need an agent-specific credential format. Existing service accounts, workload identity, OAuth token exchange, policy decision points and transaction controls can identify agent runtimes. A bounded agent running inside one stable service may use that service identity with task, case and mandate attributes. Inventing another identity silo can weaken validation and lifecycle management.

The additional work appears when tasks are ephemeral, user or enterprise mandates change, agents delegate across trust domains, model and tool versions vary, or an external action needs transaction-specific approval. The design objective is not to name everything twice. It is to retain separate identities where attribution, selective revocation, provenance, policy or business effect differs.

Identity Separation MapCorrelate six subjects without collapsing them

The human or organisational principal is accountable for the mandate. It may be a user, role, service owner or enterprise function. The workflow or case identity records the business context whose state constrains action. The agent workload instance is the cryptographically attestable runtime making the request. The model and configuration identity supplies provenance for the inference component. The tool or service identity establishes the relying party and its trust boundary. The receiving system and action record identify the durable business effect.

These identities often change independently. One model version can serve many workloads. One workload can process many authorised cases. A case can move to a different runtime after failure. A tool can be replaced without changing the principal. A committed payment receives an action identifier that must survive model, workflow and infrastructure changes. Collapsing these identities into a friendly agent name destroys the ability to explain or selectively contain the system.

The workload subject should be specific enough for attribution and quarantine, but not so volatile that every request becomes impossible to correlate. A stable service identity plus an ephemeral task instance may be appropriate inside one controlled platform. Cross-domain or high-consequence actions may need a task-specific subject. The issuer attests the binding between subject and runtime; it does not assert arbitrary business authority merely by issuing an identity.

Agent Identity EnvelopeFourteen runtime fields answer who may do what now

NIST SP 800-63 Revision 4 is current for digital identity proofing, authentication and federation of users, but its top-level guidance says it does not explicitly address machine-to-machine authentication or API access on behalf of subjects. Its issuer, subject, assertion, audience and relying-party disciplines are useful inputs, not a complete agent workload scheme. SPIFFE addresses workloads in dynamic environments through trust-domain identities and short-lived verifiable identity documents.

An issuer should make only assertions it can support. A workload platform may attest runtime, namespace, image and task binding. It usually cannot decide the business value limit or whether a customer case remains open. Those attributes come from authorised policy and workflow sources, and the relying party evaluates their current state. Identity architecture must preserve which authority made each claim.

Delegation Narrowing LawEvery hop intersects, none expands

A principal may authorise a planner to organise a trip. The planner can ask a scheduling worker to propose calendar slots, but cannot transfer access to finance tools simply because the planner has them. The worker receives a credential whose audience is the calendar service, resource is the named calendar, purpose is the trip, scope is availability and draft event, time ends with the session, and attendee set comes from the case.

The intersection is evaluated when the credential is minted and again at the relying party. Upstream mandate sets the outer boundary. Workload policy constrains which tasks this runtime may perform. Resource policy applies tenant, data and service rules. Transaction policy checks object, value, counterparty, rate and separation. Current state confirms that the case, user session, approval, provider and policy remain valid. A missing purpose or stale case state causes denial rather than default inheritance.

Delegation is not transitive by implication. A planner that can read a customer record and call a summariser does not thereby authorise the summariser to read the record directly. The planner may pass selected content under a data policy, or the issuer may exchange its credential for a narrower resource token after checking the delegation edge. Both paths are explicit and receipted.

One important negative control is valid identity but unauthorised action. An A2A remote agent can authenticate within a trusted partner domain and still lack authority for an internal customer resource. An MCP server can validate the client's credential and still reject a tool call whose case, purpose or transaction scope fails. Authentication allows the policy decision to start; it does not determine the result.

Credential exchange and proofDo not pass a user's bearer token through the chain

RFC 8693 defines OAuth token exchange, including subject and actor semantics. RFC 8707 lets an authorisation request identify the protected resource. Together they support an exchange service that validates the principal session, agent workload, delegation edge and resource request, then issues a short-lived credential with narrower audience, scope, purpose and transaction context.

The exchange service should not give an agent the user's original secret. Bearer-token forwarding lets any compromised hop replay the broad token, makes downstream attribution ambiguous and allows token lifetime to outlast the task. Exchange also provides a control point for current policy, case status, cumulative exposure and mandate revocation. Each exchange receives its own identifier so the final receipt can reconstruct the chain without storing reusable secrets.

RFC 8705 binds access tokens to mutual TLS certificates. RFC 9449 provides application-level Demonstrating Proof of Possession, binding requests through a signed proof that includes method and URI and can use freshness values. The design chooses a sender constraint appropriate to the transport and threat model. Proof binding does not expand business authority; it makes theft and replay harder for the authority already present.

RFC 9700 is the current OAuth security best current practice. It reinforces replay prevention, privilege restriction and safer client behaviour. JWT, defined by RFC 7519, supplies an interoperable claim set, but accepting a signed JWT without validating issuer, audience, time, algorithm, key, resource and context is not identity assurance. A token format never substitutes for relying-party validation.

Transaction identityA valid workload can still lack authority to commit

Permissions are verbs with effects. Read, prepare, recommend, write, commit, compensate and administer should not share one broad scope. A payment agent may read an approved invoice and prepare a draft. Commitment requires a transaction authorisation naming amount, currency, beneficiary, account, purpose, case, expiry and approving principal. The payment service verifies that signed object before creating the external effect.

Separation of duty is enforced by identity, policy and system flow, not by placing two buttons on one screen. The preparing runtime cannot mint the approval it needs. The approver sees the transaction object and cannot silently alter it after signing. The commit service checks approval, workload subject, current policy and cumulative limit. A recovery principal may compensate an erroneous payment without receiving permanent payment-administration scope.

Transaction identity also controls cumulative behaviour. Ten individually permitted actions can exceed an authorised total, rate or counterparty concentration. The transaction envelope therefore joins per-action limits with time-window exposure and workflow state. A relying party reserves or updates the cumulative value atomically enough to prevent concurrent agents from each observing the same unused limit.

The identity receipt is written by the relying system or an independent witness, not solely by the acting agent. It records request and credential identifiers, subject, issuer, principal, delegation edge, case, purpose, action, resource, policy decision, tool result, external effect and terminal status. A failed, denied, contained or abandoned attempt also receives a terminal receipt so gaps cannot disappear from history.

Revocation and containmentShort-lived does not mean irrevocable

Short credential lifetime reduces the window of misuse, but a consequential mandate may need to stop before expiry. The identity system must propagate principal session termination, workflow cancellation, key compromise, policy change, workload quarantine and transaction revocation to exchange and relying services. Critical resources may query live status or consume signed revocation events; lower-risk paths can use short expiry and bounded cache rules.

Long-running tasks need explicit reauthorisation. When an agent pauses for user input, resumes after a deadline or survives beyond its maximum task duration, it must not refresh a token as if nothing changed. Refresh rechecks the principal mandate, case state, workload health, policy version, cumulative exposure and resource conditions. Failure moves the workflow to a safe state with a terminal receipt.

Compromise containment should be selective. A proof-bound token limited to one audience, case and transaction constrains replay. Quarantining one workload instance need not disable every agent. The issuer rotates or revokes workload credentials, exchange denies new downstream tokens, relying parties reject affected identifiers, tools halt new commitments, and operations reconcile actions already in flight.

Attribution must survive the loss of the acting runtime. Independent policy, exchange, gateway, tool and receiving-system evidence can corroborate the chain. If the only log comes from the compromised agent, it cannot be the sole witness for identity or effect. Evidence retention follows the business and regulatory need without preserving live secrets.

Protocol boundaryDiscovery metadata is not business authority

MCP specification revision 2026-07-28 defines current host, client, server and authorisation behaviour. Its client and server information metadata is self-reported and intended for display, logging and debugging, not security decisions. An MCP tool server should validate issuer, subject, audience, resource, purpose, tenant, case, scope, time, proof binding and transaction limits before invocation.

A2A 1.0.0 defines agent cards, messages, tasks and authentication declarations for cross-agent interaction. An agent card can state how a remote endpoint expects authentication. It does not prove the authenticated agent's authority to access an enterprise customer record. The enterprise boundary validates the remote trust domain, delegation edge, resource policy and business mandate independently.

Protocol compatibility is transport evidence. Identity proves a subject within a trust system. Authorisation decides the action. Delegation explains how a principal's mandate reached the subject. Accountability connects the decision to external effect and owner. Keeping those claims separate prevents a successful handshake or signed agent card from becoming an implicit business approval.

Ten worked casesApply envelope, narrowing, relying party and receipt

Each case completes the relevant envelope, separates the six identities, applies the narrowing law, names the relying party and produces or withholds an identity receipt.

Interactive instrumentAgent Identity and Delegation Gate

Load a named case or select the closest runtime conditions. The result is one of five identity designs and exposes the broken or narrowing edge. It is not a trust score.

Operating cadenceRun identity as a revocable control service

At design, business and security owners define principals, mandate sources, cases, workload subjects, trust domains, relying services, scopes, transaction limits and receipts. Platform teams reuse established identity and token standards where possible. New formats require a demonstrated semantic gap.

At issuance, the workload platform attests the runtime and the mandate service supplies current business context. Exchange intersects upstream mandate with workload, resource, transaction and state policy. Credentials are short-lived, audience-specific and sender-constrained where the threat model requires it.

At every relying party, cryptographic verification precedes audience, resource, principal, delegation, purpose, scope, time, transaction and separation checks. A valid subject can still receive a denial. The tool or receiving system writes the action and terminal identity receipt.

During operation, teams monitor issuance anomalies, generic audiences, broad scopes, failed proof checks, expired-task refresh, delegation breaks, transaction-limit conflicts and missing receipts. Keys, trust bundles, issuer metadata, exchange policy and relying-party caches have explicit rotation and stale-state handling.

On change or incident, revocation reaches exchange and resource decisions, affected workloads are quarantined, in-flight actions are stopped where safe, completed effects are reconciled and every path closes with a receipt. Shared credentials and agent-generated sole-source logs are treated as attribution gaps.