]> Redthread Security

ben.le@redthreadsec.com

AI agents agent identity delegation HTTP message signatures transparency Autonomous software agents call APIs, tools and other agents on behalf of people and organisations. A party receiving such a call today can usually learn only that some bearer credential was presented. It cannot learn which organisation is accountable for the agent, which model, configuration and tools the agent is running, on whose behalf it is acting, or whether any of that has changed since it was approved. This document defines two signed objects and how they travel on HTTP requests. An Agent Passport binds an agent's public key to its accountable controller and to a digest of its build. A Delegation Receipt records one step of authority passing from a principal, through a delegator, to an agent; a chain of receipts can only narrow that authority. Requests carry both, and are signed with the agent's key using HTTP Message Signatures, so a relying party can check, without contacting the issuer per request, who the agent is, what it is running, on whose behalf it acts and what it may do.

Introduction Agents act for someone, through something. A relying party (an API, an MCP server, a payment service, a website) that receives an agent's request needs to answer four questions before it acts: Who is accountable for this agent? Is it the same agent, running the same build, that was approved? On whose behalf is it acting, and within what limits? Is any of that revoked? Existing mechanisms each answer part of this. OAuth 2.0 and Token Exchange convey authorisation to a client and can name an actor, but a client is not a build: the same client credential can sit in front of a different model, prompt or tool set. Workload identity, such as and the WIMSE workload identity token , identifies a running workload by where it runs, not by what it is. HTTP Message Signatures and the work of the IETF Web Bot Auth working group let a client prove possession of a key on each request, but say nothing about delegation. Sender-constrained tokens bind a token to a key, not to a delegation chain. Transaction Tokens carry context within one trust domain, not across organisations. This document composes these pieces into a profile for agents: An Agent Passport (): a JWT binding the agent's public key to a controller and a build digest. A Delegation Receipt (): a JWT naming a principal, bound to a delegate's key, carrying a scoped and time-limited subset of authority. Receipts chain, and each step may only attenuate. A request binding (): passports and receipts travel in HTTP header fields covered by an HTTP Message Signature made with the acting agent's key.

Relationship to Other Work Several individual drafts address agent authentication and authorisation. profiles WIMSE and the OAuth 2.0 family for agents. defines an authorisation protocol for agent access to resources, with HTTP message signatures and key discovery. This document is complementary to both and adds three things neither defines: Build binding. The passport commits to the agent's model, configuration and tools, and receipts can be bound to a build, so authority approved for one build does not carry over to another under the same key. Cross-organisation attenuation that the relying party verifies. Each step of a delegation chain is checked by the relying party against the step before it, with a test that never accepts a widening, and intersected with the principal's own access. Accountability of the controller. A controller's origin authorises the issuers that may vouch for its agents, so a relying party learns who is answerable for an agent, not only which key it holds. An authorisation server following or can issue root receipts as defined here, and a passport's holder key can be the key those protocols already bind.

Goals Identify the accountable party and the build, not only the key. Make delegation verifiable by the party acting on it, across organisational boundaries. Guarantee by construction that a delegation chain cannot widen authority. Allow verification without per-request contact with any issuer. Compose with existing identity providers rather than replace them.

Non-goals This document does not prove that an agent is actually running the build its passport names. The build digest is the issuer's assertion. Remote attestation of the runtime is out of scope; an issuer MAY condition issuance on such evidence. It does not define how a relying party decides whether to trust a controller, an issuer or a build. That is local policy. It does not define reputation or scoring.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Agent:

Software that takes actions, including calling other services, without a person approving each action.

Controller:

The organisation accountable for an agent, identified by an HTTPS origin it controls.

Issuer:

The entity that signs Agent Passports: the controller itself, or a third party the controller authorises ().

Build:

The properties that determine an agent's behaviour: model identifier, configuration (for example system instructions, tool allow-list and policy) and tool set.

Holder Key:

The key pair whose public half is bound into a passport, and whose private half the agent uses to sign requests and child receipts.

Principal:

The person or service on whose behalf a chain of agents acts.

Delegator:

The signer of a Delegation Receipt: an authorisation server acting for the principal (root receipts), or an agent passing on part of its authority (child receipts).

Delegate:

The agent a Delegation Receipt is bound to, identified by its holder key.

Relying Party (RP):

The party that receives an agent's request and verifies it.

Tool Attestation:

A signed statement by a third party about a tool the agent may call, for example an MCP server , such as an in-toto statement naming the tool's artifact digest.

Digest Object:

A JSON object {"alg": <name>, "val": <base64url without padding>}, where alg is a hash algorithm name from the IANA "Named Information Hash Algorithm Registry" (implementations MUST support sha-256). Digest Objects are compared by alg and by decoded bytes.

Overview

| | | |-- root receipt (to A) ------->| | | | | |-- child ---->| | | | | receipt | | | | | |== request ==>| | | | | passports B,A| | | | | receipts r,c | | | | | signed by B | | |<------------ status lists (cached) -----------| | | | |<- decision --| ]]>

Each agent generates a holder key and obtains a passport from an issuer, presenting its build. An authorisation server acting for the principal signs a root receipt bound to agent A's key. Agent A may pass part of that authority to agent B with a child receipt, signed with A's holder key. Agent B sends its own passport, the passports of every agent above it in the chain, and the receipts, and signs the request with its holder key. The RP validates every passport and receipt, matches the request against the leaf's grants, intersects with what the principal itself may do, and applies local policy.

Agent Passport

Format An Agent Passport is a JWT in JWS Compact Serialization . The JOSE header MUST contain typ with the value agent-passport+jwt, alg, and kid. Implementations MUST support EdDSA with Ed25519 , MAY support other asymmetric algorithms, and MUST follow ; none and symmetric algorithms MUST NOT be used.

Claims

iss (REQUIRED):

The issuer identifier, an HTTPS URL. The issuer's keys are found through its metadata ().

sub (REQUIRED):

The JWK Thumbprint URI of the holder public key, computed with SHA-256 .

cnf (REQUIRED):

A confirmation claim whose jwk member is the holder public key. Its SHA-256 JWK thumbprint MUST equal the thumbprint in sub.

agent_controller (REQUIRED):

The controller's origin, an HTTPS URL with no path, query or fragment, for example https://example.com.

agent_build (REQUIRED):

A JSON object describing the build. Members: model (REQUIRED): a string identifying the model, in the form vendor/model-id. config (REQUIRED): a Digest Object over the JCS canonicalisation of the agent's configuration object (). tools (OPTIONAL): an array of objects, each with id (a tool identifier; for an MCP server, its registry name) and optionally attestation, a Digest Object of the Tool Attestation the build was approved against. code (OPTIONAL): a Digest Object of the agent's own code artifact.

agent_aliases (OPTIONAL):

An array of other identifiers for the same agent, for example a SPIFFE ID or an identity provider's object identifier. Aliases are informational. An RP MUST NOT treat a match on an alias as verification of the passport.

iat, exp, jti (REQUIRED):

As in . exp minus iat MUST NOT exceed 86400 seconds.

status (RECOMMENDED):

A status reference as defined in .

An RP MUST reject a passport whose agent_build contains a member it does not understand, unless local policy names that member as ignorable.

Configuration Digest The configuration object is a JSON object defined by the agent framework. It SHOULD include at least the system instructions, the tool allow-list and any policy the agent enforces on itself. Hashing its JCS canonical form gives semantically identical configurations the same digest across implementations. Any change to model, config, tools or code is a new build and MUST result in a new passport. The build digest of a passport is the Digest Object, with alg sha-256, over the JCS canonicalisation of its agent_build claim. An RP that pins a build compares build digests.

Issuer Metadata An issuer publishes metadata at the well-known URI formed by inserting /.well-known/agent-passport-issuer between the host and path of its issuer identifier, as does for authorisation servers. The metadata is a JSON object with at least issuer (equal to the issuer identifier) and jwks_uri (an HTTPS URL of a JWK Set ). An RP selects the verification key by the passport's kid.

Controller Authorisation The controller publishes, at /.well-known/agent-controller on its origin, a JSON object:

An RP verifying a passport MUST check that iss is equal to agent_controller or appears in issuers. Sharing an origin is not sufficient. If the document cannot be retrieved and no cached copy is valid, the RP MUST treat the passport as invalid. An RP MAY cache the document for up to 24 hours, which bounds how long a withdrawn authorisation remains effective ().

Validation To validate a passport, an RP: Parses the JWS and checks typ, alg and kid against and local policy. Obtains the issuer's key () and verifies the signature. Checks iat, exp and the 86400-second limit, allowing clock skew of at most 60 seconds. Checks that the thumbprint of cnf.jwk equals sub. Checks controller authorisation (). If status is present, checks the referenced status (). Rejects unknown agent_build members, as described in . Applies local policy to agent_controller, agent_build and iss.

Delegation Receipts

Format A Delegation Receipt is a JWT with JOSE header typ set to agent-delegation+jwt, signed by the delegator. Header and algorithm requirements are as for passports ().

Claims

iss (REQUIRED):

The delegator. In a root receipt, the issuer identifier of the authorisation server that signed it. In a child receipt, the JWK Thumbprint URI of the delegating agent's holder key.

sub (REQUIRED):

The principal, as identified by the root receipt's authorisation server. Every receipt in a chain MUST carry the same sub as the root.

cnf (REQUIRED):

A confirmation claim whose jkt member is the base64url SHA-256 JWK thumbprint of the delegate's holder key.

act (OPTIONAL):

As in : the chain of acting parties, outermost the current delegate. Informational; chain validation does not depend on it.

dlg_parent (REQUIRED in a child receipt):

A Digest Object, with alg sha-256, over the ASCII bytes of the parent receipt's JWS Compact Serialization. It MUST be absent in a root receipt.

dlg_build (OPTIONAL):

The build digest () of the delegate's passport at the time of delegation. If present, the RP MUST reject the receipt unless the delegate's presented passport has the same build digest.

dlg_grants (REQUIRED):

A non-empty array of grant objects ().

dlg_limits (OPTIONAL):

An object with max_calls (a positive integer) and/or max_spend (an object with currency, an code, and amount, a decimal string).

purp (OPTIONAL):

A human-readable statement of why authority was delegated, as in . Recorded, not enforced.

aud (OPTIONAL):

The RPs the receipt is intended for. If present, an RP not listed MUST reject the receipt.

iat, exp, jti (REQUIRED):

As in .

status (RECOMMENDED):

A status reference as defined in .

An RP MUST reject a receipt containing a member of a grant object or of dlg_limits that it does not understand. Dropping an unknown restriction would widen authority.

Grants and Attenuation A grant object describes requests the delegate may make:

host (REQUIRED):

A DNS host name; or a wildcard, "*." followed by a DNS host name, matching that name's proper subdomains; or "*", matching any host. Host names are compared after lowercasing, removing one trailing dot and converting to A-labels . A "*." pattern whose remainder is a public suffix MUST be rejected. IP literals are permitted only as exact values.

port (OPTIONAL):

The TCP port. Default 443.

methods (OPTIONAL):

HTTP methods , case-sensitive. Default ["GET", "HEAD"].

paths (OPTIONAL):

An array of path specifiers, each either an exact path or a prefix pattern ending in /*, which matches the path before /* and any path below it. Default ["/*"].

tools (OPTIONAL):

Tool or operation names the delegate may invoke, for example MCP tool names. If present, a request that invokes a tool (as determined by the RP's protocol, for example an MCP tools/call) MUST name one of them.

max_body_bytes (OPTIONAL):

The largest request body allowed. Default 0.

A child receipt attenuates its parent if and only if all of the following hold: Every grant C in the child is covered by at least one grant P in the parent. C is covered by P when: Host: C.host equals P.host; or P.host is *; or P.host is *.D and C.host, with any leading *. removed, ends with .D. C.port equals P.port. C.methods is a subset of P.methods. Each path in C.paths is covered by some path in P.paths. If the P path is exact, the C path MUST be the identical exact path. If the P path is a prefix pattern p/*, the C path (exact or pattern) MUST equal p or begin with p/. If P.tools is present, C.tools is present and a subset of P.tools. C.max_body_bytes is no greater than P.max_body_bytes. Every limit present in the parent is present in the child with a value no greater, and the same currency. The child's exp is no later than the parent's. If the parent has aud, the child's aud is present and a subset of it. This test is conservative. It may reject some children that are in fact narrower, but it never accepts one that is broader. Implementations MUST NOT relax it.

Root Receipts A root receipt has no dlg_parent. It MUST be signed by an authorisation server acting for the principal, whose keys the RP obtains from its metadata , and whose authority to speak for sub the RP accepts by local policy. A root receipt is typically issued through Token Exchange : the subject token is the principal's, the actor token is the agent's passport, and requested_token_type is urn:ietf:params:oauth:token-type:agent-delegation. An agent MUST NOT issue a root receipt. Agent-to-agent delegation always uses a child receipt, so that every step is checked against the step before it.

Chain Validation Given the passports and the receipt chain presented with a request (), an RP: Checks that the chain has at most 8 receipts, ordered from root to leaf. Validates the root receipt's signature with its authorisation server's key, and its iat, exp, aud and status. For each child receipt, in order: Finds the presented passport whose sub equals the child's iss, validates that passport (), and checks that its holder key's thumbprint equals the previous receipt's cnf.jkt. Verifies the child's signature with that passport's cnf.jwk. Checks dlg_parent against the previous receipt, sub against the root's, and attenuation (). Checks iat, exp, aud and status. Checks that the leaf's cnf.jkt is the thumbprint of the key that signed the request. If the leaf has dlg_build, checks it against the acting agent's passport. Matches the request against the leaf's grants (). Checks limits: for every receipt in the chain, keyed by its iss and jti, the RP's count of requests (and spend) accepted under that receipt, including this one, does not exceed its dlg_limits. Authorises the request as the principal sub would be authorised by the RP's own access control, and permits it only if both that check and the grants allow it. Grants are a ceiling, never a grant of access the principal lacks. Limits are counted per RP. Unless a receipt's aud names exactly one RP, the effective limit across RPs may be higher than any single value.

Request Matching A request matches a grant when: Its scheme is https. Its host, normalised as in , matches the grant's host, and its port equals the grant's port. Its method is in the grant's methods. Its path, normalised per Section 6.2.2 (case normalisation, then percent-encoding normalisation, then dot-segment removal, in that order), matches one of the grant's paths. The query component is not matched. A request whose path contains %2F, %5C or %00 after normalisation MUST NOT match any grant. Its body is no larger than max_body_bytes. If the grant has tools, any tool the request invokes is listed.

Binding to HTTP Requests

Header Fields This document defines two HTTP header fields, both Structured Fields :

Agent-Passport:

A List whose members are Strings, each the JWS Compact Serialization of a passport. The first member is the acting agent's passport. The remaining members are the passports of every agent that signed a child receipt in the presented chain, in any order. Parameters MUST be ignored.

Agent-Delegation:

A List whose members are Strings, each a receipt's JWS Compact Serialization, ordered from root to leaf. Parameters MUST be ignored.

A request MAY carry Agent-Passport without Agent-Delegation. It then conveys identity only, and no delegated authority; what such a request may do is local policy. Header sizes grow with chain length. Agents SHOULD keep chains short, and RPs SHOULD accept at least 16 KB for the two fields combined.

Signing The acting agent MUST sign each request with its holder key using HTTP Message Signatures , with: covered components including at least "@method", "@target-uri" and "agent-passport"; and, when present, "agent-delegation", "content-digest" and "signature-agent"; the created, expires and nonce parameters, with expires no more than 300 seconds after created; keyid set to the base64url SHA-256 JWK thumbprint of the holder key; tag set to agent-passport. A request with a body MUST carry Content-Digest and cover it.

Verification An RP: Parses Agent-Passport and validates the first passport (). Verifies the HTTP message signature with that passport's cnf.jwk. It rejects a signature whose created is more than 60 seconds in the future, whose expires has passed, or whose keyid does not match the key. Rejects the request if the nonce has already been accepted for the same keyid within the signature's validity window plus 60 seconds. If Agent-Delegation is present, performs chain validation (). Records the nonce.

Relationship to Web Bot Auth The Web Bot Auth working group's documents let an agent identify a key directory with a Signature-Agent field. An agent MAY send both Signature-Agent and Agent-Passport and sign once. In that case "signature-agent" MUST be covered, and the key it resolves to MUST be the passport's holder key; an RP that finds otherwise MUST reject the request.

Status and Revocation Passports and receipts SHOULD carry a status claim referencing a Token Status List . RPs SHOULD cache status lists for no longer than their time-to-live. An RP that cannot obtain a valid status list SHOULD treat the token according to local policy, and SHOULD deny for high-value operations. An issuer SHOULD revoke a passport when the controller reports compromise of the holder key, when the build no longer matches (for example because a Tool Attestation named in agent_build.tools has been withdrawn), or when the controller withdraws authorisation. Revoking a passport invalidates every chain in which its holder delegated, because each such passport is validated during chain validation.

Transparency Issuers SHOULD append each passport they issue, and each revocation, to an append-only, publicly verifiable log following , for example served as . A log lets controllers detect passports issued in their name without authorisation, and lets anyone audit an issuer's history. This document does not require RPs to check log inclusion.

Security Considerations

Holder Key Compromise A stolen holder key lets an attacker act as the agent until its passport expires or is revoked. Lifetimes are capped at 24 hours, and holder keys SHOULD be kept in hardware-backed or platform key stores.

Replay Requests carry a nonce and a short validity window; RPs keep a nonce cache per keyid (). Passports and receipts are not request-bound. They MUST NOT be accepted without a valid request signature from the key the leaf receipt is bound to.

Build Assertions Are Assertions agent_build states what the issuer was told or verified about the build. It does not prove the agent is running it. RPs for whom this matters SHOULD accept passports only from issuers whose issuance policy includes runtime attestation, and SHOULD pin build digests. dlg_build lets a delegator bind authority to the build it approved, so a later build under the same key does not inherit it.

Attenuation and Matching The coverage test () and request matching () are defined together. An implementation that matches requests differently from how it tests coverage can be widened by the difference. Normalisation order matters: decoding %2E%2E after dot-segment removal would let a request escape a path prefix.

Ceiling, Not Grant Grants never give a principal access it lacks. An RP that skipped the principal check in would let a receipt for /accounts/* reach every account, not only the principal's.

Controller Domain Controller authorisation relies on the controller's origin. Loss of control of that origin lets an attacker authorise issuers. RPs MAY pin issuers per controller. Withdrawn authorisations remain effective for as long as RPs cache agent-controller documents, up to 24 hours.

Algorithms Implementations MUST follow , MUST reject none, and SHOULD restrict accepted algorithms by local policy.

Privacy Considerations A passport identifies an agent consistently across RPs, which allows correlation of its activity. Controllers that need unlinkability across RPs SHOULD use distinct holder keys and passports per RP. Configuration is disclosed only as a digest. Receipts identify the principal (sub) to every RP they are shown to, and purp may reveal what the principal asked for; delegators SHOULD keep purp minimal and use aud to limit which RPs see a receipt. The passports of intermediate agents are disclosed to the RP of the acting agent.

IANA Considerations

Media Types This document requests registration of the following media types per : Type name: application. Subtype name: agent-passport+jwt. Required parameters: none. Optional parameters: none. Encoding considerations: 8bit; a JWS Compact Serialization, which is ASCII. Security considerations: see . Interoperability considerations: none. Published specification: this document. Applications that use this media type: AI agents and the services that verify them. Fragment identifier considerations: none. Additional information: none. Person and email address to contact: the author. Intended usage: COMMON. Restrictions on usage: none. Author and change controller: IETF. Type name: application. Subtype name: agent-delegation+jwt. Other fields as above.

JSON Web Token Claims This document requests registration of the following claims in the "JSON Web Token Claims" registry. For each, the Change Controller is IETF and the Reference is this document. Claim Description Section agent_controller Accountable controller origin of an agent agent_build Description of an agent's build agent_aliases Other identifiers for the same agent dlg_parent Digest of the parent delegation receipt dlg_build Build digest the delegation is bound to dlg_grants Grants conveyed by a delegation receipt dlg_limits Limits on a delegation receipt

HTTP Field Names This document requests registration in the "Hypertext Transfer Protocol (HTTP) Field Name Registry": Field Name Status Structured Type Reference Agent-Passport permanent List Agent-Delegation permanent List

Well-Known URIs This document requests registration in the "Well-Known URIs" registry : URI Suffix Change Controller Reference Status agent-controller IETF permanent agent-passport-issuer IETF permanent

OAuth URI This document requests registration of urn:ietf:params:oauth:token-type:agent-delegation in the "OAuth URI" registry, with Common Name "Agent Delegation Receipt", Change Controller IETF and Reference .

Grant Members This document requests creation of an "Agent Delegation Grant Members" registry (Specification Required), initially containing host, port, methods, paths, tools and max_body_bytes. Each registration MUST state how the member is compared for attenuation. Because RPs reject unknown members (), a new member is safe to deploy: RPs that don't understand it refuse the receipt rather than ignore the restriction.

MATTRBundesdruckereiSPRIND ISO Ping IdentityCyberArkSPIRLIntuit CrowdStrikePractical Identity LLCDefakto Security Defakto SecurityAWSZscalerPing IdentityOpen AI Hellō IETF CNCF in-toto project C2SP Model Context Protocol project Mozilla Foundation

Examples TP-A and TP-B stand for the JWK Thumbprint URIs (urn:ietf:params:oauth:jwk-thumbprint:sha-256:...) of agents A and B; jkt-A and jkt-B for the corresponding bare base64url thumbprints. Values are shortened with an ellipsis ("...").

Passport (Agent B)

Delegation Chain A principal, through their organisation's authorisation server, lets agent A read account data; agent A lets agent B read only one account's statements.

Request Agent B sends its own passport first, then agent A's, because agent A signed the child receipt. Long lines are folded as described in .

Open Issues Expressing grants as an RFC 9396 authorization_details type , so that authorisation servers already supporting rich authorisation requests can issue root receipts directly. Profiling the passport as, or alongside, a WIMSE workload identity token . A claim carrying a transparency-log inclusion proof. A root receipt form signed directly by the principal's authenticator (WebAuthn). A registry of agent_build.model identifiers, or leaving them vendor-defined. Interaction with Transaction Tokens for propagation within one trust domain. Whether dlg_limits accounting should be shared between RPs.