# drafts

name: draft-gudlab-agentid-protocol
rev: 00
title: AgentID: An Identity Protocol for Autonomous AI Agents
time: 2026-03-15T17:17:21Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-16T17:17:21Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "A2A protocols", "Policy/governance"]
tags: []
fetched_at: 2026-05-22T09:24:40.604506+00:00
source: ietf
abstract:
  This document defines the AgentID Protocol, an open standard for
     establishing, verifying, and managing the identity of autonomous AI
     agents operating across the Internet.  As AI agents increasingly
     interact with web services, APIs, and each other on behalf of humans
     and organisations, the industry lacks a universal mechanism to
     determine which agent is making a request, who is accountable for it,
     and what it is permitted to do.

     AgentID introduces the Agent Identity Token (AIT), a signed JWT
     carrying agent identity, owner verification, capability, and
     delegation chain claims.  The protocol defines agent registration,
     owner verification levels, service-side access tiers, and transparent
     delegation chains with scope attenuation.  It builds on existing
     standards including OAuth 2.0, OpenID Connect, JSON Web Token (JWT),
     and JSON Web Key (JWK), adapting them to the unique requirements of
     non-human autonomous actors.

full_text:
  Web Authorization Protocol                                       T. Uzua
  Internet-Draft                                                    GudLab
  Intended status: Standards Track                           14 March 2026
  Expires: 15 September 2026


           AgentID: An Identity Protocol for Autonomous AI Agents
                      draft-gudlab-agentid-protocol-00

  Abstract

     This document defines the AgentID Protocol, an open standard for
     establishing, verifying, and managing the identity of autonomous AI
     agents operating across the Internet.  As AI agents increasingly
     interact with web services, APIs, and each other on behalf of humans
     and organisations, the industry lacks a universal mechanism to
     determine which agent is making a request, who is accountable for it,
     and what it is permitted to do.

     AgentID introduces the Agent Identity Token (AIT), a signed JWT
     carrying agent identity, owner verification, capability, and
     delegation chain claims.  The protocol defines agent registration,
     owner verification levels, service-side access tiers, and transparent
     delegation chains with scope attenuation.  It builds on existing
     standards including OAuth 2.0, OpenID Connect, JSON Web Token (JWT),
     and JSON Web Key (JWK), adapting them to the unique requirements of
     non-human autonomous actors.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 15 September 2026.







  Uzua                    Expires 15 September 2026               [Page 1]


  Internet-Draft              AgentID Protocol                  March 2026


  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Threat Model  . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Protocol Requirements . . . . . . . . . . . . . . . . . . . .   5
     4.  Agent Identity Token (AIT)  . . . . . . . . . . . . . . . . .   5
       4.1.  Token Header  . . . . . . . . . . . . . . . . . . . . . .   5
       4.2.  Token Claims  . . . . . . . . . . . . . . . . . . . . . .   6
         4.2.1.  Identity Claims . . . . . . . . . . . . . . . . . . .   6
         4.2.2.  Owner Claims  . . . . . . . . . . . . . . . . . . . .   6
         4.2.3.  Capability Claims . . . . . . . . . . . . . . . . . .   6
         4.2.4.  Delegation Claims . . . . . . . . . . . . . . . . . .   7
         4.2.5.  Standard JWT Claims . . . . . . . . . . . . . . . . .   7
       4.3.  AIT Example . . . . . . . . . . . . . . . . . . . . . . .   7
       4.4.  Cryptographic Requirements  . . . . . . . . . . . . . . .   8
       4.5.  Token Lifetime  . . . . . . . . . . . . . . . . . . . . .   8
     5.  Owner Verification Levels . . . . . . . . . . . . . . . . . .   9
     6.  Agent Registration  . . . . . . . . . . . . . . . . . . . . .   9
       6.1.  Phase 1: Owner Registration . . . . . . . . . . . . . . .   9
       6.2.  Phase 2: Agent Creation . . . . . . . . . . . . . . . . .   9
     7.  Service-Side Access Control . . . . . . . . . . . . . . . . .  10
       7.1.  Policy Expression . . . . . . . . . . . . . . . . . . . .  10
     8.  Delegation Chain  . . . . . . . . . . . . . . . . . . . . . .  11
       8.1.  Delegation Chain Structure  . . . . . . . . . . . . . . .  11
       8.2.  Scope Attenuation . . . . . . . . . . . . . . . . . . . .  12
     9.  Agent Registry  . . . . . . . . . . . . . . . . . . . . . . .  12
       9.1.  Registry API  . . . . . . . . . . . . . . . . . . . . . .  12
       9.2.  Revocation  . . . . . . . . . . . . . . . . . . . . . . .  13
     10. Relationship to OAuth 2.0 . . . . . . . . . . . . . . . . . .  13
     11. Security Considerations . . . . . . . . . . . . . . . . . . .  14
       11.1.  Key Management . . . . . . . . . . . . . . . . . . . . .  14
       11.2.  Replay Prevention  . . . . . . . . . . . . . . . . . . .  14
       11.3.  Abuse Mitigation . . . . . . . . . . . . . . . . . . . .  14



  Uzua                    Expires 15 September 2026               [Page 2]


  Internet-Draft              AgentID Protocol                  March 2026


       11.4.  Privacy Considerations . . . . . . . . . . . . . . . . .  14
     12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
       12.1.  Media Type Registration  . . . . . . . . . . . . . . . .  15
       12.2.  JWT Claims Registration  . . . . . . . . . . . . . . . .  15
     13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
       13.1.  Normative References . . . . . . . . . . . . . . . . . .  15
       13.2.  Informative References . . . . . . . . . . . . . . . . .  16
     Appendix A.  Capability Namespace Convention  . . . . . . . . . .  16
     Appendix B.  Error Codes  . . . . . . . . . . . . . . . . . . . .  17
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  17
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  18

  1.  Introduction

     Today's Internet authentication infrastructure was designed for
     humans interacting with services through browsers.  OAuth 2.0
     [RFC6749] enables a user to grant an application limited access to
     their resources.  OpenID Connect [OpenID.Core] enables a user to
     prove their identity across services.  Neither protocol was designed
     for autonomous software agents that:

     *  Operate independently without a human in the loop

     *  Chain together in multi-step workflows where Agent A dispatches
        tasks to Agent B

     *  Make decisions and take actions at machine speed on behalf of
        principals who may not be present

     The result is a proliferation of ad-hoc solutions: raw API keys with
     no ownership tracing, OAuth tokens repurposed beyond their design
     intent, workload identity frameworks such as [SPIFFE] that address
     service-to-service authentication but not agent-specific concerns
     like owner accountability and delegation chains, and proprietary
     agent authentication schemes that fragment the ecosystem.

     AgentID addresses this gap by providing a lightweight,
     cryptographically secure identity layer purpose-built for autonomous
     AI agents.  It answers three questions that no existing standard
     addresses comprehensively:

     1.  Which agent is this?

     2.  Who is accountable for it?

     3.  What is it permitted to do?





  Uzua                    Expires 15 September 2026               [Page 3]


  Internet-Draft              AgentID Protocol                  March 2026


  1.1.  Terminology

     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 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

     Agent  An autonomous software system that interacts with services on
        behalf of a principal (human user or another agent).

     Agent Identity Token (AIT)  A signed JWT that an agent presents to
        authenticate itself to a service.

     Owner  The human or organisation legally accountable for an agent's
        actions.

     Principal  The entity on whose behalf an agent acts.  May be a user,
        an organisation, or another agent.

     Delegation Chain  The ordered sequence of principals and agents
        through which authority was delegated, from the original
        authoriser to the acting agent.

     Registry  A service that stores agent identities, public keys, and
        owner verification records.

     Scope Attenuation  The principle that each link in a delegation chain
        can only have equal or fewer permissions than the previous link.

     Verification Level  A numeric indicator (0-3) of the rigour of
        identity verification performed on an agent's owner.

  2.  Threat Model

     Without a standardised agent identity layer, services face the
     following threats:

     Unattributable Abuse  An anonymous agent submits large volumes of
        spam, books fake appointments, or scrapes content.  The service
        has no way to trace the actor or hold anyone accountable.

     Impersonation  A malicious agent claims to act on behalf of a
        reputable organisation without any verifiable proof.

     Privilege Escalation  An agent granted read access to a resource
        exploits loose controls to perform write or delete operations.




  Uzua                    Expires 15 September 2026               [Page 4]


  Internet-Draft              AgentID Protocol                  March 2026


     Delegation Opacity  Agent A spawns Agent B which spawns Agent C.  A
        service receiving a request from Agent C has no visibility into
        the delegation chain or the original authorising principal.

     Rate-Limit Evasion  Without stable agent identity, rate limiting
        falls back to IP addresses, which agents trivially rotate.

  3.  Protocol Requirements

     The protocol MUST satisfy the following requirements:

     1.  *Verifiable Identity:* A service MUST be able to
         cryptographically verify an agent's identity without a
         synchronous call to a central authority.

     2.  *Owner Accountability:* Every agent identity MUST be traceable to
         a verified human or organisational owner.

     3.  *Granular Access Control:* Services MUST be able to define
         policies based on agent identity, owner identity, verification
         level, and declared capabilities.

     4.  *Delegation Transparency:* When an agent acts on behalf of
         another agent or a human, the full chain of delegation MUST be
         inspectable.

     5.  *Revocability:* Compromised or abusive agent identities MUST be
         revocable in real time.

     6.  *Interoperability:* The protocol MUST work across agent
         frameworks, programming languages, and deployment models.

     7.  *Performance:* Token verification MUST be possible offline using
         cached public keys, with registry lookups reserved for enhanced
         checks.

  4.  Agent Identity Token (AIT)

     The Agent Identity Token is a signed JSON Web Token (JWT) conforming
     to [RFC7519], with a custom claim set designed for agent
     identification.  The token is self-contained: any service with access
     to the issuer's public key can verify the token without contacting
     the registry.

  4.1.  Token Header

     The AIT JOSE header MUST contain the following parameters:




  Uzua                    Expires 15 September 2026               [Page 5]


  Internet-Draft              AgentID Protocol                  March 2026


     alg  REQUIRED.  MUST be "ES256" (ECDSA using P-256 and SHA-256, per
        [RFC7518] Section 3.4).

     typ  REQUIRED.  MUST be "AIT+jwt".

     kid  REQUIRED.  Key identifier for key rotation, corresponding to a
        key in the registry's JWKS [RFC7517].

     {
       "alg": "ES256",
       "typ": "AIT+jwt",
       "kid": "agentidp-2026-03-01"
     }

                          Figure 1: AIT Header Example

  4.2.  Token Claims

     The AIT payload contains the following claims organised into four
     groups:

  4.2.1.  Identity Claims

     agent_id  REQUIRED.  String.  Globally unique agent identifier
        assigned by the registry.

     agent_name  REQUIRED.  String.  Human-readable name of the agent.

     agent_version  RECOMMENDED.  String.  Semantic version of the agent
        software.

     agent_description  OPTIONAL.  String.  Brief description of the
        agent's purpose.

  4.2.2.  Owner Claims

     owner_id  REQUIRED.  String.  Unique identifier for the agent's owner
        in the registry.

     owner_type  REQUIRED.  String.  Either "person" or "org".

     owner_name  REQUIRED.  String.  Display name of the owner.

     verification_level  REQUIRED.  Integer (0-3).  See Section 5.

  4.2.3.  Capability Claims

     capabilities  OPTIONAL.  Array of strings.  Declared capabilities



  Uzua                    Expires 15 September 2026               [Page 6]


  Internet-Draft              AgentID Protocol                  March 2026


        using the namespace convention defined in Appendix A.

  4.2.4.  Delegation Claims

     delegation_chain  OPTIONAL.  Array of delegation objects.  See
        Section 8.

  4.2.5.  Standard JWT Claims

     iss  REQUIRED.  String.  The registry URL that issued the agent
        identity.

     sub  REQUIRED.  String.  Same value as agent_id.

     aud  RECOMMENDED.  String.  The target service URL.

     iat  REQUIRED.  NumericDate.  Time at which the token was issued.

     exp  REQUIRED.  NumericDate.  Expiration time.  MUST NOT exceed 24
        hours after iat.  A lifetime of 1 hour or less is RECOMMENDED for
        high-security contexts.

     jti  REQUIRED.  String.  Unique token identifier for replay
        prevention.

  4.3.  AIT Example

     The following is an example AIT payload:























  Uzua                    Expires 15 September 2026               [Page 7]


  Internet-Draft              AgentID Protocol                  March 2026


     {
       "agent_id": "ag_7xK9m2nP4qRtL8",
       "agent_name": "AcmeBookingAgent",
       "agent_version": "1.2.0",
       "owner_id": "own_T1mR4xBq9",
       "owner_type": "org",
       "owner_name": "Acme Inc",
       "verification_level": 2,
       "capabilities": ["calendar:read", "calendar:write"],
       "delegation_chain": [{
         "principal_type": "user",
         "principal_id": "usr_abc123",
         "granted_at": "2026-03-01T10:00:00Z",
         "scopes": ["calendar:read"]
       }],
       "iss": "https://registry.agentidp.dev",
       "sub": "ag_7xK9m2nP4qRtL8",
       "aud": "https://api.example.com",
       "iat": 1740000000,
       "exp": 1740003600,
       "jti": "tok_unique_nonce_123"
     }

                         Figure 2: AIT Payload Example

  4.4.  Cryptographic Requirements

     All Agent Identity Tokens MUST be signed using ES256 (ECDSA with the
     P-256 curve and SHA-256) as defined in [RFC7518] Section 3.4.  This
     algorithm provides strong security with compact signatures suitable
     for high-frequency agent-to-service communication.

     Agent key pairs are generated during registration and the public key
     is published via the registry's JWKS endpoint [RFC7517].  Services
     verify tokens by fetching the public key from the JWKS endpoint, with
     aggressive caching (RECOMMENDED TTL: 24 hours).

  4.5.  Token Lifetime

     AIT tokens MUST have a maximum lifetime of 24 hours (the difference
     between exp and iat MUST NOT exceed 86400 seconds).  For high-
     security contexts, a lifetime of 1 hour or less is RECOMMENDED.
     Short-lived tokens limit the blast radius of key compromise.  Agents
     MUST implement automatic token refresh using their private key.







  Uzua                    Expires 15 September 2026               [Page 8]


  Internet-Draft              AgentID Protocol                  March 2026


  5.  Owner Verification Levels

     The protocol defines four verification levels providing increasing
     assurance about the agent owner's identity.  Services can set minimum
     verification requirements per endpoint.

     Level 0 - Unverified  Email address confirmed only.  Suitable for
        testing, development, and open-access services.

     Level 1 - Email  Email and phone verification.  Suitable for low-risk
        public services.

     Level 2 - Domain  DNS TXT record or well-known file verification at
        the owner's domain.  Suitable for business APIs and partner
        integrations.

     Level 3 - Organisation  Know Your Business (KYB) verification
        including company registration and legal entity verification.
        Suitable for financial services, healthcare, and regulated
        industries.

  6.  Agent Registration

     Agent registration is a two-phase process: owner verification
     (performed once) followed by agent creation (performed per agent).  A
     single verified owner MAY register multiple agents.

  6.1.  Phase 1: Owner Registration

     1.  Owner registers at an AgentID-compliant registry with email and
         authenticating credentials.

     2.  Owner completes verification to their desired level (email,
         domain DNS, or KYB document submission).

     3.  Registry issues an owner_id and management credentials.

  6.2.  Phase 2: Agent Creation

     1.  Owner calls POST /v1/agents with agent name, description, and
         declared capabilities.

     2.  Registry generates an ES256 key pair, stores the public key, and
         returns the agent_id, private key (in JWK format per [RFC7517]),
         and the kid.






  Uzua                    Expires 15 September 2026               [Page 9]


  Internet-Draft              AgentID Protocol                  March 2026


     3.  Agent uses the private key to self-sign AIT tokens.  The private
         key MUST NOT be retained by the registry after delivery to the
         owner.

     Owners MUST immediately store the agent private key in a secure
     secrets manager.  If the private key is lost, the agent MUST be re-
     registered with a new key pair.

  7.  Service-Side Access Control

     Services consuming AgentID tokens implement access policies based on
     the claims present in the AIT.  The protocol defines three standard
     access tiers:

     Open  Any agent may access.  No AIT required.  Rate limiting is IP-
        based only.  Suitable for public read-only endpoints.

     Authenticated  A valid AIT from any registered agent is required.
        Token signature and revocation status are verified.  Rate limiting
        is per agent_id.  Suitable for general-purpose APIs.

     Permissioned  A valid AIT is required AND the agent_id or owner_id
        MUST be on an explicit allowlist maintained by the service.  Rate
        limiting is per agent_id.  Suitable for partner integrations and
        sensitive data.

  7.1.  Policy Expression

     Services define policies as a set of rules evaluated against AIT
     claims.  The protocol RECOMMENDS the following policy structure:

     {
       "resource": "/api/bookings",
       "access_tier": "authenticated",
       "min_verification_level": 2,
       "required_capabilities": ["calendar:write"],
       "rate_limit": {
         "requests_per_hour": 100,
         "scope": "agent_id"
       },
       "allowlist": null,
       "denylist": ["ag_known_bad_actor"]
     }

                        Figure 3: Access Policy Example






  Uzua                    Expires 15 September 2026              [Page 10]


  Internet-Draft              AgentID Protocol                  March 2026


  8.  Delegation Chain

     When Agent A instructs Agent B to perform an action, or when a human
     user authorises an agent to act on their behalf, the delegation chain
     is encoded in the AIT so that the receiving service can inspect the
     full provenance of the request.

  8.1.  Delegation Chain Structure

     The delegation_chain claim is an ordered array of delegation objects,
     from the original principal (index 0) to the most recent delegator.
     Each entry records who delegated, when, and with what scope
     restrictions.

     {
       "delegation_chain": [
         {
           "principal_type": "user",
           "principal_id": "usr_john_abc",
           "granted_at": "2026-03-01T10:00:00Z",
           "scopes": ["calendar:read", "calendar:write"],
           "evidence": "oauth2:token_exchange"
         },
         {
           "principal_type": "agent",
           "principal_id": "ag_orchestrator_1",
           "granted_at": "2026-03-01T10:00:05Z",
           "scopes": ["calendar:read"],
           "evidence": "ait:delegation"
         }
       ]
     }

                       Figure 4: Delegation Chain Example

     Each delegation object contains:

     principal_type  REQUIRED.  String.  Either "user" or "agent".

     principal_id  REQUIRED.  String.  Identifier of the delegating
        principal.

     granted_at  REQUIRED.  String (datetime).  When the delegation was
        granted.

     scopes  REQUIRED.  Array of strings.  The scopes granted in this
        delegation step.




  Uzua                    Expires 15 September 2026              [Page 11]


  Internet-Draft              AgentID Protocol                  March 2026


     evidence  OPTIONAL.  String.  Reference to the mechanism used to
        establish the delegation (e.g., "oauth2:token_exchange" per
        [RFC8693], "ait:delegation").

  8.2.  Scope Attenuation

     Each link in the delegation chain MUST have scopes that are equal to
     or a strict subset of the previous link's scopes.  A delegate MUST
     NOT grant more permissions than it received.  This is enforced by
     both the issuing agent (when constructing the token) and the
     verifying service (when validating claims).

     If a verifying service detects a scope attenuation violation, it MUST
     reject the token with error code AID-009 (DELEGATION_INVALID).

  9.  Agent Registry

     The Agent Registry is the trust anchor of the AgentID ecosystem.  It
     stores agent public keys, owner verification records, and revocation
     status.

  9.1.  Registry API

     A compliant registry MUST implement the following endpoints:



























  Uzua                    Expires 15 September 2026              [Page 12]


  Internet-Draft              AgentID Protocol                  March 2026


       +========+==============================+======================+
       | Method | Endpoint                     | Description          |
       +========+==============================+======================+
       | POST   | /v1/owners                   | Register a new owner |
       +--------+------------------------------+----------------------+
       | POST   | /v1/owners/{id}/verify       | Submit verification  |
       |        |                              | evidence             |
       +--------+------------------------------+----------------------+
       | POST   | /v1/agents                   | Register a new agent |
       +--------+------------------------------+----------------------+
       | GET    | /v1/agents/{agent_id}        | Public agent lookup  |
       +--------+------------------------------+----------------------+
       | GET    | /v1/                         | Fetch agent public   |
       |        | agents/{agent_id}/public-key | key (JWK)            |
       +--------+------------------------------+----------------------+
       | DELETE | /v1/agents/{agent_id}        | Revoke an agent      |
       +--------+------------------------------+----------------------+
       | GET    | /.well-known/jwks.json       | Registry JWKS        |
       |        |                              | endpoint             |
       +--------+------------------------------+----------------------+
       | GET    | /v1/agents/{agent_id}/status | Real-time revocation |
       |        |                              | check                |
       +--------+------------------------------+----------------------+

                                   Table 1

  9.2.  Revocation

     Agent revocation MUST be immediate.  When an owner revokes an agent
     or the registry suspends one, the agent status is set to "revoked".

     *  Services implementing real-time checks SHOULD call the status
        endpoint.

     *  Services relying on cached public keys SHOULD implement a maximum
        cache TTL of 1 hour and MUST honour Cache-Control headers returned
        by the registry.

  10.  Relationship to OAuth 2.0

     AgentID is designed to complement, not replace, OAuth 2.0 [RFC6749].
     For services that already use OAuth for user authentication, AgentID
     adds the agent identity layer.  A typical integration pattern is:

     1.  The user grants an OAuth token to the agent (user delegation).






  Uzua                    Expires 15 September 2026              [Page 13]


  Internet-Draft              AgentID Protocol                  March 2026


     2.  The agent includes the OAuth grant reference in the AIT
         delegation chain via the "evidence" field (e.g.,
         "oauth2:token_exchange").

     3.  The service verifies both the agent's identity (AgentID) and the
         user's authorisation (OAuth).

     This layered approach allows services to answer "which agent is
     this?"  (AgentID) independently from "what is this user allowing?"
     (OAuth), providing complete request provenance.

  11.  Security Considerations

  11.1.  Key Management

     Agent private keys MUST be stored in hardware security modules (HSMs)
     or cloud secret managers in production.  Key rotation is supported
     via key versioning: owners can generate a new key pair without
     changing the agent_id.  Both old and new keys are valid during a
     configurable overlap period (default: 72 hours).

  11.2.  Replay Prevention

     Every AIT includes a unique jti claim.  Services SHOULD maintain a
     jti cache (e.g., with TTL matching token expiry) and reject tokens
     with previously seen jti values.  For stateless verification, the
     short token lifetime provides an acceptable trade-off.

  11.3.  Abuse Mitigation

     Registries SHOULD implement automated abuse detection monitoring for
     anomalous patterns.  Services can report abusive agent_ids to the
     registry.  A graduated response model is RECOMMENDED: warning,
     temporary suspension, permanent revocation, owner-level ban.

  11.4.  Privacy Considerations

     Registries store owner identity information subject to applicable
     data protection regulations (GDPR, etc.).  Owner personal data MUST
     NOT be exposed via the public agent lookup API unless the owner
     explicitly opts in.  The minimum public disclosure is: owner_type,
     verification_level, and (for Level 2+) verified_domain.

  12.  IANA Considerations







  Uzua                    Expires 15 September 2026              [Page 14]


  Internet-Draft              AgentID Protocol                  March 2026


  12.1.  Media Type Registration

     This document requests registration of the "AIT+jwt" media type
     subtype in the "JSON Web Token Types" sub-registry of the "JSON Web
     Token (JWT)" registry.

     Type name:  AIT+jwt

     Subtype name:  N/A

     Required parameters:  N/A

     Optional parameters:  N/A

     Reference:  This document

  12.2.  JWT Claims Registration

     This document requests registration of the following claims in the
     "JSON Web Token Claims" registry:

     *  agent_id - Globally unique agent identifier

     *  agent_name - Human-readable agent name

     *  agent_version - Agent software version

     *  agent_description - Agent purpose description

     *  owner_id - Agent owner identifier

     *  owner_type - Owner type (person or org)

     *  owner_name - Owner display name

     *  verification_level - Owner verification level (0-3)

     *  delegation_chain - Delegation provenance chain

  13.  References

  13.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997,
                <https://www.rfc-editor.org/info/rfc2119>.





  Uzua                    Expires 15 September 2026              [Page 15]


  Internet-Draft              AgentID Protocol                  March 2026


     [RFC6749]  Hardt, D., "The OAuth 2.0 Authorization Framework",
                RFC 6749, October 2012,
                <https://www.rfc-editor.org/info/rfc6749>.

     [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517, May 2015,
                <https://www.rfc-editor.org/info/rfc7517>.

     [RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, May
                2015, <https://www.rfc-editor.org/info/rfc7518>.

     [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
                (JWT)", RFC 7519, May 2015,
                <https://www.rfc-editor.org/info/rfc7519>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, May 2017,
                <https://www.rfc-editor.org/info/rfc8174>.

  13.2.  Informative References

     [OpenID.Core]
                Sakimura, N., Bradley, J., Jones, M., Medeiros, B. D., and
                C. Mortimore, "OpenID Connect Core 1.0", November 2014,
                <https://openid.net/specs/openid-connect-core-1_0.html>.

     [RFC8693]  Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C.
                Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, January
                2020, <https://www.rfc-editor.org/info/rfc8693>.

     [SPIFFE]   CNCF, "SPIFFE: Secure Production Identity Framework for
                Everyone", 2024,
                <https://spiffe.io/docs/latest/spiffe-about/overview/>.

  Appendix A.  Capability Namespace Convention

     Capabilities follow a resource:action format:

     form:submit          Submit form data
     form:read            Read form structure/schema
     calendar:read        Read calendar events
     calendar:write       Create/update events
     calendar:delete      Delete events
     email:send           Send emails
     email:read           Read inbox
     storage:read         Read files
     storage:write        Upload/modify files
     payment:initiate     Start a payment
     payment:confirm      Confirm a payment



  Uzua                    Expires 15 September 2026              [Page 16]


  Internet-Draft              AgentID Protocol                  March 2026


     Service providers MAY define custom capabilities using reverse-domain
     notation (e.g., "com.example.booking:create").

  Appendix B.  Error Codes

        +=========+===========================+======================+
        | Code    | Name                      | Description          |
        +=========+===========================+======================+
        | AID-001 | INVALID_TOKEN             | AIT signature        |
        |         |                           | verification failed  |
        +---------+---------------------------+----------------------+
        | AID-002 | TOKEN_EXPIRED             | AIT has exceeded its |
        |         |                           | exp claim            |
        +---------+---------------------------+----------------------+
        | AID-003 | AGENT_REVOKED             | Agent has been       |
        |         |                           | revoked              |
        +---------+---------------------------+----------------------+
        | AID-004 | AGENT_SUSPENDED           | Agent is temporarily |
        |         |                           | suspended            |
        +---------+---------------------------+----------------------+
        | AID-005 | INSUFFICIENT_VERIFICATION | Owner verification   |
        |         |                           | level below minimum  |
        +---------+---------------------------+----------------------+
        | AID-006 | CAPABILITY_DENIED         | Agent lacks required |
        |         |                           | capability           |
        +---------+---------------------------+----------------------+
        | AID-007 | RATE_LIMIT_EXCEEDED       | Per-agent rate limit |
        |         |                           | exceeded             |
        +---------+---------------------------+----------------------+
        | AID-008 | NOT_ON_ALLOWLIST          | Agent not on service |
        |         |                           | allowlist            |
        +---------+---------------------------+----------------------+
        | AID-009 | DELEGATION_INVALID        | Scope attenuation    |
        |         |                           | violated             |
        +---------+---------------------------+----------------------+
        | AID-010 | REPLAY_DETECTED           | Token jti previously |
        |         |                           | used                 |
        +---------+---------------------------+----------------------+

                                   Table 2

  Acknowledgements

     The authors wish to thank the contributors to the AgentID Protocol
     specification on GitHub, and the broader community working on AI
     agent identity and authentication standards.





  Uzua                    Expires 15 September 2026              [Page 17]


  Internet-Draft              AgentID Protocol                  March 2026


  Author's Address

     Tim Uzua
     GudLab
     Email: tim@gudlab.org
     URI:   https://gudlab.org













































  Uzua                    Expires 15 September 2026              [Page 18]


name: draft-nemethi-aid-agent-identity-discovery
rev: 00
title: Agent Identity and Discovery (AID)
time: 2026-03-16T14:10:56Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-17T14:10:55Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent discovery/reg", "Data formats/interop"]
tags: []
fetched_at: 2026-05-22T09:24:40.604512+00:00
source: ietf
abstract:
  Agent Identity and Discovery (AID) is a minimal, DNS-first discovery
     protocol for locating agent service endpoints.  Given a domain name,
     an AID client queries a DNS TXT record at the well-known subdomain
     _agent.<domain> and learns the service endpoint URI, protocol token,
     authentication hint, and optional metadata for that agent.

     This document defines the AID v1.2 record format, client discovery
     algorithm, exact-host lookup rules, security requirements, and IANA
     registrations for the `_agent` DNS node name and the `agent` service
     name.  AID is intentionally small.  After discovery, protocol-
     specific mechanisms such as MCP or A2A handle communication and
     capability negotiation.

full_text:
  Internet Engineering Task Force                          B. Nemethi, Ed.
  Internet-Draft                                 Open Agent Registry, Inc.
  Intended status: Informational                             16 March 2026
  Expires: 17 September 2026


                     Agent Identity and Discovery (AID)
               draft-nemethi-aid-agent-identity-discovery-00

  Abstract

     Agent Identity and Discovery (AID) is a minimal, DNS-first discovery
     protocol for locating agent service endpoints.  Given a domain name,
     an AID client queries a DNS TXT record at the well-known subdomain
     _agent.<domain> and learns the service endpoint URI, protocol token,
     authentication hint, and optional metadata for that agent.

     This document defines the AID v1.2 record format, client discovery
     algorithm, exact-host lookup rules, security requirements, and IANA
     registrations for the `_agent` DNS node name and the `agent` service
     name.  AID is intentionally small.  After discovery, protocol-
     specific mechanisms such as MCP or A2A handle communication and
     capability negotiation.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 17 September 2026.

  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.






  Nemethi                 Expires 17 September 2026               [Page 1]


  Internet-Draft                     AID                        March 2026


     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
       2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
       2.2.  Terms . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  AID Record Format . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.  Syntax and Parsing  . . . . . . . . . . . . . . . . . . .   4
       3.2.  Defined Keys  . . . . . . . . . . . . . . . . . . . . . .   4
       3.3.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.  Client Discovery Procedure  . . . . . . . . . . . . . . . . .   6
       4.1.  Discovery Algorithm . . . . . . . . . . . . . . . . . . .   6
       4.2.  Standard Client Error Codes . . . . . . . . . . . . . . .   7
       4.3.  Exact-Host Semantics and Explicit Delegation  . . . . . .   7
       4.4.  Exposing Multiple Protocols . . . . . . . . . . . . . . .   8
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
       5.1.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .  10
       5.2.  Enterprise Policy Modes . . . . . . . . . . . . . . . . .  10
     6.  DNS and Caching . . . . . . . . . . . . . . . . . . . . . . .  11
     7.  Future Path . . . . . . . . . . . . . . . . . . . . . . . . .  11
       7.1.  Label Stability . . . . . . . . . . . . . . . . . . . . .  11
     8.  Registries and Governance . . . . . . . . . . . . . . . . . .  11
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
       9.1.  Registration in the Underscored and Globally Scoped DNS
             Node Names Registry . . . . . . . . . . . . . . . . . . .  12
       9.2.  Registration in the Service Name and Transport Protocol
             Port Number Registry  . . . . . . . . . . . . . . . . . .  12
     10. Normative References  . . . . . . . . . . . . . . . . . . . .  13
     11. Informative References  . . . . . . . . . . . . . . . . . . .  14
     Appendix A.  Authentication Scheme Registry . . . . . . . . . . .  14
     Appendix B.  Protocol Registry  . . . . . . . . . . . . . . . . .  14
     Appendix C.  Client Error Constants . . . . . . . . . . . . . . .  15
     Appendix D.  PKA Handshake  . . . . . . . . . . . . . . . . . . .  16
     Appendix E.  .well-known Fallback . . . . . . . . . . . . . . . .  17
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17







  Nemethi                 Expires 17 September 2026               [Page 2]


  Internet-Draft                     AID                        March 2026


  1.  Introduction

     Applications that need to locate and connect to an agent often rely
     on out-of-band configuration, centralized directories, or protocol-
     specific discovery mechanisms.  AID defines a single DNS-based
     bootstrap point that answers one question: given a domain, where is
     the agent and which protocol should a client speak?

     AID uses a TXT record at the well-known DNS name _agent.<domain>.
     The record is small, versioned, and protocol-agnostic.  It tells a
     client where the agent is located, which protocol token applies, what
     authentication hint to expect, and whether endpoint proof is
     required.

     *  Zero configuration: a user supplies a domain and the client
        performs discovery.

     *  Decentralized deployment: the protocol uses standard DNS
        publication.

     *  Protocol-agnostic bootstrap: AID identifies the next protocol,
        rather than replacing it.

     *  Stable evolution path: the `_agent` label remains stable across
        protocol versions.

     This document specifies the wire format and client behavior for AID
     v1.2 and requests two IANA registrations.  The RFC 8552 registration
     covers the deployed TXT-based discovery label `_agent`, while the RFC
     6335 service-name-only registration reserves `agent` for possible
     future SRV-based discovery under the same naming family.

  2.  Conventions and Terminology

  2.1.  Requirements Language

     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 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  2.2.  Terms

     AID Client
        Software that performs AID discovery for a domain.





  Nemethi                 Expires 17 September 2026               [Page 3]


  Internet-Draft                     AID                        March 2026


     Provider
        The entity that controls a domain and publishes the AID TXT
        record.

     _agent subdomain
        The DNS name `_agent.<domain>` where the AID TXT record is
        published.

     A-label
        The Punycode representation of an Internationalized Domain Name as
        described in [RFC5890].

  3.  AID Record Format

     A provider MUST advertise its agent service by publishing a single
     TXT record at `_agent.<domain>`. For AID v1.x, agents MUST use DNS
     TXT records for discovery.  TXT is the deployed discovery record type
     because it is widely available across DNS providers and registrars.
     Future versions of AID may adopt a more structured record type, but
     the `_agent` label remains stable; see Section 7.1.

  3.1.  Syntax and Parsing

     The record MUST be a single semicolon-delimited string of `key=value`
     pairs.  Clients SHOULD `trim()` leading and trailing whitespace from
     keys and values.  Clients MUST ignore unknown keys.

     If a DNS server splits the TXT record into multiple 255-octet
     strings, the client MUST concatenate them in order before parsing.
     Providers SHOULD keep the full record under 255 octets when
     practical.

     Key comparison is case-insensitive.  Clients MUST recognize the
     single-letter lowercase alias for every defined key.  A record MUST
     NOT include both a long key and its alias.  Providers SHOULD emit the
     short-key form `v,u,p,a,s,d,e,k,i` for AID v1.x records.

  3.2.  Defined Keys

     version (`v`) Required
        Specification version.  For AID v1.x this MUST be `aid1`. Example:
        `v=aid1`.

     uri (`u`) Required
        Absolute endpoint URL or local locator.  Allowed schemes depend on
        the selected protocol token; see Appendix B.  Example:
        `u=https://api.example.com/mcp`.




  Nemethi                 Expires 17 September 2026               [Page 4]


  Internet-Draft                     AID                        March 2026


     proto (`p`) Required
        Protocol token from Appendix B.  Example: `p=mcp`.

     auth (`a`) Recommended
        Authentication hint token from Appendix A.  Example: `a=pat`.

     desc (`s`) Optional
        Short human-readable description, up to 60 UTF-8 bytes.  Example:
        `s=Primary AI Gateway`.

     docs (`d`) Optional
        Absolute HTTPS URL for human-readable documentation.  Example:
        `d=https://docs.example.com/agent`.

     dep (`e`) Optional
        ISO 8601 UTC timestamp indicating deprecation.  Example:
        `e=2026-01-01T00:00:00Z`.

     pka (`k`) Optional
        Multibase-encoded Ed25519 public key for endpoint proof.  Example:
        `k=z7rW8rTq8o4mM6vVf7w1k3m4uQn9p2YxCAbcDeFgHiJ`.

     kid (`i`) Conditional
        Rotation identifier, 1 to 6 lowercase alphanumeric characters.
        Required when `pka` is present.  Example: `i=g1`.

  3.3.  Examples

     _agent.example.com. 300 IN TXT (
       "v=aid1;u=https://api.example.com/mcp;"
       "p=mcp;a=pat;s=Example AI Tools"
     )

                           Figure 1: Remote MCP Agent

     _agent.grafana.com. 300 IN TXT (
       "v=aid1;u=docker:grafana/mcp:latest;"
       "p=local;a=pat;s=Run Grafana agent locally"
     )

                        Figure 2: Local Agent via Docker

     _agent.example.com. 300 IN TXT (
       "v=aid1;p=mcp;u=https://api.example.com/mcp;"
       "k=z7rW8rTq8o4mM6vVf7w1k3m4uQn9p2YxCAbcDeFgHiJ;i=g1;"
       "d=https://docs.example.com/agent;"
       "e=2026-01-01T00:00:00Z;s=Secure AI Gateway"
     )



  Nemethi                 Expires 17 September 2026               [Page 5]


  Internet-Draft                     AID                        March 2026


                   Figure 3: Remote MCP with PKA and Metadata

     _agent.local.test. 300 IN TXT (
       "v=aid1;p=zeroconf;"
       "u=zeroconf:_mcp._tcp;s=Local Dev Agent"
     )

                        Figure 4: Local Zeroconf Example

  4.  Client Discovery Procedure

  4.1.  Discovery Algorithm

     When an AID client is given a domain, it MUST perform the following
     steps:

     1.  Normalize the domain.  If the input contains non-ASCII labels,
         convert them to A-label form as described in [RFC5890].

     2.  Query the TXT record at `_agent.<exact-host-user-entered>`. The
         client MUST NOT walk up the DNS hierarchy.  If no record is found
         or the lookup fails, the client MAY try the `.well-known`
         fallback on the same exact host; see Appendix E.

     3.  Parse the TXT answer set as semicolon-delimited `key=value`
         records.  Key comparison MUST be case-insensitive, and clients
         MUST recognize single-letter aliases for all defined keys.  If
         exactly one valid AID record is present at the queried DNS name,
         use it.  If more than one valid AID record is present at the same
         queried DNS name, the client MUST fail due to ambiguity.
         Malformed answers do not matter when there is exactly one valid
         AID record.

     4.  If `docs` is present, the client MAY display it.  If `dep` is in
         the future, the client SHOULD warn.  If `dep` is in the past, the
         client SHOULD fail gracefully.

     5.  If `pka` is present, the client MUST perform the endpoint-proof
         procedure in Appendix D.  Providers MUST publish `kid` whenever
         `pka` is present.

     6.  If validation succeeds, return the discovered details.  If the
         client does not support the selected protocol token, it MUST fail
         with the appropriate error.







  Nemethi                 Expires 17 September 2026               [Page 6]


  Internet-Draft                     AID                        March 2026


  4.2.  Standard Client Error Codes

        +======+=======================+=============================+
        | Code | Name                  | Meaning                     |
        +======+=======================+=============================+
        | 1000 | ERR_NO_RECORD         | No `_agent` TXT record was  |
        |      |                       | found for the domain.       |
        +------+-----------------------+-----------------------------+
        | 1001 | ERR_INVALID_TXT       | A record was found but is   |
        |      |                       | malformed or missing        |
        |      |                       | required keys.              |
        +------+-----------------------+-----------------------------+
        | 1002 | ERR_UNSUPPORTED_PROTO | The record is valid, but    |
        |      |                       | the client does not support |
        |      |                       | the selected protocol.      |
        +------+-----------------------+-----------------------------+
        | 1003 | ERR_SECURITY          | Discovery failed due to a   |
        |      |                       | security policy or          |
        |      |                       | verification failure.       |
        +------+-----------------------+-----------------------------+
        | 1004 | ERR_DNS_LOOKUP_FAILED | The DNS query failed for a  |
        |      |                       | network-related reason.     |
        +------+-----------------------+-----------------------------+
        | 1005 | ERR_FALLBACK_FAILED   | The `.well-known` fallback  |
        |      |                       | failed or returned invalid  |
        |      |                       | data.                       |
        +------+-----------------------+-----------------------------+

                         Table 1: Client Error Codes

  4.3.  Exact-Host Semantics and Explicit Delegation

     Discovery is exact-host by default.  If the application asks for
     `app.team.example.com`, the canonical AID query name is
     `_agent.app.team.example.com`.

     Clients MUST NOT walk up the DNS hierarchy looking for
     `_agent.team.example.com` or `_agent.example.com`. If an operator
     wants a child host to inherit a shared record, that inheritance MUST
     be expressed in DNS for the exact queried name, for example by using
     a `CNAME` at the child host's `_agent` label.










  Nemethi                 Expires 17 September 2026               [Page 7]


  Internet-Draft                     AID                        March 2026


     _agent.app.team.example.com. 300 IN TXT (
       "v=aid1;p=mcp;"
       "u=https://app.team.example.com/mcp"
     )

     _agent.app.team.example.com. 300 IN CNAME (
       _agent.shared.team.example.com.
     )
     _agent.shared.team.example.com. 300 IN TXT (
       "v=aid1;p=mcp;"
       "u=https://gateway.team.example.com/mcp"
     )

                  Figure 5: Exact-Host and Delegated Examples

     Protocol-specific lookups follow the same exact-host rule.  If an
     application explicitly asks for a given protocol token, a client MAY
     query `_agent._<proto>.<exact-host>` before the base `_agent.<exact-
     host>` name, but it MUST NOT query parent hosts implicitly.

  4.4.  Exposing Multiple Protocols

     The canonical location for discovery is the base record
     `_agent.<domain>`. Providers MAY additionally expose distinct agent
     services on protocol-specific subdomains of the form
     `_agent._<proto>.<domain>`.

     _agent._mcp.example.com. 300 IN TXT (
       "v=aid1;p=mcp;"
       "u=https://api.example.com/mcp"
     )
     _agent._a2a.example.com. 300 IN TXT (
       "v=aid1;p=a2a;"
       "u=https://api.example.com/a2a"
     )

                      Figure 6: Protocol-Specific Records

     By default, clients query the base record.  When a specific protocol
     token is explicitly requested by the calling application, clients MAY
     first query the corresponding protocol-specific name and then fall
     back to the base record for the same exact host.

  5.  Security Considerations

     AID publishes public discovery metadata.  The TXT record MUST NOT
     contain secrets.  The protocol depends on DNS integrity, TLS for
     remote endpoints, and explicit client safeguards for local execution.



  Nemethi                 Expires 17 September 2026               [Page 8]


  Internet-Draft                     AID                        March 2026


     *  Providers SHOULD sign AID records with DNSSEC when available.
        Clients SHOULD perform DNSSEC validation when DNSSEC-signed
        answers are available.

     *  A `remote` agent's `uri` MUST use `https://`. Clients MUST perform
        standard TLS certificate and hostname validation as described in
        [RFC9525].

     *  When `pka` is present, clients MUST verify endpoint control of the
        private key as described in Appendix D.  Providers MUST publish
        `kid` when `pka` is present.  Clients SHOULD warn if a previously
        observed `pka` disappears.

     *  Clients that support `proto=local` MUST implement the safeguards
        described below.

     *  Clients MUST NOT automatically follow cross-origin redirects from
        a discovered endpoint.

     Clients that support `proto=local` MUST implement the following
     safeguards:

     1.  Explicit consent: before first execution, the client MUST display
         the full resolved command and require explicit confirmation.

     2.  Integrity check: the client MUST compute and cache a
         cryptographic fingerprint of the `uri` and `proto` values.  If
         these values change on a later lookup, the client MUST re-trigger
         the full consent process.

     3.  No shell interpretation: arguments derived from the `uri` MUST be
         passed atomically to the underlying OS execution call to prevent
         command injection.

     4.  No nested discovery: the client MUST reject a `local` execution
         `uri` that could be interpreted as a command that initiates
         another AID discovery request.

     5.  Sandboxing: clients SHOULD run local agents in a sandboxed
         environment with minimum necessary permissions.

     If an initial request to the discovered `uri` returns an HTTP
     redirect (`301`, `302`, `307`, or `308`) to a different origin,
     clients SHOULD treat this as a potential security risk.  Clients MUST
     NOT follow such cross-origin redirects automatically.
     Implementations MAY either terminate with `ERR_SECURITY` or require
     explicit user confirmation before proceeding.




  Nemethi                 Expires 17 September 2026               [Page 9]


  Internet-Draft                     AID                        March 2026


  5.1.  Threat Model

     AID addresses DNS spoofing and cache poisoning with optional DNSSEC
     validation, endpoint impersonation with optional public-key
     attestation, downgrade detection with remembered key state, command
     injection risks for local execution, and cross-origin redirect abuse
     for remote endpoints.

     Compromised authoritative DNS servers, active network attackers
     beyond the protections of TLS, and revocation beyond DNS record
     update remain outside the direct scope of AID v1.2.

  5.2.  Enterprise Policy Modes

     Clients that expose enterprise controls SHOULD provide policy presets
     and MAY expose the underlying policy knobs directly.

         +==========+============+=========+============+===========+
         | Preset   | PKA        | DNSSEC  | Well-known | Downgrade |
         +==========+============+=========+============+===========+
         | balanced | if-present | prefer  | auto       | warn      |
         +----------+------------+---------+------------+-----------+
         | strict   | require    | require | disable    | fail      |
         +----------+------------+---------+------------+-----------+

                      Table 2: Normative Policy Presets

     The underlying policy knobs are:

     *  PKA policy: `if-present | require`

     *  DNSSEC policy: `off | prefer | require`

     *  Well-known policy: `auto | disable`

     *  Downgrade policy: `off | warn | fail`

     Policy semantics are as follows:

     *  PKA `require`: discovery MUST fail with `ERR_SECURITY` if the
        selected record does not publish `pka` and `kid`.

     *  DNSSEC `prefer`: clients SHOULD continue when DNSSEC cannot be
        validated, but SHOULD surface a warning.

     *  DNSSEC `require`: clients MUST fail with `ERR_SECURITY` when
        DNSSEC validation is unavailable or unsuccessful for the selected
        DNS answer.



  Nemethi                 Expires 17 September 2026              [Page 10]


  Internet-Draft                     AID                        March 2026


     *  Well-known `disable`: clients MUST NOT use `/.well-known/agent`
        fallback.

     *  Downgrade `warn`: if a previously seen `pka` disappears or `pka`
        or `kid` changes, clients SHOULD surface a warning.

     *  Downgrade `fail`: if a previously seen `pka` disappears or `pka`
        or `kid` changes, clients MUST fail with `ERR_SECURITY`.

     If discovery succeeds only through `.well-known`, that result cannot
     satisfy a policy that requires DNSSEC validation.

  6.  DNS and Caching

     Providers are RECOMMENDED to publish `_agent` TXT records with a TTL
     between 300 and 900 seconds.  Clients MUST respect the received TTL
     and MUST NOT cache the record longer than that.

  7.  Future Path

     AID v2 or later may adopt a more structured DNS record type such as
     SRV [RFC2782] or SVCB [RFC9460], depending on operational deployment
     support.  TXT remains the canonical mechanism for AID v1.x.

     Formal requests are expected for the `_agent` underscored DNS node
     name under [RFC8552] and the `agent` service name under [RFC6335].

  7.1.  Label Stability

     The stable DNS label for AID is `_agent`. Record types may evolve,
     but the discovery label remains `_agent` across versions and the
     record version field identifies the wire-format expectations.  This
     is the main reason the RFC 8552 registration is valuable even if
     later AID versions use a different DNS RR type.

  8.  Registries and Governance

     To support interoperability, token registries and community resources
     are maintained publicly.

     *  Token registries: the canonical lists for `auth` and `proto`
        tokens are maintained at https://github.com/agentcommunity/aid-
        tokens (https://github.com/agentcommunity/aid-tokens).  Additions
        require a pull request and are governed by a first-come, first-
        served policy with expert review.






  Nemethi                 Expires 17 September 2026              [Page 11]


  Internet-Draft                     AID                        March 2026


     *  Global index: an open DNS crawler and community dashboard showing
        AID adoption is maintained at https://github.com/agentcommunity/
        aid-registry (https://github.com/agentcommunity/aid-registry).

  9.  IANA Considerations

     This document requests registration in two IANA registries.  The
     registrations serve different purposes.  The RFC 8552 request covers
     AID v1.x TXT discovery at `_agent.<domain>`. The RFC 6335 request
     reserves the service name `agent` for potential future DNS service
     discovery usage under `_agent._tcp.<domain>`.

  9.1.  Registration in the Underscored and Globally Scoped DNS Node Names
        Registry

     IANA is requested to register the following entry in the "Underscored
     and Globally Scoped DNS Node Names" registry established by
     [RFC8552].

                         +-----------+---------------+
                         | RR Type   | TXT           |
                         +-----------+---------------+
                         | Node Name | _agent        |
                         +-----------+---------------+
                         | Reference | This document |
                         +-----------+---------------+

                             Table 3: Requested RFC
                               8552 Registration

     The `_agent` node name is used exclusively for Agent Identity and
     Discovery.  A single TXT record published at `_agent.<domain>`
     contains semicolon-delimited key/value pairs that identify an agent
     endpoint, protocol token, and optional metadata as defined in
     Section 3 and Section 4.

     The requested node name is specific to AID and does not reserve the
     broader concept of agents or agent-related discovery generally.
     Protocol-specific labels of the form `_agent._<proto>.<domain>` are
     subordinate names beneath the registered `_agent` node and do not
     require separate global registration.

  9.2.  Registration in the Service Name and Transport Protocol Port
        Number Registry

     IANA is requested to register the following service-name-only entry
     in the "Service Name and Transport Protocol Port Number" registry
     defined by [RFC6335].



  Nemethi                 Expires 17 September 2026              [Page 12]


  Internet-Draft                     AID                        March 2026


        +-------------+----------------------------------------------+
        | Service     | agent                                        |
        | Name        |                                              |
        +-------------+----------------------------------------------+
        | Transport   | tcp                                          |
        | Protocol(s) |                                              |
        +-------------+----------------------------------------------+
        | Description | Agent Identity and Discovery (AID): DNS-     |
        |             | based discovery of agent service endpoints   |
        +-------------+----------------------------------------------+
        | Port Number | N/A                                          |
        +-------------+----------------------------------------------+
        | Assignment  | No port number is requested.  This is a      |
        | Notes       | service-name-only registration intended to   |
        |             | establish `agent` for possible future SRV-   |
        |             | based discovery under `_agent._tcp.<domain>` |
        |             | while preserving the stable `_agent` label.  |
        +-------------+----------------------------------------------+
        | Reference   | This document                                |
        +-------------+----------------------------------------------+

                   Table 4: Requested RFC 6335 Registration

  10.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", RFC 2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC5890]  Klensin, J., "Internationalized Domain Names for
                Applications (IDNA): Definitions and Document Framework",
                RFC 5890, August 2010,
                <https://www.rfc-editor.org/rfc/rfc5890>.

     [RFC6335]  Cotton, M., "Internet Assigned Numbers Authority (IANA)
                Procedures for the Management of the Service Name and
                Transport Protocol Port Number Registry", RFC 6335, August
                2011, <https://www.rfc-editor.org/rfc/rfc6335>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", RFC 8174, May 2017,
                <https://www.rfc-editor.org/rfc/rfc8174>.

     [RFC8552]  Sullivan, A., "Scoped Interpretation of DNS Resource
                Records through "Underscored" Naming of Attribute Leaves",
                RFC 8552, March 2019,
                <https://www.rfc-editor.org/rfc/rfc8552>.




  Nemethi                 Expires 17 September 2026              [Page 13]


  Internet-Draft                     AID                        March 2026


     [RFC9421]  Fielding, R., "HTTP Message Signatures", RFC 9421,
                November 2023, <https://www.rfc-editor.org/rfc/rfc9421>.

     [RFC9525]  Saint-Andre, P. and R. Salz, "Service Identity in TLS",
                RFC 9525, November 2023,
                <https://www.rfc-editor.org/rfc/rfc9525>.

  11.  Informative References

     [RFC2782]  Gulbrandsen, A., "A DNS RR for specifying the location of
                services (DNS SRV)", RFC 2782, February 2000,
                <https://www.rfc-editor.org/rfc/rfc2782>.

     [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
                (URIs)", RFC 8615, May 2019,
                <https://www.rfc-editor.org/rfc/rfc8615>.

     [RFC9460]  Schwartz, B., "Service Binding and Parameter Specification
                via the DNS (SVCB and HTTPS Resource Records)", RFC 9460,
                November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.

  Appendix A.  Authentication Scheme Registry

     All authentication tokens are case-sensitive and use lowercase ASCII.

     *  none

     *  pat

     *  apikey

     *  basic

     *  oauth2_device

     *  oauth2_code

     *  mtls

     *  custom

  Appendix B.  Protocol Registry

     All protocol tokens are case-sensitive and use lowercase ASCII.







  Nemethi                 Expires 17 September 2026              [Page 14]


  Internet-Draft                     AID                        March 2026


       +===========+=========================+=========================+
       | Token     | Meaning                 | Allowed `uri` scheme(s) |
       +===========+=========================+=========================+
       | mcp       | Model Context Protocol  | https://                |
       +-----------+-------------------------+-------------------------+
       | a2a       | Agent-to-Agent Protocol | https://                |
       +-----------+-------------------------+-------------------------+
       | openapi   | OpenAPI specification   | https://                |
       |           | document                |                         |
       +-----------+-------------------------+-------------------------+
       | grpc      | gRPC over HTTP/2 or     | https://                |
       |           | HTTP/3                  |                         |
       +-----------+-------------------------+-------------------------+
       | graphql   | GraphQL over HTTP       | https://                |
       +-----------+-------------------------+-------------------------+
       | websocket | WebSocket transport     | wss://                  |
       +-----------+-------------------------+-------------------------+
       | local     | The agent runs locally  | docker:, npx:, pip:     |
       |           | on the client machine   |                         |
       +-----------+-------------------------+-------------------------+
       | zeroconf  | mDNS or DNS-SD service  | zeroconf:<service_type> |
       |           | discovery               |                         |
       +-----------+-------------------------+-------------------------+
       | ucp       | Universal Commerce      | https://                |
       |           | Protocol                |                         |
       +-----------+-------------------------+-------------------------+

                            Table 5: Protocol Tokens

  Appendix C.  Client Error Constants

     For cross-language SDK consistency, clients SHOULD use the following
     numeric constants.


















  Nemethi                 Expires 17 September 2026              [Page 15]


  Internet-Draft                     AID                        March 2026


                       +=======================+=======+
                       | Constant              | Value |
                       +=======================+=======+
                       | ERR_NO_RECORD         | 1000  |
                       +-----------------------+-------+
                       | ERR_INVALID_TXT       | 1001  |
                       +-----------------------+-------+
                       | ERR_UNSUPPORTED_PROTO | 1002  |
                       +-----------------------+-------+
                       | ERR_SECURITY          | 1003  |
                       +-----------------------+-------+
                       | ERR_DNS_LOOKUP_FAILED | 1004  |
                       +-----------------------+-------+
                       | ERR_FALLBACK_FAILED   | 1005  |
                       +-----------------------+-------+

                         Table 6: Error Constant Values

  Appendix D.  PKA Handshake

     When `pka` is present, the client MUST verify control of the
     corresponding private key using HTTP Message Signatures with Ed25519
     as specified in [RFC9421].

     function performPKAHandshake(uri, pka, kid):
         nonce = generateRandomBytes(32)
         challenge = base64urlEncode(nonce)
         headers = {
             "AID-Challenge": challenge,
             "Date": currentUTCTime()
         }
         response = sendGET(uri, headers)

         if response.status != 200:
             failWith(ERR_SECURITY)

         sigInput = response.headers["Signature-Input"]
         signature = response.headers["Signature"]

         created = parseCreated(sigInput)
         if |currentTime() - created| > 300 seconds:
             failWith(ERR_SECURITY)

         pubKey = multibaseDecode(pka)
         if not verifyEd25519(signature, sigInput.coveredFields, pubKey):
             failWith(ERR_SECURITY)

                       Figure 7: PKA Handshake Pseudocode



  Nemethi                 Expires 17 September 2026              [Page 16]


  Internet-Draft                     AID                        March 2026


     Providers MUST include `kid` whenever `pka` is present.  Clients
     SHOULD warn on downgrade if a previously observed `pka` disappears.

  Appendix E.  .well-known Fallback

     AID is a DNS-based discovery protocol.  The fallback defined here is
     a non-normative convenience for environments where publishing DNS TXT
     records is difficult.  It does not change the RFC 8552 scope of
     `_agent`.

     *  Path: `GET https://<domain>/.well-known/agent`

     *  Format: JSON mirroring the TXT keys, including aliases

     *  Security: TLS certificate validation still applies, and `pka`
        still applies when present

     *  Client behavior: use DNS first and fall back only on
        `ERR_NO_RECORD` or `ERR_DNS_LOOKUP_FAILED`

     *  Error mapping: use `ERR_FALLBACK_FAILED` when the fallback fails
        or is invalid

     The `.well-known` URI convention itself is described in [RFC8615].

  Author's Address

     Balazs Nemethi (editor)
     Open Agent Registry, Inc.
     Email: balazs@agentcommunity.org
     URI:   https://agentcommunity.org




















  Nemethi                 Expires 17 September 2026              [Page 17]


name: draft-aip-agent-identity-protocol
rev: 00
title: Agent Identity Protocol: Agentic Authentication and Authorized Policy Enforcement
time: 2026-03-16T18:09:05Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-17T18:09:05Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Policy/governance", "AI safety/alignment"]
tags: []
fetched_at: 2026-05-22T09:24:40.604516+00:00
source: ietf
abstract:
  This document defines the Agent Identity Protocol (AIP), an open
     standard for verifiable identity and policy enforcement for
     artificial intelligence (AI) agents.

     Agent Identity Protocol (AIP) addresses the problem of AI agents
     operating with unbounded permissions -- running as users, inheriting
     full API key access, and executing tool calls with no verifiable
     identity boundary between human and non-human actors.

     The protocol is structured as two cooperating layers.  Layer 1
     (Identity) gives every agent a unique identifier and a key pair
     registered with an AIP Registry; the agent signs every outbound
     action with that key.  Layer 2 (Enforcement) interposes a proxy
     between the AI client and every tool server that verifies the
     signature, evaluates a declarative policy, and produces an allow,
     deny, or hold decision before any tool is reached.

full_text:
  Network Working Group                                             J. Cao
  Internet-Draft                                                   Montcao
  Intended status: Standards Track                     C. Arango Gutierrez
  Expires: 17 September 2026                                        NVIDIA
                                                             16 March 2026


   Agent Identity Protocol: Agentic Authentication and Authorized Policy
                                Enforcement
                    draft-aip-agent-identity-protocol-00

  Abstract

     This document defines the Agent Identity Protocol (AIP), an open
     standard for verifiable identity and policy enforcement for
     artificial intelligence (AI) agents.

     Agent Identity Protocol (AIP) addresses the problem of AI agents
     operating with unbounded permissions -- running as users, inheriting
     full API key access, and executing tool calls with no verifiable
     identity boundary between human and non-human actors.

     The protocol is structured as two cooperating layers.  Layer 1
     (Identity) gives every agent a unique identifier and a key pair
     registered with an AIP Registry; the agent signs every outbound
     action with that key.  Layer 2 (Enforcement) interposes a proxy
     between the AI client and every tool server that verifies the
     signature, evaluates a declarative policy, and produces an allow,
     deny, or hold decision before any tool is reached.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 17 September 2026.





  Cao & Arango Gutierrez  Expires 17 September 2026               [Page 1]


  Internet-Draft  Agent Identity Protocol: Agentic Authent      March 2026


  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Terminology and Conventions . . . . . . . . . . . . . . . . .   5
     3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   6
       3.1.  The Identity Gap  . . . . . . . . . . . . . . . . . . . .   6
       3.2.  The Enforcement Gap . . . . . . . . . . . . . . . . . . .   7
       3.3.  Scope of This Specification . . . . . . . . . . . . . . .   7
     4.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   7
       4.1.  Architecture  . . . . . . . . . . . . . . . . . . . . . .   7
       4.2.  Call Lifecycle  . . . . . . . . . . . . . . . . . . . . .   8
       4.3.  Relationship to Existing Standards  . . . . . . . . . . .   9
     5.  Layer 1: Agent Identity . . . . . . . . . . . . . . . . . . .   9
       5.1.  Agent Registration  . . . . . . . . . . . . . . . . . . .   9
       5.2.  Agent Record  . . . . . . . . . . . . . . . . . . . . . .  10
       5.3.  AIP Registry API  . . . . . . . . . . . . . . . . . . . .  11
       5.4.  Key Rotation  . . . . . . . . . . . . . . . . . . . . . .  12
       5.5.  Agent Revocation  . . . . . . . . . . . . . . . . . . . .  12
       5.6.  The AIP Token (Agent Attestation Token) . . . . . . . . .  12
         5.6.1.  Token Fields  . . . . . . . . . . . . . . . . . . . .  12
         5.6.2.  Canonical Serialization . . . . . . . . . . . . . . .  13
         5.6.3.  Example Token (before base64url encoding for
                 transport)  . . . . . . . . . . . . . . . . . . . . .  13
       5.7.  Token Verification  . . . . . . . . . . . . . . . . . . .  13
     6.  Layer 2: Enforcement Proxy  . . . . . . . . . . . . . . . . .  14
       6.1.  Proxy Architecture  . . . . . . . . . . . . . . . . . . .  14
       6.2.  AgentPolicy . . . . . . . . . . . . . . . . . . . . . . .  15
         6.2.1.  Schema  . . . . . . . . . . . . . . . . . . . . . . .  15
         6.2.2.  Tool Allowlist  . . . . . . . . . . . . . . . . . . .  16
         6.2.3.  Tool Rules  . . . . . . . . . . . . . . . . . . . . .  16
         6.2.4.  DLP Rules . . . . . . . . . . . . . . . . . . . . . .  16
         6.2.5.  HITL Configuration  . . . . . . . . . . . . . . . . .  17
       6.3.  Intercept Flow  . . . . . . . . . . . . . . . . . . . . .  17
       6.4.  Decision Outcomes . . . . . . . . . . . . . . . . . . . .  18



  Cao & Arango Gutierrez  Expires 17 September 2026               [Page 2]


  Internet-Draft  Agent Identity Protocol: Agentic Authent      March 2026


       6.5.  Human-in-the-Loop (HITL)  . . . . . . . . . . . . . . . .  18
       6.6.  Data Loss Prevention (DLP)  . . . . . . . . . . . . . . .  18
       6.7.  Audit Logging . . . . . . . . . . . . . . . . . . . . . .  19
     7.  Wire Formats  . . . . . . . . . . . . . . . . . . . . . . . .  19
       7.1.  AIP-Token Header  . . . . . . . . . . . . . . . . . . . .  19
       7.2.  Error Response Format . . . . . . . . . . . . . . . . . .  20
       7.3.  Audit Log Record  . . . . . . . . . . . . . . . . . . . .  21
     8.  Deployment Topologies . . . . . . . . . . . . . . . . . . . .  22
       8.1.  Localhost Proxy . . . . . . . . . . . . . . . . . . . . .  22
       8.2.  Kubernetes Sidecar  . . . . . . . . . . . . . . . . . . .  22
       8.3.  Enterprise Federation . . . . . . . . . . . . . . . . . .  23
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .  23
       9.1.  Cryptographic Algorithm . . . . . . . . . . . . . . . . .  23
       9.2.  Prompt Injection Resistance . . . . . . . . . . . . . . .  23
       9.3.  Transport Security  . . . . . . . . . . . . . . . . . . .  24
       9.4.  Private Key Storage . . . . . . . . . . . . . . . . . . .  24
       9.5.  Registry Trust  . . . . . . . . . . . . . . . . . . . . .  24
       9.6.  Nonce Cache Sizing  . . . . . . . . . . . . . . . . . . .  24
       9.7.  Revocation Latency  . . . . . . . . . . . . . . . . . . .  24
       9.8.  Denial-of-Service . . . . . . . . . . . . . . . . . . . .  25
     10. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  25
       10.1.  Agent Record Visibility  . . . . . . . . . . . . . . . .  25
       10.2.  Audit Log Sensitivity  . . . . . . . . . . . . . . . . .  25
       10.3.  DLP Redaction  . . . . . . . . . . . . . . . . . . . . .  25
       10.4.  Registry Data Retention  . . . . . . . . . . . . . . . .  25
     11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  25
       11.1.  HTTP Header Field  . . . . . . . . . . . . . . . . . . .  26
       11.2.  Media Type . . . . . . . . . . . . . . . . . . . . . . .  26
     12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  26
       12.1.  Normative References . . . . . . . . . . . . . . . . . .  26
       12.2.  Informative References . . . . . . . . . . . . . . . . .  27
     Appendix A.  Example AgentPolicy  . . . . . . . . . . . . . . . .  27
     Appendix B.  Example AIP Token  . . . . . . . . . . . . . . . . .  28
     Appendix C.  Error Code Reference . . . . . . . . . . . . . . . .  29
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  30

  1.  Introduction

     AI agents are being deployed at scale with the same credentials as
     the humans who operate them.  When an agent calls a tool -- writing a
     file, querying a database, sending a request to an external API --
     there is nothing in the request that distinguishes it from a direct
     human action.  The downstream service has no way to know it is
     talking to an agent, which agent, who authorized it, or what it is
     permitted to do.






  Cao & Arango Gutierrez  Expires 17 September 2026               [Page 3]


  Internet-Draft  Agent Identity Protocol: Agentic Authent      March 2026


     This creates compounding problems as agents become more capable and
     more numerous.  An agent that is compromised, misbehaves, or is
     manipulated into acting outside its intended scope has no technical
     boundary stopping it from using every credential it has been given.
     Audit logs attribute actions to human accounts rather than to agents,
     making incident investigation difficult.  Multi-agent systems can
     accumulate permissions across delegation steps without any explicit
     record of what was authorized.

     AIP closes this gap with two layers:

     Layer 1 -- Agent Identity.  At provisioning time, the agent is
     registered with an AIP Registry.  The registry assigns the agent a
     unique identifier (the Agent ID) and records the agent's public key
     alongside the identity of the accountable principal.  From that point
     forward, the agent signs every outbound tool call with its private
     key.  Any party that can reach the registry can verify who the agent
     is.

     Layer 2 -- Enforcement Proxy.  An AIP Proxy sits between the AI
     client and every tool server.  It intercepts every tool call,
     verifies the agent's signature against the registry, evaluates the
     call against a simple declarative policy (the AgentPolicy), and
     either forwards the call, blocks it, or holds it for human approval.
     The tool server is never reached until all checks pass.  Every
     decision is written to an append-only audit log.

     The two layers are independent.  Layer 1 can be used without Layer 2
     to provide signed, attributable agent actions in existing systems.
     Layer 2 requires Layer 1 for identity verification but adds no new
     requirements on tool servers.

     AIP targets the Model Context Protocol (MCP) [MCP] as its primary
     tool-call interface but is designed to be applicable to any
     structured tool invocation mechanism.

     AIP does NOT:

     *  Define a new transport protocol.

     *  Replace existing service-level authentication (OAuth 2.0, mTLS).
        It adds an agent-identity layer on top of existing mechanisms.

     *  Provide content moderation or model output filtering.







  Cao & Arango Gutierrez  Expires 17 September 2026               [Page 4]


  Internet-Draft  Agent Identity Protocol: Agentic Authent      March 2026


  2.  Terminology and Conventions

     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 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

     Agent:
        An autonomous software process that uses a large language model or
        other AI system to reason over tasks and invoke external tools on
        behalf of a principal.

     Agent ID:
        A unique, stable identifier assigned to an agent by an AIP
        Registry at registration time.  The Agent ID is a UUID v4
        [RFC4122] prefixed with the registry hostname, e.g.,
        "reg.example.com/01933f4a-9b2c-7d8e-af01-3b5c6d7e8f9a".

     Agent Record:
        The data structure stored in the AIP Registry that holds an
        agent's Agent ID, public key, principal identifier, and metadata.
        Defined in Section 5.2.

     AIP Proxy (or "Enforcement Proxy"):
        A transparent forward proxy that intercepts tool calls between an
        AI client and tool servers.  It verifies the AIP Token and
        evaluates the AgentPolicy before forwarding or blocking the call.

     AIP Registry:
        A server that stores Agent Records and exposes an HTTP API for
        registration, key lookup, and revocation.

     AIP Token:
        A signed JSON object attached to every tool call by the agent.  It
        carries the agent's Agent ID, the tool being called, a nonce, a
        timestamp, and an key signature.  Defined in Section 5.6.

     AgentPolicy:
        A YAML configuration file that declares which tools an agent is
        permitted to call, argument constraints, DLP rules, and HITL
        requirements.  Defined in Section 6.2.

     DLP:
        Data Loss Prevention; scanning of tool call arguments and
        responses for sensitive data patterns.





  Cao & Arango Gutierrez  Expires 17 September 2026               [Page 5]


  Internet-Draft  Agent Identity Protocol: Agentic Authent      March 2026


     HITL:
        Human-in-the-Loop; a control mode in which the proxy holds a tool
        call and waits for explicit approval from an operator before
        forwarding it.

     IoA:
        Internet of Agents; the network of autonomous AI agents that act
        across organizational and infrastructure boundaries.

     MCP:
        Model Context Protocol [MCP]; a structured protocol for tool-call
        communication between AI clients and tool servers.

     Principal:
        The human operator or organization accountable for an agent.

     Tool Call:
        A structured invocation of an external capability initiated by an
        agent, typically carrying a tool name and arguments.

     Tool Server:
        A service that exposes tools callable by agents.

  3.  Problem Statement

  3.1.  The Identity Gap

     When an AI agent calls a tool, it presents credentials that belong to
     a human account.  The tool server cannot tell whether the actor is a
     human or an agent, which agent it is, or what limits apply to it.
     This creates four concrete problems:

     (a)  Security -- A compromised or manipulated agent can invoke any

          tool the human account can reach.  There is no agent-specific
          authorization boundary.

     (b)  Auditability -- Logs record actions against a human account.

          After an incident, investigators cannot determine which actions
          were taken by a human versus an agent.

     (c)  Compliance -- Regulations increasingly require traceability of

          automated decision-making.  Without agent-level identity,
          organizations cannot satisfy these requirements.

     (d)  Accountability -- Billing, rate limits, and quotas are scoped



  Cao & Arango Gutierrez  Expires 17 September 2026               [Page 6]


  Internet-Draft  Agent Identity Protocol: Agentic Authent      March 2026


          to human accounts.  Agent usage cannot be isolated or
          attributed.

  3.2.  The Enforcement Gap

     Even where agent behavior policies exist, they are expressed as text
     in model system prompts.  System prompts are not tamper-evident and
     can be bypassed by adversarial inputs to the model.  There is no
     infrastructure-layer enforcement point that acts independently of the
     model.

  3.3.  Scope of This Specification

     AIP closes both gaps.  Layer 1 gives every agent a distinct,
     verifiable identity independent of the human principal's credentials.
     Layer 2 enforces agent-specific policy at the tool-call boundary,
     outside the model's trust domain, in a way that cannot be overridden
     by model outputs.

  4.  Protocol Overview

  4.1.  Architecture

     AIP introduces two components into the agent-to-tool-server path: an
     AIP Registry (Layer 1) and an AIP Proxy (Layer 2).


























  Cao & Arango Gutierrez  Expires 17 September 2026               [Page 7]


  Internet-Draft  Agent Identity Protocol: Agentic Authent      March 2026


                      +-----------------------------------------+
                      |           AI Client (Agent)             |
                      +-----------------+-----------------------+
                                        | tools/call + AIP Token
                                        v
                      +-----------------------------------------+
                      |            AIP Proxy (Layer 2)          |
                      |  +-----------+  +--------------------+  |
                      |  |  Verify   |  |   Policy Engine    |  |
                      |  |  Token    |  |   (AgentPolicy)    |  |
                      |  +-----+-----+  +---------+----------+  |
                      |        |                  |              |
                      |  +-----v------------------v----------+  |
                      |  |         Audit Logger              |  |
                      |  +-----------------------------------+  |
                      +-----+-------------------+---------------+
                            |                   |
                     ALLOW  |             DENY  |  HOLD
                            v                   v
                      +-----------+    +------------------+
                      | Tool      |    | Error / HITL     |
                      | Server    |    | Queue            |
                      +-----------+    +------------------+

                      ^
                      | key lookup
                      |
                 +---------+
                 |   AIP   |
                 | Registry|
                 | (Lay. 1)|
                 +---------+

                           Figure 1: AIP Architecture

  4.2.  Call Lifecycle

     The lifecycle of a single tool call under AIP is as follows:

     1.  Registration (once, at deploy time).  The principal registers the
         agent with an AIP Registry.  The registry assigns an Agent ID and
         stores the agent's public key.  The agent stores its private key
         securely.

     2.  Token construction (per call).  Before each tool call the agent
         constructs an AIP Token (Section 5.6): a small JSON object
         containing the Agent ID, tool name, argument hash, nonce,
         timestamp, and a key signature over the token.



  Cao & Arango Gutierrez  Expires 17 September 2026               [Page 8]


  Internet-Draft  Agent Identity Protocol: Agentic Authent      March 2026


     3.  Proxy intercept.  The AIP Proxy receives the tool call request
         before it reaches the tool server.

     4.  Token verification (Layer 1).  The proxy retrieves the agent's
         public key from the registry (or local cache) and verifies the
         signature.  It also checks the nonce for replay and the timestamp
         for freshness.

     5.  Policy evaluation (Layer 2).  The proxy checks the call against
         the AgentPolicy: is the tool on the allowlist?  Do the arguments
         pass validation?  Does the call trigger a HITL hold?  Does the
         response contain sensitive data that must be redacted?

     6.  Decision.  The proxy produces one of three outcomes: ALLOW --
         forward the call to the tool server; DENY -- return an error to
         the agent, tool server not reached; HOLD -- queue the call for
         human approval.

     7.  Audit.  Every decision is written to the audit log regardless of
         outcome.

  4.3.  Relationship to Existing Standards

     *  OAuth 2.0 [RFC6749] / OIDC [OIDC]: AIP does not replace service-
        level authentication.  The agent still presents its OAuth token or
        API key to the tool server.  AIP provides a separate agent
        identity layer that the proxy can verify independently.

     *  SPIFFE/SVID [SPIFFE]: In Kubernetes deployments, the AIP Proxy MAY
        use a SPIFFE SVID to authenticate to tool servers over mTLS,
        layering workload identity on top of AIP agent identity.

     *  JSON-RPC 2.0 [JSON-RPC]: Tool call and error messages use the
        JSON-RPC 2.0 wire format, compatible with MCP and similar
        protocols.

  5.  Layer 1: Agent Identity

  5.1.  Agent Registration

     An agent is provisioned by its principal submitting a registration
     request to an AIP Registry.  The request MUST include:

     (a)  The agent's public key, base64url-encoded [RFC4648];







  Cao & Arango Gutierrez  Expires 17 September 2026               [Page 9]


  Internet-Draft  Agent Identity Protocol: Agentic Authent      March 2026


          (b) The principal identifier -- a string that uniquely
          identifies the accountable human or organization (e.g., an email
          address, an organization slug, or an OAuth subject claim); (TO
          BE WORKED ON FURTHER)

     (c)  A human-readable agent name (RECOMMENDED);

          (d) An optional free-text description.

     The registration request MUST be authenticated.  Authentication MAY
     be via OAuth 2.0 bearer token, mTLS client certificate, or a pre-
     shared registration secret, at the registry operator's discretion.

     On successful registration, the registry:

     (a)  Assigns a UUID v4 [RFC4122] as the agent's local identifier;

          (b) Constructs the Agent ID as "<registry-host>/<uuid>"; (c)
          Stores the Agent Record (Section 5.2); (d) Returns the Agent ID
          to the principal.

     The principal MUST store the Agent ID and configure the agent with
     both the Agent ID and its private key before deployment.

  5.2.  Agent Record

     The Agent Record is the data structure the AIP Registry stores for
     each registered agent.  It MUST contain:

     agentId (string):
        The Agent ID assigned at registration, in the form "<registry-
        host>/<uuid-v4>".  Example:
        "reg.agentidentityprotocol.io/01933f4a-9b2c-7d8e-af01"

     publicKey (string):
        The agent's current public key, base64url-encoded.

     principalId (string):
        Identifier of the accountable principal.

     name (string):
        Human-readable agent name.  Informational only; not authenticated.

     description (string, optional):
        Free-text description of the agent's purpose.

     createdAt (string):
        ISO 8601 UTC timestamp of registration.



  Cao & Arango Gutierrez  Expires 17 September 2026              [Page 10]


  Internet-Draft  Agent Identity Protocol: Agentic Authent      March 2026


     keyHistory (array):
        Append-only list of all public keys ever bound to this Agent ID.
        Each entry contains "publicKey", "activeFrom", and "revokedAt"
        (null if still active).

     status (string):
        One of "active" or "revoked".

     Example Agent Record (JSON):

     {
       "agentId": "reg.agentidentityprotocol.io/01933f4a-9b2c-7d8e-af01",
       "publicKey": "MCowBQYDK2VwAyEAz8vG...",
       "principalId": "acme-corp",
       "name": "ResearchAssistant-v1",
       "description": "Internal document retrieval agent",
       "createdAt": "2026-01-15T09:00:00Z",
       "keyHistory": [
         {
           "publicKey": "MCowBQYDK2VwAyEAz8vG...",
           "activeFrom": "2026-01-15T09:00:00Z",
           "revokedAt": null
         }
       ],
       "status": "active"
     }

  5.3.  AIP Registry API

     The AIP Registry MUST expose the following HTTP endpoints over TLS
     1.3 (Section 9.4):

     POST   /v1/agents              Register a new agent
     GET    /v1/agents/{agentId}    Retrieve an Agent Record
     PUT    /v1/agents/{agentId}/key  Rotate the agent's public key
     DELETE /v1/agents/{agentId}    Revoke an agent
     GET    /v1/revocations/stream  SSE stream for revocation events

     The GET /v1/agents/{agentId} endpoint is the only endpoint that MUST
     be reachable by AIP Proxies at call-verification time.  All other
     endpoints are used during provisioning and key management.

     Responses from GET /v1/agents/{agentId} MUST include the full Agent
     Record.  Proxies SHOULD cache this response for at least 30 seconds.
     The cache MUST be invalidated on receipt of a revocation event from
     the SSE stream.





  Cao & Arango Gutierrez  Expires 17 September 2026              [Page 11]


  Internet-Draft  Agent Identity Protocol: Agentic Authent      March 2026


  5.4.  Key Rotation

     A principal rotates an agent's key by submitting a PUT request to
     /v1/agents/{agentId}/key, authenticated with the current private key.
     The request body MUST contain the new public key.

     The registry MUST:
          (a) Set "revokedAt" on the current keyHistory entry to the
          current timestamp;

     (b) 
          Append a new keyHistory entry with the new public key;

          (c) Update the "publicKey" field on the Agent Record; (d) Emit a
          rotation event on the revocations SSE stream so that proxies can
          invalidate their cached Agent Records immediately.

     The Agent ID does NOT change on key rotation.

  5.5.  Agent Revocation

     A principal revokes an agent by sending a DELETE request to /v1/
     agents/{agentId}.  The registry MUST set the agent's status to
     "revoked" and emit a revocation event on the SSE stream.

     Proxies MUST reject AIP Tokens from revoked agents with error AIP-
     E012.  Revoked Agent Records MUST be retained in the registry for
     audit log verification but MUST NOT be returned as "active".

  5.6.  The AIP Token (Agent Attestation Token)

     The AIP Token is a compact signed JSON object that the agent
     constructs and attaches to every outbound tool call.  It is the
     mechanism by which the agent asserts its identity to the proxy.

  5.6.1.  Token Fields

     aipVersion (string, REQUIRED):
        Protocol version.  MUST be "1" for this specification.

     agentId (string, REQUIRED):
        The agent's Agent ID as registered with the AIP Registry.

     tool (string, REQUIRED):
        The name of the tool being called, exactly as declared in the tool
        server's manifest.





  Cao & Arango Gutierrez  Expires 17 September 2026              [Page 12]


  Internet-Draft  Agent Identity Protocol: Agentic Authent      March 2026


     argumentsHash (string, REQUIRED):
        Lowercase hex-encoded SHA-256 hash of the canonical JSON
        serialization of the tool call arguments.  This binds the token to
        the specific arguments being passed.

     nonce (string, REQUIRED):
        A 128-bit cryptographically random value, hex-encoded.  MUST be
        unique per token.  MUST be generated by a CSPRNG.

     timestamp (string, REQUIRED):
        ISO 8601 UTC timestamp of token construction.

     signature (string, REQUIRED):
        Base64url-encoded signature over the canonical serialization of
        the token (Section 5.6.2).

  5.6.2.  Canonical Serialization

     To produce the bytes that are signed:

     (a)  Construct a JSON object containing all token fields except

          "signature";

     (b)  Serialize with no insignificant whitespace;

          (c) Sort object keys lexicographically; (d) Encode as UTF-8.

     The signature field is then set to the base64url encoding of the
     signature over these bytes.

  5.6.3.  Example Token (before base64url encoding for transport)

     {
       "aipVersion": "1",
       "agentId": "reg.agentidentityprotocol.io/01933f4a-9b2c-7d8e-af01",
       "tool": "read_file",
       "argumentsHash": "e3b0c44298fc1c149afb4c8996fb924...",
       "nonce": "a3f8b2c1d4e5f607a8b9c0d1e2f3a4b5",
       "timestamp": "2026-02-24T14:30:00Z",
       "signature": "TUlJQ0lqQU5CZ2txaGtpRzl3MEJB..."
     }

  5.7.  Token Verification

     The AIP Proxy MUST perform the following checks in order.  A failure
     at any step MUST produce a DENY decision with the corresponding error
     code (Section 7.2) and an audit log entry.



  Cao & Arango Gutierrez  Expires 17 September 2026              [Page 13]


  Internet-Draft  Agent Identity Protocol: Agentic Authent      March 2026


     Step 1 -- Presence check.
        Confirm the AIP Token is present in the request.  On failure: AIP-
        E010.

     Step 2 -- Agent Record lookup.
        Resolve the Agent ID from the token against the AIP Registry (or
        local cache).  Confirm the Agent Record status is "active".  On
        failure: AIP-E011 (unresolvable) or AIP-E012 (revoked).

     Step 3 -- Signature verification.
        Compute the canonical serialization (Section 5.6.2) and verify the
        key signature against the public key in the Agent Record.  This
        operation MUST be performed in constant time.  On failure: AIP-
        E013.

     Step 4 -- Nonce replay check.
        Check the nonce against the proxy's local nonce cache (minimum
        TTL: 600 seconds).  If the nonce has been seen before, reject.  On
        failure: AIP-E004.

     Step 5 -- Timestamp freshness.
        Reject the token if its timestamp is more than 300 seconds in the
        past or 30 seconds in the future relative to the proxy clock.  On
        failure: AIP-E005.

     If all five steps pass, the token is verified and the call proceeds
     to policy evaluation (Section 6.3).

  6.  Layer 2: Enforcement Proxy

  6.1.  Proxy Architecture

     The AIP Proxy is a forward proxy interposed between the AI client and
     one or more tool servers.  It is transparent: it presents itself to
     the AI client as the tool server endpoint, and to the tool server as
     an authorized caller.

     The proxy operates in one of two modes, set per agent in the
     AgentPolicy:

     enforce:  Policy violations result in DENY responses.  The tool

               server is never reached for blocked calls.  This is the
               default and RECOMMENDED mode.

     monitor:  Policy violations are logged but calls are forwarded





  Cao & Arango Gutierrez  Expires 17 September 2026              [Page 14]


  Internet-Draft  Agent Identity Protocol: Agentic Authent      March 2026


               regardless.  Used for baselining and policy development
               before switching to enforce mode.

     The proxy MUST maintain locally:

     o  The AgentPolicy for each agent it serves;
     o  A bounded nonce cache (TTL >= 600 seconds, LRU eviction);
     o  A revocation cache (refresh interval <= 60 seconds);
     o  An append-only audit log.

  6.2.  AgentPolicy

     The AgentPolicy is a YAML file that declares the enforcement rules
     for a specific agent.  One AgentPolicy file corresponds to one Agent
     ID.  A AgentPolicy file can apply to multiple Agent IDs.

  6.2.1.  Schema

     <CODE BEGINS>
        agentId: <Agent ID>
        mode: <enforce | monitor>

        tools:
          allowed:
            - <tool-name>
          rules:
            - tool: <tool-name>
              action: <allow | ask | block>
              args:
                <arg-name>:
                  pattern: <PCRE regex>
                  maxLength: <integer>

        dlp:
          - name: <pattern name>
            regex: <PCRE regex>
            action: <redact | block>
            scope: <request | response | both>

        hitl:
          approvers:
            - <email or identifier of approver>
          timeout_seconds: <integer, default 300>  # seconds to wait for approval
          on_timeout: <deny | allow>               # action if no response received
     <CODE ENDS>






  Cao & Arango Gutierrez  Expires 17 September 2026              [Page 15]


  Internet-Draft  Agent Identity Protocol: Agentic Authent      March 2026


  6.2.2.  Tool Allowlist

     The tools.allowed list defines every tool the agent is permitted to
     call.  Any call to a tool not on this list MUST be denied with
     AIP-E001 when the proxy is in enforce mode.

  6.2.3.  Tool Rules

     Each entry in tools.rules applies additional handling to a named
     tool:

     allow:  The tool is on the allowlist and is forwarded after

             argument validation.  This is the default when no rule is
             specified.

     ask:    The call is held for HITL approval before forwarding,

             regardless of any other policy check.

     block:  The call is unconditionally denied.  This overrides the

             allowlist and cannot be circumvented.  Use this for tools
             that must never be reachable by the agent under any
             circumstances.

     Argument rules (args) apply PCRE regex pattern matching and a maximum
     length check to named arguments before the call is forwarded.  A
     violation produces AIP-E002.

  6.2.4.  DLP Rules

     Each DLP rule specifies a regex pattern, an action, and a scope:

     redact / request:   Matching content in arguments is replaced with

                         "[REDACTED:<name>]" and the call proceeds.

     redact / response:  Matching content in the tool response is

                         replaced with "[REDACTED:<name>]" before the
                         response is returned to the agent.

     block / both:       If a match is found anywhere in the request

                         or response, the call or response is rejected
                         with AIP-E008.




  Cao & Arango Gutierrez  Expires 17 September 2026              [Page 16]


  Internet-Draft  Agent Identity Protocol: Agentic Authent      March 2026


  6.2.5.  HITL Configuration

     The hitl block identifies who may approve held calls, how long the
     proxy waits, and what to do on timeout.  The default on_timeout is
     "deny".  Setting on_timeout to "allow" SHOULD only be used for non-
     sensitive, low-impact tools.

  6.3.  Intercept Flow

     The following is the normative sequence for every tool call received
     by the proxy.

     1.  Receive the tool call from the AI client.

     2.  Run token verification (Section 5.7).
         Any failure -> DENY with the corresponding AIP-Exxx code.

     3.  Check tools.allowed.
         Tool not present and mode == enforce -> DENY AIP-E001.

     4.  Check tools.rules for this tool.
         action == block -> DENY AIP-E003.
         action == ask   -> go to step 7 (HITL).

     5.  Validate arguments against any matching tools.rules.args.
         Violation -> DENY AIP-E002.

     6.  Run DLP scan on request arguments.
         block match -> DENY AIP-E008.
         redact match -> replace content, continue.

     7.  If action == ask: submit to HITL queue (Section 6.5).
         Approved -> continue to step 8.
         Denied   -> DENY AIP-E015.
         Timed out -> resolve per on_timeout.

     8.  ALLOW: forward the call to the tool server.

     9.  Receive the tool server response.

     10. Run DLP scan on the response.
         block match -> return AIP-E008 to agent, suppress response.
         redact match -> replace content, continue.

     11.  Return the (possibly redacted) response to the agent.

     12.  Write audit log record (Section 6.7).




  Cao & Arango Gutierrez  Expires 17 September 2026              [Page 17]


  Internet-Draft  Agent Identity Protocol: Agentic Authent      March 2026


  6.4.  Decision Outcomes

     ALLOW:  The call passed all checks and was forwarded.  The tool

             server response was returned to the agent.

     DENY:   The call was rejected before reaching the tool server.

             The proxy returns a JSON-RPC 2.0 error (Section 7.2).  The
             tool server receives nothing.

     HOLD:   The call is queued.  The proxy returns a pending response

             to the agent.  The call is resolved when a human approver
             responds or the HITL timeout is reached.

  6.5.  Human-in-the-Loop (HITL)

     When a call is held, the proxy MUST notify all addresses listed in
     hitl.approvers.  The notification MUST include:

     *  The Agent ID and agent name;

     *  The tool name and (post-redaction) arguments;

     *  The policy rule that triggered the hold;

     *  A unique hold_id.

     Notification delivery (email, webhook, Slack, web UI) is out of scope
     for this specification.

     Approvers submit a decision to the proxy using the HITL API.
     Approval and denial endpoints are:

        POST /v1/hitl/{hold_id}/approve
        POST /v1/hitl/{hold_id}/deny

     These endpoints MUST be authenticated.  If no response is received
     within hitl.timeout_seconds, the proxy resolves the hold according to
     hitl.on_timeout and writes the outcome to the audit log.

  6.6.  Data Loss Prevention (DLP)

     The DLP scanner applies the dlp rules from the AgentPolicy to both
     the inbound tool call arguments and the outbound tool server
     response.  Rules are evaluated in the order they are listed.  The
     first matching rule wins.



  Cao & Arango Gutierrez  Expires 17 September 2026              [Page 18]


  Internet-Draft  Agent Identity Protocol: Agentic Authent      March 2026


     Implementations SHOULD provide a standard rule library covering
     common sensitive data types:

     *  Cloud provider credentials (AWS, GCP, Azure key patterns);

     *  Private key material (PEM headers);

     *  Common PII patterns (email, phone, SSN formats);

     *  Generic high-entropy secrets (long alphanumeric tokens).

  6.7.  Audit Logging

     The proxy MUST write one log record per tool call outcome.  Records
     MUST be appended to an append-only log and MUST NOT be modified after
     writing.

     Log records SHOULD be hash-chained: each record includes the SHA-256
     hash of the previous record, enabling tamper detection.

     See Section 7.3 for the normative record format.

     Log records MUST be retained for a minimum of 90 days.

  7.  Wire Formats

  7.1.  AIP-Token Header

     For HTTP-based tool transports, the AIP Token is conveyed in the
     request header:

        AIP-Token: <base64url-encoded UTF-8 JSON token>

     base64url encoding is defined in [RFC4648] Section 5 (no padding).

     For MCP stdio transports, the AIP Token is conveyed as a "_aip" field
     at the top level of the JSON-RPC request object:














  Cao & Arango Gutierrez  Expires 17 September 2026              [Page 19]


  Internet-Draft  Agent Identity Protocol: Agentic Authent      March 2026


     {
       "jsonrpc": "2.0",
       "method": "tools/call",
       "id": 1,
       "params": {
         "name": "read_file",
         "arguments": { "path": "/data/report.txt" }
       },
       "_aip": {
         "aipVersion": "1",
         "agentId": "reg.agentidentityprotocol.io/01933f4a...",
         "tool": "read_file",
         "argumentsHash": "e3b0c44298...",
         "nonce": "a3f8b2c1d4e5f607...",
         "timestamp": "2026-02-24T14:30:00Z",
         "signature": "TUlJQ0lq..."
       }
     }

  7.2.  Error Response Format

     Error responses MUST conform to JSON-RPC 2.0 [JSON-RPC].  AIP error
     codes are in the range -32001 to -32099:




























  Cao & Arango Gutierrez  Expires 17 September 2026              [Page 20]


  Internet-Draft  Agent Identity Protocol: Agentic Authent      March 2026


     Code     ID        Meaning
     ------   --------  -----------------------------------------------
     -32001   AIP-E001  Tool not in allowlist
     -32002   AIP-E002  Argument validation failed
     -32003   AIP-E003  Tool unconditionally blocked
     -32004   AIP-E004  Nonce replay detected
     -32005   AIP-E005  Timestamp out of range
     -32008   AIP-E008  DLP violation
     -32010   AIP-E010  AIP Token missing
     -32011   AIP-E011  Agent ID not found in registry
     -32012   AIP-E012  Agent revoked
     -32013   AIP-E013  Signature verification failed
     -32015   AIP-E015  HITL approval denied
     -32016   AIP-E016  HITL timed out
     -32099   AIP-E099  Internal proxy error

     Example error response:

     {
       "jsonrpc": "2.0",
       "id": 1,
       "error": {
         "code": -32001,
         "message": "AIP-E001: tool not in allowlist",
         "data": {
           "aipCode": "AIP-E001",
           "agentId": "reg.agentidentityprotocol.io/01933f4a...",
           "tool": "exec_command"
         }
       }
     }

  7.3.  Audit Log Record

     Each record is a single JSON object on one line (JSONL [JSONL]):
















  Cao & Arango Gutierrez  Expires 17 September 2026              [Page 21]


  Internet-Draft  Agent Identity Protocol: Agentic Authent      March 2026


     {
       "v": 1,
       "ts": "<ISO 8601 UTC>",
       "eventId": "<UUID v4>",
       "prevHash": "<SHA-256 hex of previous record, or null>",
       "decision": "<ALLOW | DENY | HOLD>",
       "errorCode": "<AIP-Exxx or null>",
       "agentId": "<Agent ID>",
       "principalId": "<principal identifier>",
       "tool": "<tool name>",
       "argumentsHash": "<SHA-256 hex>",
       "policyName": "<AgentPolicy agentId value>",
       "verificationStep": "<1-5 or null if passed>",
       "dlp": [
         { "rule": "<rule name>", "scope": "<request|response>",
           "action": "<redacted|blocked>" }
       ],
       "holdId": "<UUID or null>",
       "proxyVersion": "<semver>"
     }

  8.  Deployment Topologies

  8.1.  Localhost Proxy

     The localhost proxy is the simplest deployment: a single binary
     running on the developer's machine alongside the AI client.  It binds
     to 127.0.0.1:8787 (configurable), supports HTTP and MCP stdio
     interception, and uses a local SQLite database for the nonce cache,
     revocation cache, and audit log.  Policy is loaded from a YAML file
     at ~/.aip/policy.yaml.

     This mode is suitable for individual developers and is the
     recommended starting point for adopting AIP.  A Go proxy
     implementation is available at the working group's GitHub repository.

  8.2.  Kubernetes Sidecar

     For production deployments, the AIP Proxy runs as a sidecar container
     in the same pod as the agent container.  Outbound tool-server traffic
     is redirected through the proxy on port 15001 via iptables REDIRECT
     rules.  Policy is loaded from a Kubernetes ConfigMap or Secret.
     Storage uses Redis for the distributed nonce cache and a
     PersistentVolumeClaim for the audit log.  A Prometheus metrics
     endpoint is exposed at /metrics.

     Exported metrics include: aip_calls_total, aip_denials_total,
     aip_holds_total, and aip_verification_latency_seconds.



  Cao & Arango Gutierrez  Expires 17 September 2026              [Page 22]


  Internet-Draft  Agent Identity Protocol: Agentic Authent      March 2026


  8.3.  Enterprise Federation

     In enterprise environments the AIP Proxy integrates with existing
     identity infrastructure:

     *  OIDC mapping: The registry maintains a table mapping Agent IDs to
        OIDC subject claims.  When a tool server requires an OIDC token,
        the proxy can present one on the agent's behalf after AIP
        verification passes, without the agent holding OIDC credentials
        directly.

     *  SPIFFE/mTLS: The proxy is issued a SPIFFE SVID and uses it to
        establish mTLS connections to tool servers, providing transport-
        layer mutual authentication in addition to AIP application-layer
        identity.

     *  Central policy management: AgentPolicy files are managed via a
        policy API with versioning, rollback, and change auditing, rather
        than local YAML files.

  9.  Security Considerations

  9.1.  Cryptographic Algorithm

     AIP is built with the idea of using Ed25519 [RFC8032] for all
     signatures.  Ed25519 was chosen because it is fast (sign and verify
     in under 1ms), produces short keys and signatures (32 and 64 bytes
     respectively), is deterministic (no per-signature randomness
     required), and has broad library support across all major languages
     and platforms.  However other cryptographic algorithms should be
     supported.

     All Ed25519 operations MUST use a constant-time
     implementation to prevent timing side-channels (Section 9.3).

  9.2.  Prompt Injection Resistance

     The principal threat model for AIP at Layer 2 is the prompt injection
     attack: malicious content in the agent's context causes it to attempt
     tool calls outside its intended scope.

     The allowlist in the AgentPolicy prevents the agent from reaching
     tools it was not provisioned for, regardless of what the model
     produces.  The "block" action provides an unconditional deny for
     specified tools that cannot be overridden by any model output,
     injected prompt, or delegation claim.  The proxy operates entirely
     outside the model's trust boundary; the model cannot influence the
     proxy's decisions.



  Cao & Arango Gutierrez  Expires 17 September 2026              [Page 23]


  Internet-Draft  Agent Identity Protocol: Agentic Authent      March 2026


     AIP does not protect against:
     o  A compromised agent runtime that routes calls around the proxy;
     o  Tool servers that accept calls from sources other than the proxy.

  9.3.  Transport Security

     All communication between AIP Proxies and the AIP Registry MUST use
     TLS 1.3 [RFC8446].  Server certificates MUST be validated against the
     system trust store.  Certificate pinning is RECOMMENDED for registry
     connections in production deployments.

     Proxy-to-tool-server connections MUST use TLS 1.2 [RFC5246] or later.
     TLS 1.3 is RECOMMENDED.

  9.4.  Private Key Storage

     Agent private keys MUST be stored in a secure key store.  In order of
     preference:

     1.  Hardware Security Module (HSM) or Trusted Platform Module (TPM);
     2.  OS keychain (macOS Keychain, Windows DPAPI, Linux Secret
     Service); 3.  Encrypted file with passphrase derived using Argon2id
     [RFC9106].

     Private keys MUST NOT be stored in environment variables, plaintext
     configuration files, or source code repositories.

  9.5.  Registry Trust

     A proxy MUST be configured with an explicit list of trusted registry
     hostnames and the TLS certificate fingerprint (or CA) for each.
     Agent Records from registries not on this list MUST be rejected.

  9.6.  Nonce Cache Sizing

     The nonce cache must be large enough to hold all unique nonces
     generated within the TTL window (600 seconds).  Implementations MUST
     use a bounded cache with LRU eviction and MUST NOT silently drop old
     nonces without ensuring they are outside the TTL window.

  9.7.  Revocation Latency

     The proxy's revocation cache has a maximum refresh interval of 60
     seconds (Section 6.1).  In the worst case, a revoked agent can
     continue making calls for up to 60 seconds after revocation.
     Deployments with stricter requirements SHOULD subscribe to the
     registry's SSE revocation stream (Section 5.3) and invalidate the
     cache on receipt of a revocation event.



  Cao & Arango Gutierrez  Expires 17 September 2026              [Page 24]


  Internet-Draft  Agent Identity Protocol: Agentic Authent      March 2026


  9.8.  Denial-of-Service

     The proxy adds a small amount of latency to every tool call (one
     cache lookup and one key verification).  To prevent the proxy from
     becoming an availability bottleneck:

     *  Agent Record lookups MUST be served from the local cache except on
        cache miss or invalidation;

     *  The proxy SHOULD enforce a per-agent call rate limit to prevent a
        runaway agent from flooding the registry with cache-miss lookups.

  10.  Privacy Considerations

  10.1.  Agent Record Visibility

     Agent Records are visible to any party that can query the registry.
     Principals SHOULD use non-identifying agent names for agents that
     handle sensitive workloads.

  10.2.  Audit Log Sensitivity

     Audit logs contain Agent IDs, tool names, and argument hashes.  While
     argument values are not logged in plaintext, the combination of Agent
     ID and tool name may itself be sensitive in some contexts.  Audit
     logs MUST be access-controlled appropriately.

  10.3.  DLP Redaction

     When DLP redaction is applied to a response, the proxy modifies the
     data the agent receives.  Operators MUST ensure that redaction does
     not cause the agent to produce incorrect or harmful downstream
     actions due to missing context.

  10.4.  Registry Data Retention

     Registry operators MUST publish a data retention policy.  Agent
     Records for revoked agents SHOULD be pseudonymized after the minimum
     retention period required for audit log verification.

  11.  IANA Considerations










  Cao & Arango Gutierrez  Expires 17 September 2026              [Page 25]


  Internet-Draft  Agent Identity Protocol: Agentic Authent      March 2026


  11.1.  HTTP Header Field

     This document defines the "AIP-Token" HTTP header field.
     Registration is requested in the "Permanent Message Header Field
     Names" registry per [RFC3864].  The header field name is "AIP-Token",
     applicable protocol is "http", status is "standard", the author/
     change controller is the IETF, and the specification document is this
     document (Section 7.1).

  11.2.  Media Type

     The media type "application/aip+json" is requested for AIP Tokens
     serialized as standalone JSON documents.  The type name is
     "application", the subtype name is "aip+json", the required parameter
     is "version" (value "1"), encoding considerations are UTF-8, and
     security considerations are described in Section 9.

  12.  References

  12.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/info/rfc2119>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/info/rfc8174>.

     [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
                Signature Algorithm (EdDSA)", RFC 8032,
                DOI 10.17487/RFC8032, January 2017,
                <https://www.rfc-editor.org/info/rfc8032>.

     [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
                Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
                <https://www.rfc-editor.org/info/rfc8446>.

     [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
                (TLS) Protocol Version 1.2", RFC 5246,
                DOI 10.17487/RFC5246, August 2008,
                <https://www.rfc-editor.org/info/rfc5246>.

     [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
                Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
                <https://www.rfc-editor.org/info/rfc4648>.




  Cao & Arango Gutierrez  Expires 17 September 2026              [Page 26]


  Internet-Draft  Agent Identity Protocol: Agentic Authent      March 2026


     [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
                Unique IDentifier (UUID) URN Namespace", RFC 4122,
                DOI 10.17487/RFC4122, July 2005,
                <https://www.rfc-editor.org/info/rfc4122>.

     [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
                RFC 6749, DOI 10.17487/RFC6749, October 2012,
                <https://www.rfc-editor.org/info/rfc6749>.

     [RFC9106]  Biryukov, A., Dinu, D., Khovratovich, D., and S.
                Josefsson, "Argon2 Memory-Hard Function for Password
                Hashing and Proof-of-Work Applications", RFC 9106,
                DOI 10.17487/RFC9106, September 2021,
                <https://www.rfc-editor.org/info/rfc9106>.

     [JSON-RPC] JSON-RPC Working Group, "JSON-RPC 2.0 Specification",
                January 2013.

     [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
                Procedures for Message Header Fields", BCP 90, RFC 3864,
                DOI 10.17487/RFC3864, September 2004,
                <https://www.rfc-editor.org/info/rfc3864>.

  12.2.  Informative References

     [MCP]      Anthropic, "Model Context Protocol", November 2024.

     [OIDC]     Sakimura, N. et al., "OpenID Connect Core 1.0", November
                2014.

     [SPIFFE]   CNCF SPIFFE Project, "SPIFFE: Secure Production Identity
                Framework for Everyone", 2024.

     [JSONL]    Granger, N., "JSON Lines", 2014.

  Appendix A.  Example AgentPolicy

     A complete AgentPolicy for a research assistant agent.













  Cao & Arango Gutierrez  Expires 17 September 2026              [Page 27]


  Internet-Draft  Agent Identity Protocol: Agentic Authent      March 2026


     <CODE BEGINS>
        agentId: reg.agentidentityprotocol.io/01933f4a-9b2c-7d8e-af01
        mode: enforce

        tools:
          - allowed:
            - read_file
            - list_directory
            - web_search
            - git_status
            - write_file
            - create_issue
          - rules:
            - tool: write_file
              action: ask
            - tool: exec_command
              action: block
            - tool: delete_file
              action: block
            - tool: create_issue
              action: ask

        dlp:
          - name: aws-access-key
            regex: "AKIA[A-Z0-9]{16}"
            action: block
            scope: both
          - name: private-key-pem
            regex: "-----BEGIN [A-Z ]* PRIVATE KEY-----"
            action: block
            scope: both
          - name: generic-token
            regex: "[a-zA-Z0-9_\\-]{40,}"
            action: redact
            scope: response

        hitl:
          - approvers:
            - ops@acme.example
          - timeout_seconds: 300  # wait 5 minutes
          - on_timeout: deny
     <CODE ENDS>

  Appendix B.  Example AIP Token

     An AIP Token for a read_file call, shown before base64url encoding
     for transport in the AIP-Token header.




  Cao & Arango Gutierrez  Expires 17 September 2026              [Page 28]


  Internet-Draft  Agent Identity Protocol: Agentic Authent      March 2026


  {
    "aipVersion": "1",
    "agentId": "reg.agentidentityprotocol.io/01933f4a-9b2c-7d8e-af01",
    "tool": "read_file",
    "argumentsHash": "e3b0c44298fc1c149afb4c8996fb92427ae41e4649b934ca495991b7852b855",
    "nonce": "a3f8b2c1d4e5f607a8b9c0d1e2f3a4b5",
    "timestamp": "2026-02-24T14:30:00Z",
    "signature": "TUlJQ0lqQU5CZ2txaGtpRzl3MEJBUUVGQUFOQ0E..."
  }

  Appendix C.  Error Code Reference

     AIP-E001  Tool not in allowlist

               The requested tool is not listed in tools.allowed and the
               proxy is in enforce mode.

     AIP-E002  Argument validation failed

               A tool argument failed a pattern or maxLength check defined
               in tools.rules.args.

     AIP-E003  Tool unconditionally blocked

               The tool has action: block in tools.rules.

     AIP-E004  Nonce replay

               The nonce in the AIP Token was already seen within the
               600-second cache window.

     AIP-E005  Timestamp out of range

               The token timestamp is more than 300 seconds old or more
               than 30 seconds in the future.

     AIP-E008  DLP violation

               A DLP rule with action: block matched content in the
               request or response.

     AIP-E010  AIP Token missing

               The tool call arrived with no AIP-Token header or _aip
               field.

     AIP-E011  Agent ID not found




  Cao & Arango Gutierrez  Expires 17 September 2026              [Page 29]


  Internet-Draft  Agent Identity Protocol: Agentic Authent      March 2026


               The agentId in the token could not be resolved at the
               registry.

     AIP-E012  Agent revoked

               The Agent Record for this agentId has status: revoked.

     AIP-E013  Signature verification failed

               The key signature did not verify against the public key in
               the Agent Record.

     AIP-E015  HITL approval denied

               A human approver explicitly denied the held call.

     AIP-E016  HITL timed out

               The HITL hold expired and on_timeout is set to deny.

     AIP-E099  Internal proxy error

               An unexpected error occurred in the proxy.  See proxy logs
               for details.

  Authors' Addresses

     James Cao
     Montcao
     Email: james@montcao.com
     URI:   https://agentidentityprotocol.io


     Carlos Eduardo Arango Gutierrez
     NVIDIA
     Email: eduardoa@nvidia.com
     URI:   https://agentidentityprotocol.io














  Cao & Arango Gutierrez  Expires 17 September 2026              [Page 30]


name: draft-niyikiza-oauth-attenuating-agent-tokens
rev: 00
title: Attenuating Authorization Tokens for Agentic Delegation Chains
time: 2026-03-17T06:51:37Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-18T06:51:37Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Policy/governance", "AI safety/alignment"]
tags: []
fetched_at: 2026-05-22T09:24:40.604520+00:00
source: ietf
abstract:
  This document defines Attenuating Authorization Tokens (AATs), a JWT-
     based credential format for secure delegation in AI agent systems.
     An AAT encodes which tools an agent may invoke and with what argument
     constraints.  Any holder can derive a more restrictive token offline
     that narrows or maintains scope but cannot expand it.  This invariant
     is cryptographically enforced and verifiable offline by any party
     holding the root token's trust anchor key.

     This specification extends the Rich Authorization Requests format
     (RFC 9396) with delegation-chain semantics and defines a typed
     constraint vocabulary for tool-level argument restrictions.  The
     accompanying chain verification algorithm enforces the monotonic
     attenuation invariant at each delegation step and requires no network
     contact with the root issuer.

full_text:
  Web Authorization Protocol (OAuth)                        N. A. Niyikiza
  Internet-Draft                                                     Tenuo
  Intended status: Standards Track                           16 March 2026
  Expires: 17 September 2026


       Attenuating Authorization Tokens for Agentic Delegation Chains
              draft-niyikiza-oauth-attenuating-agent-tokens-00

  Abstract

     This document defines Attenuating Authorization Tokens (AATs), a JWT-
     based credential format for secure delegation in AI agent systems.
     An AAT encodes which tools an agent may invoke and with what argument
     constraints.  Any holder can derive a more restrictive token offline
     that narrows or maintains scope but cannot expand it.  This invariant
     is cryptographically enforced and verifiable offline by any party
     holding the root token's trust anchor key.

     This specification extends the Rich Authorization Requests format
     (RFC 9396) with delegation-chain semantics and defines a typed
     constraint vocabulary for tool-level argument restrictions.  The
     accompanying chain verification algorithm enforces the monotonic
     attenuation invariant at each delegation step and requires no network
     contact with the root issuer.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 17 September 2026.

  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.




  Niyikiza                Expires 17 September 2026               [Page 1]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.  Limitations of Existing OAuth Mechanisms for Agentic
             Delegation  . . . . . . . . . . . . . . . . . . . . . . .   5
       1.2.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .   6
       1.3.  Relationship to Prior Work  . . . . . . . . . . . . . . .   6
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.  Token Types and Structure . . . . . . . . . . . . . . . . . .   9
       3.1.  Token Types . . . . . . . . . . . . . . . . . . . . . . .   9
       3.2.  Common Claims . . . . . . . . . . . . . . . . . . . . . .  10
       3.3.  Capability Claims via authorization_details . . . . . . .  13
         3.3.1.  Tool Identifier Requirements  . . . . . . . . . . . .  14
       3.4.  Argument Constraints  . . . . . . . . . . . . . . . . . .  15
       3.5.  Extension Constraint Registry . . . . . . . . . . . . . .  18
         3.5.1.  Attenuation Compliance Requirement  . . . . . . . . .  18
         3.5.2.  Enforcement Point Obligations . . . . . . . . . . . .  19
         3.5.3.  Example Registration: Path Containment  . . . . . . .  20
       3.6.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .  21
         3.6.1.  Root Delegation Token . . . . . . . . . . . . . . . .  21
         3.6.2.  Derived Execution Token . . . . . . . . . . . . . . .  22
       3.7.  Root Issuer Support and Root Token Issuance . . . . . . .  23
         3.7.1.  Root Issuer Discovery . . . . . . . . . . . . . . . .  24
         3.7.2.  Agent Token Request . . . . . . . . . . . . . . . . .  24
         3.7.3.  Root Token Issuance . . . . . . . . . . . . . . . . .  25
     4.  Attenuation Invariants  . . . . . . . . . . . . . . . . . . .  26
       4.1.  Capability Lattice Model (Non-Normative)  . . . . . . . .  26
       4.2.  I1: Delegation Authority  . . . . . . . . . . . . . . . .  27
       4.3.  I2: Depth Monotonicity  . . . . . . . . . . . . . . . . .  27
         4.3.1.  Implementation Resource Limits  . . . . . . . . . . .  28
       4.4.  I3: TTL Monotonicity  . . . . . . . . . . . . . . . . . .  28
       4.5.  I4: Capability Monotonicity . . . . . . . . . . . . . . .  29
       4.6.  I5: Cryptographic Linkage . . . . . . . . . . . . . . . .  35
       4.7.  I6: Proof of Possession . . . . . . . . . . . . . . . . .  35
     5.  Proof of Possession . . . . . . . . . . . . . . . . . . . . .  35
       5.1.  Rationale . . . . . . . . . . . . . . . . . . . . . . . .  35
       5.2.  PoP Token Structure . . . . . . . . . . . . . . . . . . .  36
       5.3.  Verification  . . . . . . . . . . . . . . . . . . . . . .  37
     6.  Token Derivation  . . . . . . . . . . . . . . . . . . . . . .  38



  Niyikiza                Expires 17 September 2026               [Page 2]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     7.  Chain Verification Algorithm  . . . . . . . . . . . . . . . .  39
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .  44
       8.1.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .  45
         8.1.1.  Threats Mitigated . . . . . . . . . . . . . . . . . .  45
         8.1.2.  Threats Not Mitigated . . . . . . . . . . . . . . . .  46
       8.2.  Attenuation as the Security Invariant . . . . . . . . . .  47
       8.3.  Root Key Compromise . . . . . . . . . . . . . . . . . . .  47
       8.4.  Holder Key Compromise . . . . . . . . . . . . . . . . . .  48
       8.5.  Chain Splicing  . . . . . . . . . . . . . . . . . . . . .  48
       8.6.  Replay Attacks  . . . . . . . . . . . . . . . . . . . . .  48
       8.7.  Constraint Evaluation . . . . . . . . . . . . . . . . . .  49
       8.8.  Depth Limit . . . . . . . . . . . . . . . . . . . . . . .  49
       8.9.  Unknown Constraint Types  . . . . . . . . . . . . . . . .  50
       8.10. Token Revocation  . . . . . . . . . . . . . . . . . . . .  50
       8.11. Clock Skew  . . . . . . . . . . . . . . . . . . . . . . .  50
       8.12. Type-Transition Key Separation  . . . . . . . . . . . . .  51
       8.13. CEL Conjunction Privilege Escalation  . . . . . . . . . .  51
       8.14. Algorithm Confusion . . . . . . . . . . . . . . . . . . .  52
       8.15. Token Content Visibility  . . . . . . . . . . . . . . . .  52
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  52
       9.1.  JWT Claims Registry . . . . . . . . . . . . . . . . . . .  52
       9.2.  OAuth Authorization Details Types Registry  . . . . . . .  54
       9.3.  AAT Constraint Type Registry  . . . . . . . . . . . . . .  54
         9.3.1.  Designated Expert Instructions  . . . . . . . . . . .  54
         9.3.2.  Registration Template . . . . . . . . . . . . . . . .  55
         9.3.3.  Initial Registry Entries  . . . . . . . . . . . . . .  56
       9.4.  OAuth Authorization Server Metadata Registry  . . . . . .  57
       9.5.  OAuth Token Type Registration . . . . . . . . . . . . . .  58
       9.6.  OAuth Token Endpoint Parameters Registry  . . . . . . . .  58
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  58
       10.1.  Normative References . . . . . . . . . . . . . . . . . .  58
       10.2.  Informative References . . . . . . . . . . . . . . . . .  60
     Appendix A.  Comparison with Related OAuth Mechanisms
             (Non-Normative) . . . . . . . . . . . . . . . . . . . . .  62
       A.1.  Token Exchange (RFC 8693) . . . . . . . . . . . . . . . .  62
       A.2.  Rich Authorization Requests (RFC 9396)  . . . . . . . . .  62
       A.3.  DPoP (RFC 9449) . . . . . . . . . . . . . . . . . . . . .  63
       A.4.  Biscuit . . . . . . . . . . . . . . . . . . . . . . . . .  64
     Appendix B.  Implementation Notes (Non-Normative) . . . . . . . .  64
       B.1.  Algorithm Recommendations . . . . . . . . . . . . . . . .  64
       B.2.  Performance . . . . . . . . . . . . . . . . . . . . . . .  65
       B.3.  Recognizing Derived Token iss Values in Middleware  . . .  65
       B.4.  Relationship to WIMSE . . . . . . . . . . . . . . . . . .  65
       B.5.  Delegation Depth Guidance . . . . . . . . . . . . . . . .  66
       B.6.  Implementation Size Limits  . . . . . . . . . . . . . . .  66
       B.7.  Signed Passthrough Metadata . . . . . . . . . . . . . . .  67
       B.8.  TTL Guidance  . . . . . . . . . . . . . . . . . . . . . .  68




  Niyikiza                Expires 17 September 2026               [Page 3]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     Appendix C.  Policy Languages with Decidable Containment
             (Non-Normative) . . . . . . . . . . . . . . . . . . . . .  68
     Appendix D.  CBOR/CWT Profile (Normative) . . . . . . . . . . . .  69
       D.1.  CWT Representation  . . . . . . . . . . . . . . . . . . .  70
       D.2.  Deterministic Encoding  . . . . . . . . . . . . . . . . .  70
       D.3.  Claim Key Assignments . . . . . . . . . . . . . . . . . .  70
       D.4.  Companion Document  . . . . . . . . . . . . . . . . . . .  71
     Appendix E.  Implementation Status (Non-Normative)  . . . . . . .  71
       E.1.  Reference Implementation  . . . . . . . . . . . . . . . .  71
       E.2.  Formal Verification . . . . . . . . . . . . . . . . . . .  71
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  71

  1.  Introduction

     AI agent systems increasingly delegate tasks to chains of autonomous
     agents, each invoking tools on behalf of a user or service.  Today,
     the tokens that authorize these invocations are typically scoped to
     the principal — the user or service account — not to the task the
     agent is performing.  Even when an OAuth scope narrows the token to a
     subset of APIs, it does not express which tools, with which argument
     values, a particular agent should use for a particular task.  The
     token that checks flight availability also authorizes completing a
     purchase and charging a corporate card.  A prompt injection attack, a
     model hallucination, or a compromised sub-agent can exploit this gap,
     exercising authority the agent should never have needed.  This is the
     confused deputy problem [HARDY88] applied to agentic delegation.

     This problem is compounded by a gap in existing infrastructure.  The
     WIMSE architecture [WIMSE-ARCH] provides mechanisms for establishing
     workload identity and propagating it across service boundaries.
     OAuth 2.0 [RFC6749] provides token issuance and scoping.  Neither
     provides a mechanism for a token holder to derive a narrower token
     and pass it downstream.  Without delegation-aware semantics, the only
     options are to trust every agent in the chain with the full token or
     to require each delegation step to contact the authorization server.
     The latter is impractical for agentic workflows that execute tool
     invocations in rapid succession, operate across trust boundaries, or
     run in environments with intermittent connectivity.

     Capability-based systems [DENNIS66] solve both problems.  Authority
     is carried by unforgeable tokens scoped to specific operations; a
     holder can attenuate a capability before passing it on, but cannot
     amplify it [SALTZER75].  This document defines such a mechanism for
     OAuth-based agent systems, complementing WIMSE's identity layer with
     a delegation and attenuation layer.

     The following diagram shows the delegation flow this specification
     enables:



  Niyikiza                Expires 17 September 2026               [Page 4]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     Root Issuer
            |
            | issues root AAT (Section 3.7)
            v
     Orchestrating Agent
            |
            | derives AAT (Section 6)
            v
     Planning Agent
            |
            | derives AAT (Section 6)
            v
     Tool-Invoking Agent
            |
            | presents AAT with PoP JWT (Section 5)
            v
     Enforcement Point
       (verifies chain offline, Section 7)

     At each derivation step, the derived token's scope is a subset of the
     parent's: scope can only narrow or stay the same, never widen.  The
     enforcement point verifies the complete chain using only the root
     token's trust anchor key; no network calls are required.  How token
     chains are carried to enforcement points is deployment-specific; this
     document does not define a transport binding.

  1.1.  Limitations of Existing OAuth Mechanisms for Agentic Delegation

     OAuth 2.0 Token Exchange [RFC8693] enables a principal to obtain a
     new token with reduced scope by contacting the authorization server.
     The server enforces the scope reduction.  This requires a synchronous
     round-trip to the authorization server at each delegation hop.  In
     multi-agent chains, this makes the authorization server a participant
     in every delegation decision, coupling the delegation topology to
     authorization server (AS) availability.  [RFC8693] supports
     representing prior delegation actors via nested act claims, but those
     claims are informational for access control decisions rather than a
     cryptographically self-verifiable attenuation chain.  The AS mediates
     each grant independently, and no mechanism ensures that downstream
     delegation intent remains consistent with the original authorization
     scope.

     Rich Authorization Requests (RAR) [RFC9396] extend OAuth tokens with
     structured authorization detail objects, enabling expressive
     capability descriptions.  RAR addresses the expressiveness problem.
     It does not define how a token holder can produce a narrower token,
     or how a chain of such derivations can be verified.




  Niyikiza                Expires 17 September 2026               [Page 5]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     Proposals to extend the authorization code flow with explicit agent
     consent, such as introducing a requested_actor parameter at the
     authorization endpoint, address who the agent is and whether the user
     approved the delegation.  They do not constrain which tools the agent
     may invoke or with what argument values.  AATs are complementary:
     they scope authority to specific tools and arguments after identity
     and consent have been established.

     To the author's knowledge, no existing OAuth standard defines a
     delegation chain protocol with a cryptographically enforced
     attenuation invariant and offline chain verification.

  1.2.  Design Goals

     1.  *Least privilege at the invocation boundary.* An agent's
         authorization token encodes which tools it may call and with what
         argument constraints, scoped to the task, not to the full
         authority of the calling principal.

     2.  *Offline derivation.* A token holder can derive a more
         restrictive token without contacting the root issuer.

     3.  *Independent chain verification.* Any enforcement point holding
         the trust anchor can verify the complete delegation chain without
         network calls.

     4.  *Cryptographically enforced attenuation.* A derived token cannot
         grant broader authority than its parent.

     5.  *JWT interoperability.* Tokens are representable as signed JWTs
         [RFC7519], allowing deployments to verify chains using existing
         JSON Object Signing and Encryption (JOSE) infrastructure without
         new cryptographic dependencies.

  1.3.  Relationship to Prior Work

     Macaroons [MACAROONS] introduced the concept of attenuating tokens
     with contextual caveats.  Macaroons use HMAC chaining, which provides
     attenuation but not proof of possession, and express caveats as free-
     form predicates evaluated at the target service at runtime.  This
     specification adds asymmetric proof of possession, structured tool-
     level capability claims, and a typed constraint vocabulary.  It
     defines a normative subsumption relation, enabling any party holding
     the chain to verify monotonicity structurally, without predicate
     evaluation at a central service.






  Niyikiza                Expires 17 September 2026               [Page 6]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     Biscuit [BISCUIT] extends the Macaroons model with asymmetric public
     key signatures and offline attenuation, addressing the proof-of-
     possession gap.  Biscuit expresses authorization policies in a
     Datalog variant, requiring a logic engine at verification time.  This
     specification uses structured constraint types decidable by
     structural analysis and defines a typed delegation-chain model with
     explicit token roles and chain-position claims.  A detailed
     comparison appears in Appendix A.

     The capability-based security model underlying AATs draws on
     [DENNIS66], which introduced capabilities as unforgeable tokens of
     authority, and [MILLER06], which formalized the principle of least
     authority (POLA) and the attenuation property in object-capability
     systems.  AATs apply these principles at the protocol layer: each
     token is a capability scoped to specific tools and arguments, and
     derivation can only attenuate, never amplify, the authority it
     carries.

     [DEEPMIND26] argues that safe multi-agent delegation requires
     explicit transfer of authority, responsibility, and trust at each
     delegation step, with bounded operational scope.  [CAMEL25] shows
     that capability-based controls enforced at the tool boundary can
     provide provable security properties in an agentic framework.  These
     results motivate a protocol-layer mechanism that encodes delegation
     scope in verifiable credential artifacts enforced independently of
     model behavior.  AATs realize one protocol-layer approach to that
     goal.

  2.  Terminology

     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 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

     *Attenuating Authorization Token (AAT):* A signed JWT as defined in
     this document.  An AAT encodes tool-level capability claims and
     supports offline derivation of derived tokens with authority equal to
     or narrower than the parent's.











  Niyikiza                Expires 17 September 2026               [Page 7]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     *Root Token:* An AAT with no parent token, del_depth: 0, and par_hash
     absent.  A root token may carry either aat_type: "delegation" or
     aat_type: "execution": a root issuer may mint an execution token
     directly when an agent requires immediate tool invocation authority
     without an intermediate delegation step.  A root token is signed by
     the private key corresponding to a trust anchor and establishes the
     authority ceiling for all derived tokens.  A root token is a
     positional role, not a distinct aat_type value: the two aat_type
     values are "delegation" and "execution".

     *Root Issuer:* The entity that mints root tokens.  The root issuer
     holds the private key corresponding to a trust anchor and is
     responsible for verifying agent identity and requested authority
     before issuance.

     *Token Holder:* The entity that possesses an AAT and the private key
     corresponding to its cnf.jwk claim.  The token holder is the party
     authorized to present the token, derive further tokens from it, or
     both, depending on the token's aat_type.

     *Derived Token:* An AAT produced by a token holder from a parent AAT,
     also referred to as a child token.  A derived token's authority is a
     subset of its parent's authority (equal or narrower).  Derivation
     does not require a round-trip to the root issuer.

     *Delegation Token:* An AAT that authorizes its holder to derive
     further tokens for a specified set of tools.  The name reflects what
     the holder is authorized to do, not who issued the token.  A
     delegation token does not authorize tool invocation.  A delegation
     token may itself be derived from a parent token; it is not
     necessarily produced by the root issuer.

     *Execution Token:* An AAT that authorizes its holder to invoke a
     specific set of tools subject to argument constraints.  An execution
     token holder may derive tokens with authority equal to or narrower
     than their own, subject to the depth limit of the chain.

     *Tool:* An addressable function or API operation that an agent may
     invoke.  A tool is identified by a string identifier.  Tool
     identifiers SHOULD be URIs ([RFC3986]); see Section 3.3.1 for
     requirements.  Tool identifiers MUST NOT contain characters that are
     subject to Unicode normalization (such as combining characters or
     characters with multiple canonical forms), as normalization-sensitive
     identifiers can produce inconsistent matching behavior across
     implementations.






  Niyikiza                Expires 17 September 2026               [Page 8]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     *Argument Constraint:* A predicate over a tool argument value that
     the argument MUST satisfy for the invocation to be authorized.
     Constraints are evaluated at the enforcement point before invocation.

     *Capability Claim:* The set of (tool, argument constraints) pairs
     encoded in an AAT's authorization_details claim.

     *Attenuation:* The process of deriving a token with a capability
     claim that is a subset of the parent token's capability claim.
     Attenuation is the only permitted direction of derivation.

     *Chain:* An ordered sequence of AATs from root to leaf, where each
     token was derived from its predecessor.

     *Leaf Token:* The last token in a chain.  The leaf token is the one
     presented to the enforcement point for authorization.  A leaf token
     MUST have aat_type: "execution".  The PoP JWT is signed by the
     private key corresponding to the leaf token's cnf.jwk.

     *Enforcement Point:* The component that receives a tool invocation
     request, verifies the presented token chain, evaluates argument
     constraints, and permits or denies execution.

     *Trust Anchor:* A public key that enforcement points are configured
     to trust as the root of a delegation chain.  Root tokens are signed
     by the private key corresponding to a trust anchor.

     *Proof of Possession (PoP):* A cryptographic demonstration that the
     presenter of a token controls the private key corresponding to the
     public key bound in the token's cnf claim.  In this specification,
     the token holder presents the chain and signs the PoP JWT using the
     same private key.

  3.  Token Types and Structure

  3.1.  Token Types

     This specification defines two token types, distinguished by the
     aat_type claim.

     *Delegation Tokens* (aat_type: "delegation") enumerate the tools for
     which the holder may derive further tokens; they do not authorize
     tool invocation.  A delegation token holder MUST NOT present a
     delegation token to an enforcement point to invoke a tool.  Root
     delegation tokens are typically issued by a root issuer to
     orchestrating agents, but delegation tokens may also appear at
     intermediate hops in a chain, derived from a parent delegation token
     with narrower scope.  A derived token from a delegation token MUST



  Niyikiza                Expires 17 September 2026               [Page 9]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     NOT authorize tools absent from the delegation token's
     authorization_details.  The capability monotonicity invariant (I4,
     Section 4.5) applies at every delegation step: derived tokens can
     only narrow the authorized tool set and argument constraints relative
     to the delegation token.

     *Execution Tokens* (aat_type: "execution") authorize tool invocation.
     They enumerate specific tools and the argument constraints that apply
     to each.  Execution tokens are presented to enforcement points at
     tool invocation boundaries.

     The separation between delegation and execution authority is a
     structural property of the token, not a policy decision left to
     enforcement points.  This moves the authorization boundary from
     something an enforcement point must judge to something any
     enforcement point can read directly from the chain, and enables type-
     transition key separation (Section 8.12) to be structurally enforced
     rather than left to convention.

     Any type transition is permitted, provided del_depth < del_max_depth
     in the parent token.  A holder of either token type may derive a
     token of either type, narrowing or maintaining the authorized tool
     set and argument constraints.  The capability monotonicity invariant
     (I4, Section 4.5) applies at every derivation step regardless of the
     type transition.

     A derived token whose aat_type differs from its parent's aat_type
     MUST have a cnf.jwk whose JWK Thumbprint ([RFC7638]) differs from the
     parent's cnf.jwk thumbprint.  This ensures structural separation
     between planning authority and invocation authority: an entity that
     delegates cannot use the same key to invoke, and an entity that
     invokes cannot use the same key to delegate.  When aat_type is
     preserved across a derivation step, same-key derivation is permitted.
     The security rationale for type-transition key separation is
     discussed in Section 8.12.

     A root issuer MAY issue an execution token directly, bypassing the
     delegation step, when an agent requires immediate tool invocation
     authority without intermediate planning authority.

  3.2.  Common Claims

     The following claims appear in both token types.  All claims listed
     as REQUIRED MUST be present.  Claims listed as OPTIONAL MAY be
     omitted; their absence carries the semantics described in the table.






  Niyikiza                Expires 17 September 2026              [Page 10]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     +=====================+===========+=========+==========================+
     |Claim                |Type       |Required |Description               |
     +=====================+===========+=========+==========================+
     |jti                  |string     |REQUIRED |Unique token identifier.  |
     |                     |           |         |SHOULD be a UUIDv7 value. |
     |                     |           |         |When a UUID is used, it   |
     |                     |           |         |MUST be encoded as a      |
     |                     |           |         |lowercase hyphenated      |
     |                     |           |         |string in the form        |
     |                     |           |         |xxxxxxxx-xxxx-xxxx-xxxx-  |
     |                     |           |         |xxxxxxxxxxxx per          |
     |                     |           |         |[RFC9562].                |
     +---------------------+-----------+---------+--------------------------+
     |iss                  |string     |REQUIRED |Identifier of the entity  |
     |                     |           |         |that signed this token.   |
     |                     |           |         |For root tokens, MUST be a|
     |                     |           |         |URI identifying the root  |
     |                     |           |         |issuer.  For derived      |
     |                     |           |         |tokens, MUST be a JWK     |
     |                     |           |         |Thumbprint URI as defined |
     |                     |           |         |in [RFC9278], using the   |
     |                     |           |         |SHA-256 hash algorithm:   |
     |                     |           |         |urn:ietf:params:oauth:jwk-|
     |                     |           |         |thumbprint:sha-           |
     |                     |           |         |256:<thumbprint>, where   |
     |                     |           |         |<thumbprint> is computed  |
     |                     |           |         |per [RFC7638].            |
     +---------------------+-----------+---------+--------------------------+
     |iat                  |NumericDate|REQUIRED |Time at which the token   |
     |                     |           |         |was issued.  MUST NOT be  |
     |                     |           |         |more than MAX_IAT_SKEW in |
     |                     |           |         |the future relative to the|
     |                     |           |         |enforcement point's clock |
     |                     |           |         |(see Section 4.4).  In a  |
     |                     |           |         |chain, a derived token's  |
     |                     |           |         |iat MUST NOT be earlier   |
     |                     |           |         |than its parent's iat.    |
     +---------------------+-----------+---------+--------------------------+
     |exp                  |NumericDate|REQUIRED |Time at which the token   |
     |                     |           |         |expires.  MUST be greater |
     |                     |           |         |than iat.  MUST NOT exceed|
     |                     |           |         |iat plus                  |
     |                     |           |         |MAX_TOKEN_LIFETIME (see   |
     |                     |           |         |Section 4.4).             |
     +---------------------+-----------+---------+--------------------------+
     |cnf                  |object     |REQUIRED |Confirmation claim        |
     |                     |           |         |[RFC7800].  MUST contain  |
     |                     |           |         |jwk with the holder's     |



  Niyikiza                Expires 17 September 2026              [Page 11]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     |                     |           |         |public key.  The jwk value|
     |                     |           |         |MUST be a public key;     |
     |                     |           |         |private key material MUST |
     |                     |           |         |NOT appear in this field. |
     +---------------------+-----------+---------+--------------------------+
     |aat_type             |string     |REQUIRED |Token type.  MUST be      |
     |                     |           |         |"delegation" or           |
     |                     |           |         |"execution".              |
     +---------------------+-----------+---------+--------------------------+
     |del_depth            |integer    |REQUIRED |Delegation depth. 0 for   |
     |                     |           |         |root tokens.  Incremented |
     |                     |           |         |by exactly 1 at each      |
     |                     |           |         |derivation step (see      |
     |                     |           |         |Section 4.3).             |
     +---------------------+-----------+---------+--------------------------+
     |del_max_depth        |integer    |REQUIRED |Maximum delegation depth  |
     |                     |           |         |permitted in this chain.  |
     |                     |           |         |MUST be a non-negative    |
     |                     |           |         |integer not exceeding the |
     |                     |           |         |implementation's          |
     |                     |           |         |MAX_DELEGATION_DEPTH      |
     |                     |           |         |(Section 4.3).            |
     +---------------------+-----------+---------+--------------------------+
     |par_hash             |string     |MUST     |Base64url-encoded SHA-256 |
     |                     |           |(derived)|digest of the parent      |
     |                     |           |/ MUST   |token's JWS Signing Input,|
     |                     |           |NOT      |using base64url encoding  |
     |                     |           |(root)   |without padding as defined|
     |                     |           |         |in [RFC7515] Appendix C.  |
     |                     |           |         |MUST be absent in root    |
     |                     |           |         |tokens.  MUST be present  |
     |                     |           |         |in all derived tokens.    |
     +---------------------+-----------+---------+--------------------------+
     |authorization_details|array      |REQUIRED |Tool capability claims.   |
     |                     |           |         |Format defined in         |
     |                     |           |         |Section 3.3.              |
     +---------------------+-----------+---------+--------------------------+

                                    Table 1

     Implementations MUST support Ed25519 [RFC8032] for token signing and
     verification.  Implementations MAY support additional algorithms.









  Niyikiza                Expires 17 September 2026              [Page 12]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     In both root and derived tokens, iss is a URI.  For root tokens, iss
     is a URI identifying the root issuer, consistent with conventional
     OAuth usage.  For derived tokens, iss is a JWK Thumbprint URI
     [RFC9278] that encodes the SHA-256 thumbprint of the signing key.
     This makes I1 verifiable offline: the enforcement point can confirm
     that the thumbprint embedded in derived.iss matches parent.cnf.jwk
     without any external lookup.

     This specification intentionally omits the sub claim.  In
     conventional OAuth tokens, sub identifies the resource owner or
     principal on whose behalf the token is issued.  In an AAT chain, the
     holder's identity is fully determined by cnf.jwk: the entity
     presenting the token proves possession of the private key
     corresponding to cnf.jwk.  Including a sub claim would introduce an
     additional identity binding that is not cryptographically enforced by
     this specification and could be set arbitrarily by any delegating
     party.  Implementations that require a human-readable subject
     identifier MAY convey one in additional JWT claims outside this
     specification (see Appendix B.7).

  3.3.  Capability Claims via authorization_details

     This specification profiles [RFC9396] for tool-level capability
     claims.  Each entry in the authorization_details array MUST have type
     set to "attenuating_agent_token".  The entry MUST include a tools
     member that maps tool names to argument constraint sets.

     {
       "authorization_details": [
         {
           "type": "attenuating_agent_token",
           "tools": {
             "read_file": {
               "path": {
                 "constraint_type": "pattern", "value": "/data/*"
               }
             },
             "search_index": {
               "query": {
                 "constraint_type": "pattern", "value": "*public*"
               },
               "limit": { "constraint_type": "range", "max": 100 }
             }
           }
         }
       ]
     }




  Niyikiza                Expires 17 September 2026              [Page 13]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     A tool entry with an empty constraint map {} is valid and indicates
     that the tool is authorized without argument restrictions.

     When a tool entry contains one or more argument constraints, the
     enforcement point operates in closed-world mode for that tool
     invocation: any argument not named in the constraint map MUST be
     rejected.  A constrained argument that is absent from the invocation
     MUST also be rejected.  The presence of a constraint asserts that the
     issuer has reasoned about that argument.  An invocation that omits it
     has not been validated against that reasoning.  This is a security
     property, not a configuration option.

     Issuers who wish to permit an argument to be omitted MUST NOT include
     a constraint for it in the constraint map.  There is no "optional
     constraint" mechanism; the constraint map is a closed specification
     of the required invocation shape.  To authorize an argument without
     restricting its value, use a wildcard constraint (see below).

     A token issuer that wishes to allow unconstrained arguments alongside
     constrained ones MUST explicitly include a wildcard constraint for
     each argument that should be unrestricted.  A wildcard constraint
     satisfies closed-world mode while permitting any value for that
     argument (see Section 3.4).  Enforcement points MUST enforce closed-
     world mode and MUST NOT permit unconstrained arguments when any
     constraint is present for the tool (see Section 7, step 6b).

     The authorization_details array MAY contain entries of other types
     alongside attenuating_agent_token entries, consistent with the
     extensibility model of [RFC9396].  Enforcement points implementing
     this specification process only entries with type set to
     attenuating_agent_token and MUST ignore entries of other types.  An
     authorization_details array containing multiple entries with type:
     "attenuating_agent_token" is invalid; the tools map in a single entry
     provides sufficient structure for all tool-level capability claims.

  3.3.1.  Tool Identifier Requirements

     Tool identifiers are the keys of the tools map in an
     authorization_details entry.  The following requirements apply.

     Tool identifiers MUST be unique within the tools map of a single
     token.  An authorization_details entry containing duplicate tool
     identifier keys is malformed and MUST be rejected.

     Tool identifiers SHOULD be URIs ([RFC3986]).  URI-format identifiers
     provide namespace isolation across agents and prevent semantic
     collision when multiple agents in a deployment expose tools with
     identical local names.



  Niyikiza                Expires 17 September 2026              [Page 14]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     When URI-format identifiers are used, the URI SHOULD be scoped to the
     authority of the agent that exposes the tool.  The authority
     component SHOULD correspond to the agent's workload identity or a
     domain controlled by the agent's operator.  The URI SHOULD include a
     version component or content hash to ensure that all parties in the
     chain reason about the same tool schema.  For example:

     https://billing-agent.example.com/tools/charge/v2

     Tool identifiers that are not URIs MAY be used in single-agent
     deployments where namespace collision is not a concern.  Deployments
     spanning multiple agents or trust domains SHOULD use URI-format
     identifiers.

     A tool identifier carries no inherent authorization semantics beyond
     naming a capability.  The root issuer is responsible for verifying
     that the tool identifier is meaningful and that the requesting agent
     is authorized to claim identifiers under the tool URI's authority
     component before minting a root token (Section 3.7.3).

  3.4.  Argument Constraints

     Each argument constraint is an object with a constraint_type member
     and type-specific members.  The following constraint types are
     defined normatively.  The check predicate and subsumes relation for
     each type are normative: two independent implementations MUST produce
     identical results when evaluating either predicate against the same
     inputs.

     For constraint types where this specification does not define a
     general containment algorithm (specifically pattern, regex, cel, not,
     and any), this specification prescribes a conservative syntactic
     strategy.  The strategy is sound: it never incorrectly accepts a non-
     subsuming constraint.  It is conservative: it may reject constraints
     that are semantically subsuming but cannot be proven so
     syntactically.  Deployments requiring richer policy expressiveness
     with full subsumption support SHOULD use a registered extension
     constraint type built on a language with a decidable containment
     algorithm (see Section 3.5 and Appendix C).

     +=================+=====================+===========================+
     | constraint_type | Additional Members  | Semantics                 |
     +=================+=====================+===========================+
     | exact           | value (any scalar)  | Argument MUST equal       |
     |                 |                     | value exactly.            |
     +-----------------+---------------------+---------------------------+
     | pattern         | value (string)      | Argument MUST match the   |
     |                 |                     | glob pattern.  See        |



  Niyikiza                Expires 17 September 2026              [Page 15]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     |                 |                     | below for syntax.         |
     +-----------------+---------------------+---------------------------+
     | range           | min (number,        | Argument MUST be a        |
     |                 | optional), max      | number satisfying the     |
     |                 | (number, optional), | specified bounds.  Both   |
     |                 | min_inclusive       | bounds are optional.      |
     |                 | (boolean, optional, | min_inclusive and         |
     |                 | default true),      | max_inclusive control     |
     |                 | max_inclusive       | whether the respective    |
     |                 | (boolean, optional, | bound is included in      |
     |                 | default true)       | the valid range; both     |
     |                 |                     | default to true (closed   |
     |                 |                     | interval).                |
     +-----------------+---------------------+---------------------------+
     | one_of          | values (array)      | Argument MUST be a        |
     |                 |                     | member of values.         |
     +-----------------+---------------------+---------------------------+
     | not_one_of      | excluded (array)    | Argument MUST NOT be a    |
     |                 |                     | member of excluded.       |
     +-----------------+---------------------+---------------------------+
     | contains        | required (array)    | Argument, which MUST be   |
     |                 |                     | an array, MUST contain    |
     |                 |                     | every element listed in   |
     |                 |                     | required.                 |
     +-----------------+---------------------+---------------------------+
     | subset          | allowed (array)     | Argument, which MUST be   |
     |                 |                     | an array, MUST be a       |
     |                 |                     | subset of allowed.        |
     +-----------------+---------------------+---------------------------+
     | regex           | pattern (string)    | Argument MUST match the   |
     |                 |                     | regular expression.       |
     |                 |                     | See below for dialect     |
     |                 |                     | and subsumption notes.    |
     +-----------------+---------------------+---------------------------+
     | cel             | expression (string) | Argument MUST satisfy     |
     |                 |                     | the Common Expression     |
     |                 |                     | Language (CEL)            |
     |                 |                     | expression, which MUST    |
     |                 |                     | return a boolean.  See    |
     |                 |                     | below for subsumption     |
     |                 |                     | rules.                    |
     +-----------------+---------------------+---------------------------+
     | wildcard        | (none)              | Any value is accepted.    |
     +-----------------+---------------------+---------------------------+
     | all             | constraints (array) | Logical AND of nested     |
     |                 |                     | constraints.  See         |
     |                 |                     | Section 4.5 for           |
     |                 |                     | subsumption rules.        |



  Niyikiza                Expires 17 September 2026              [Page 16]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     +-----------------+---------------------+---------------------------+
     | any             | constraints (array) | Logical OR of nested      |
     |                 |                     | constraints.  See         |
     |                 |                     | Section 4.5 for           |
     |                 |                     | subsumption rules.        |
     +-----------------+---------------------+---------------------------+
     | not             | constraint (object) | Logical negation of a     |
     |                 |                     | nested constraint.  See   |
     |                 |                     | Section 4.5 for           |
     |                 |                     | subsumption rules.        |
     +-----------------+---------------------+---------------------------+

                                    Table 2

     *Pattern glob syntax.* The pattern constraint uses the following glob
     syntax. * matches any sequence of characters not containing a path
     separator. ? matches any single character. [abc] matches any single
     character in the set. [!abc] matches any single character not in the
     set.  The token ** (double-star) has no defined semantics in this
     specification and MUST NOT appear in pattern values.  Brace
     alternation (e.g., {a,b}) has no defined semantics in this
     specification and MUST NOT appear in pattern values; deployments
     requiring alternation SHOULD use any with multiple pattern
     constraints.  See Section 4.5 for subsumption rules.

     *Regex dialect and subsumption.* The regex constraint does not
     standardize a dialect; implementations MUST document the dialect they
     support.  This specification does not define a portable containment
     algorithm for regular expressions; equality of pattern strings is the
     normative conservative subsumption strategy.  See Section 4.5.

     *CEL check predicate.* The cel expression MUST evaluate to a boolean.
     The subsumption strategy for cel uses balanced-parentheses
     conjunction; see Section 4.5 for the normative rules and Section 8.13
     for the security rationale.

     Enforcement points MUST reject invocations where any argument
     violates its associated constraint.  Enforcement points MUST deny
     authorization if they encounter a constraint_type they do not
     recognize (fail-closed behavior).  This fail-closed rule applies only
     to constraint types within authorization_details.  Enforcement points
     MUST ignore unrecognized top-level JWT claims; a token MUST NOT be
     rejected solely because it contains claims outside those defined in
     this specification.

     Composite constraint types (all, any, not) are recursive.
     MAX_CONSTRAINT_DEPTH is an implementation-defined finite integer
     specifying the maximum nesting depth of a constraint tree.



  Niyikiza                Expires 17 September 2026              [Page 17]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     Implementations MUST enforce a finite MAX_CONSTRAINT_DEPTH to prevent
     resource exhaustion from pathologically deep constraint trees.  A
     value of 32 is RECOMMENDED.  Enforcement points MUST reject any
     constraint tree whose nesting depth exceeds MAX_CONSTRAINT_DEPTH.

     Domain-specific constraint types such as path containment, URL
     safety, or IP range matching may be registered in the extension
     registry (Section 3.5).

  3.5.  Extension Constraint Registry

     Implementations MAY define extension constraint types beyond those
     listed in Section 3.4.  Extension constraint types MUST be registered
     in the IANA AAT Constraint Type Registry defined in Section 9.3.  The
     registry exists to preserve security and interoperability in the
     presence of domain-specific constraints; it is not a requirement that
     all implementations support arbitrary extensions.  An enforcement
     point that does not recognize a registered extension type MUST deny
     authorization (Section 3.5.2), but it is not required to implement
     that type.

  3.5.1.  Attenuation Compliance Requirement

     The capability monotonicity invariant (I4, Section 4.5) applies to
     extension constraint types without exception.  An extension
     constraint type MUST NOT be registered unless its registration
     defines all of the following.

     *A subsumption verification procedure.* The registration MUST provide
     a complete, formal definition of what it means for one instance of
     the constraint to be at least as restrictive as another instance of
     the same constraint type.  This procedure MUST satisfy three
     properties:

     1.  *Decidable.* The procedure MUST terminate in finite time for all
         inputs.  It MUST NOT require solving problems that are
         undecidable or computationally intractable in the general case.
         If the constraint language used by the type is not closed under
         decidable containment analysis, the registration MUST prescribe a
         conservative syntactic strategy and MUST formally justify that
         the strategy is sound (never accepts a non-subsuming pair).










  Niyikiza                Expires 17 September 2026              [Page 18]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     2.  *Sound.* The procedure MUST NOT return true unless the semantic
         subsumption relation holds.  That is, if the procedure returns
         true for (C_parent, C_child), then for all argument values v:
         C_child.check(v) implies C_parent.check(v).  The procedure MAY be
         conservative: it MAY return false for semantically subsuming
         pairs that it cannot verify, but it MUST NOT return true for non-
         subsuming pairs.

     3.  *Deterministic.* Two independent implementations of the procedure
         MUST produce identical results for the same inputs.  The
         procedure MUST be specified precisely enough to ensure this.
         Ambiguity in the specification of the procedure is grounds for
         rejection of the registration.

     This specification does not prescribe the internal mechanism of the
     subsumption verification procedure.  Registrations MAY use structural
     comparison of token claims, formal type-checking, proof-carrying
     tokens, or any other mechanism that satisfies the three properties
     above.  See Appendix C for non-normative guidance on policy languages
     with decidable containment algorithms.

     *Cross-type subsumption rules.* For each core constraint type defined
     in Section 3.4, the registration MUST specify whether a derived token
     may substitute an extension type instance for a parent constraint of
     that core type (or vice versa).  If substitution is permitted, the
     registration MUST state the conditions.  Any (parent type, child
     type) pair not explicitly declared valid MUST be treated as invalid
     by enforcement points.

  3.5.2.  Enforcement Point Obligations

     When an enforcement point encounters an extension constraint type
     during chain verification, it MUST:

     1.  Locate the registered subsumption verification procedure for that
         type.  If no registration exists, the enforcement point MUST
         reject the chain (fail-closed).

     2.  Evaluate the subsumption relation at every chain link where the
         constraint appears, as part of the I4 check.  A chain link where
         the derived constraint does not subsume the parent constraint
         MUST be rejected.

     3.  Evaluate the constraint's check predicate against the presented
         argument value during authorization.  If the predicate returns
         false, the invocation MUST be denied.





  Niyikiza                Expires 17 September 2026              [Page 19]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     An enforcement point that does not implement a registered extension
     constraint type MUST deny authorization rather than skip the
     constraint.  The presence of an unrecognized constraint type in a
     token represents a restriction the issuer intended to enforce.
     Silently omitting that check would violate the attenuation guarantee.

  3.5.3.  Example Registration: Path Containment

     The following is an illustrative example of a conforming extension
     constraint registration.  It is not defined normatively in this
     document.

     *Type name:* path_containment

     *Additional members:* root (string, required).  An absolute path
     prefix.

     *check predicate:* The argument, after resolving all . and ..
     components and removing redundant separators, must begin with root.
     The normalization step is part of the predicate; implementations that
     compare raw argument strings without normalization do not conform to
     this registration.

     *subsumes relation:* subsumes(C_parent, C_child) is true if and only
     if C_child.root is C_parent.root or a descendant of C_parent.root
     under the normalized path ordering.

     *Cross-type subsumption:* A derived exact constraint subsumes a
     parent path_containment constraint if and only if the exact value,
     after normalization, begins with the parent's root.  All other cross-
     type pairs involving path_containment are invalid.

     The following additional examples illustrate conforming extension
     registrations for network-oriented constraint types.  Neither is
     defined normatively in this document.

     *Type name:* cidr

     *Additional members:* network (string, required).  An IPv4 or IPv6
     network in CIDR notation.

     *check predicate:* The argument must be a valid IPv4 or IPv6 address
     string that falls within network after normalization of IPv6-mapped
     IPv4 addresses, octal notation, and URL-encoded hostnames.
     Implementations must normalize address representations before
     comparison to prevent encoding bypasses.





  Niyikiza                Expires 17 September 2026              [Page 20]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     *subsumes relation:* subsumes(C_parent, C_child) is true if and only
     if C_child.network is a subnet of C_parent.network.

     *Cross-type subsumption:* A derived exact constraint subsumes a
     parent cidr constraint if and only if the exact value, after
     normalization, is an address within the parent's network.  All other
     cross-type pairs involving cidr are invalid.

     *Type name:* url_safe

     *Additional members:* allow_schemes (array of strings, optional,
     default ["http", "https"]); allow_domains (array of strings,
     optional); deny_domains (array of strings, optional); block_private
     (boolean, optional, default true); block_loopback (boolean, optional,
     default true); block_metadata (boolean, optional, default true).

     *check predicate:* The argument must be a URL whose scheme appears in
     allow_schemes.  If block_private, block_loopback, or block_metadata
     are true, the resolved host must not be a private, loopback, or cloud
     metadata address respectively, after normalization of all known IP
     encoding forms (decimal, hex, octal, IPv6-mapped, URL-encoded).  If
     allow_domains is non-empty, the host must match at least one entry.
     If deny_domains is non-empty, the host must not match any entry.
     deny_domains takes precedence over allow_domains on overlap.

     *subsumes relation:* subsumes(C_parent, C_child) is true if and only
     if C_child is at least as restrictive as C_parent on every field:
     allow_schemes is a subset of parent's; block_private, block_loopback,
     and block_metadata are each equal to or more restrictive than the
     parent's corresponding flag; allow_domains is a subset of parent's
     (or parent has none); deny_domains is a superset of parent's.

     *Cross-type subsumption:* A derived exact constraint subsumes a
     parent url_safe constraint if and only if the exact value passes the
     parent's check predicate.  All other cross-type pairs involving
     url_safe are invalid.

  3.6.  Examples

  3.6.1.  Root Delegation Token











  Niyikiza                Expires 17 September 2026              [Page 21]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     {
       "jti": "01957a3f-4e23-7b01-a9d1-0050569c2e4f",
       "iss": "https://auth.example.com",
       "iat": 1741600000,
       "exp": 1741603600,
       "aat_type": "delegation",
       "del_depth": 0,
       "del_max_depth": 3,
       "cnf": {
         "jwk": {
           "kty": "OKP",
           "crv": "Ed25519",
           "x": "11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo"
         }
       },
       "authorization_details": [
         {
           "type": "attenuating_agent_token",
           "tools": {
             "read_file": {
               "path": {
                 "constraint_type": "pattern", "value": "/data/*"
               }
             },
             "search_index": {}
           }
         }
       ]
     }

  3.6.2.  Derived Execution Token




















  Niyikiza                Expires 17 September 2026              [Page 22]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     {
       "jti": "01957a41-0081-7c20-bf3a-00a0c91e1234",
       "iss": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:KAKnRDlMQVIKCfS5JhHlABCHjAFLdyEVVHdpnGnLLg8",
       "iat": 1741600120,
       "exp": 1741601920,
       "aat_type": "execution",
       "del_depth": 1,
       "del_max_depth": 3,
       "par_hash": "sha256_base64url_of_parent_jws_signing_input",
       "cnf": {
         "jwk": {
           "kty": "OKP",
           "crv": "Ed25519",
           "x": "rAl9xvTDAeUADPnIWlGpFHtGg4Y8OqcQE5N4XYNdLPs"
         }
       },
       "authorization_details": [
         {
           "type": "attenuating_agent_token",
           "tools": {
             "read_file": {
               "path": {
                 "constraint_type": "exact",
                 "value": "/data/q3-report.pdf"
               }
             }
           }
         }
       ]
     }

     Note that the derived token:

     *  Carries a par_hash linking it to its parent.

     *  Has del_depth incremented to 1.

     *  Restricts read_file to a single file rather than the full /data
        subtree.

     *  Omits search_index, which the parent permitted.  Tool omission is
        valid attenuation.

     *  Expires 1800s after its own issuance, versus the parent's 3600s
        window.

  3.7.  Root Issuer Support and Root Token Issuance




  Niyikiza                Expires 17 September 2026              [Page 23]


  Internet-Draft          Attenuating Agent Tokens              March 2026


  3.7.1.  Root Issuer Discovery

     A root issuer that supports AAT issuance SHOULD advertise this
     capability using the following metadata parameter in its
     authorization server metadata document [RFC8414], if supported.

              +====================+============================+
              | Metadata Parameter | Value                      |
              +====================+============================+
              | aat_issuer         | Boolean. true if the AS    |
              |                    | can issue AAT root tokens. |
              +--------------------+----------------------------+

                                    Table 3

     This document requests registration of aat_issuer in the IANA OAuth
     Authorization Server Metadata registry (Section 9.4).

  3.7.2.  Agent Token Request

     An agent requesting a root AAT MUST include a cnf parameter in its
     token endpoint request (in the OAuth 2.0 sense, the agent acts as the
     client for this request).  This specification treats cnf as a
     profiled use of the key confirmation object structure defined in
     [RFC7800] Section 3.1; its semantics are fully specified by that
     document.  This document requests registration of cnf as an OAuth
     token endpoint request parameter (Section 9.6).  The value MUST be a
     JSON object containing a jwk member with the agent's public key in
     JWK format [RFC7517].  This is the key that the root issuer will bind
     into the root token's cnf.jwk claim.

     POST /token HTTP/1.1
     Host: as.example.com
     Content-Type: application/x-www-form-urlencoded

     grant_type=client_credentials
     &authorization_details=%5B%7B%22type%22%3A%22attenuating_agent_
       token%22%2C...%7D%5D
     &cnf=%7B%22jwk%22%3A%7B%22kty%22%3A%22OKP%22%2C...%7D%7D

     The request MUST also include authorization_details in RAR format
     [RFC9396] with type set to attenuating_agent_token, enumerating the
     tools and argument constraints the agent is requesting authority to
     invoke or delegate.







  Niyikiza                Expires 17 September 2026              [Page 24]


  Internet-Draft          Attenuating Agent Tokens              March 2026


  3.7.3.  Root Token Issuance

     Upon a valid request, the AS constructs and returns a root AAT.  The
     AS:

     1.  Sets iss to the AS's own URI.

     2.  Sets jti to a unique token identifier, RECOMMENDED to be a UUIDv7
         value per [RFC9562].

     3.  Sets iat to the current time and exp to the token's expiry time,
         subject to the constraints in Section 4.4.

     4.  Sets aat_type to "delegation" or "execution" as appropriate for
         the grant.

     5.  Sets del_depth to 0, del_max_depth to the maximum delegation
         depth permitted for this grant, and par_hash to absent.

     6.  Sets cnf.jwk to the public key submitted in the agent's cnf
         request parameter.  The root issuer MUST validate that the
         submitted key is well-formed and is a public key.  The root
         issuer SHOULD require the agent to demonstrate possession of the
         corresponding private key, for example via a signed proof-of-
         possession assertion in the token request.

     7.  Sets authorization_details to the capability claims granted,
         which MAY be a subset of what the agent requested.

     8.  For each URI-format tool identifier in the requested
         authorization_details, the root issuer SHOULD verify that the
         requesting agent's identity, as established by the agent's client
         authentication credentials, corresponds to the authority
         component of each claimed tool URI.  If this verification fails,
         the root issuer MUST reject the request.  The mechanism by which
         agent identity is mapped to tool URI authority is deployment-
         specific and outside the scope of this specification.

     9.  Signs the token with the AS's own private key.

     The AS returns the token in a standard OAuth 2.0 token endpoint
     response ([RFC6749] Section 5.1) with the following field values:

     {
       "access_token": "<compact-serialized AAT JWT>",
       "token_type": "aat",
       "expires_in": <seconds until exp>
     }



  Niyikiza                Expires 17 September 2026              [Page 25]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     The token_type value "aat" is registered in Section 9.5.  Clients
     MUST NOT treat the returned token as a bearer token for use with
     arbitrary resource servers.  Its only valid use is as the root of an
     AAT delegation chain presented to an enforcement point per Section 7.

     Note: this specification defines token endpoint issuance for
     interoperability with existing OAuth 2.0 deployments.  Unlike bearer
     tokens, an AAT carries its own holder key binding and is not usable
     as a credential for HTTP resource access.  Alternative issuance
     profiles are outside the scope of this document.

     The AS does not need to store or track derived tokens issued
     downstream by the initial token holder.  Chain verification is
     performed by enforcement points using only the root token's public
     key as a trust anchor.

  4.  Attenuation Invariants

     Every derived token in a chain MUST satisfy all of the following
     invariants.  The verification algorithm in Section 7 enforces these
     invariants; enforcement points MUST reject any chain that violates
     any invariant.

  4.1.  Capability Lattice Model (Non-Normative)

     The attenuation invariants in this section are instances of a single
     abstract structure: a capability lattice.  This subsection states
     that structure informally to give readers a mental model for
     interpreting the normative rules that follow.

     For a token T, define its capability set C(T) as the set of (tool,
     args) pairs that T authorizes (that is, the pairs for which T would
     permit invocation).  The core security property of this protocol is:

     C(child) ⊆ C(parent)

     Every delegation step moves down or stays at the same position in
     this partial order.  A derived token can only authorize a subset of
     what its parent authorized.  It cannot add tools, loosen argument
     constraints, or extend the chain's authority in any dimension.

     The ⊆ relation is not defined by enumerating (tool, args) pairs
     (argument spaces are typically infinite) but by the structural
     subsumption rules in Section 4.5.  At the tool level, the derived
     token's tool set must be a subset of the parent's.  At the argument
     level, when the parent's constraint map is non-empty, the derived
     token must preserve the parent's key set exactly (Section 4.5
     explains why closed-world semantics require this).



  Niyikiza                Expires 17 September 2026              [Page 26]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     When the parent's map is empty, the derived token may introduce keys,
     transitioning from open-world to closed-world.  Each per-key
     constraint must be at least as restrictive.  A derived constraint
     c_child subsumes a parent constraint c_parent (written c_child ⊑
     c_parent) if every argument value that satisfies c_child also
     satisfies c_parent.

     Two boundary cases complete the structure.  The empty capability set
     ∅ is the bottom element: a token with no tools authorized is a valid
     but useless terminal token.  The root token's capability set is the
     ceiling for the entire chain: no derived token at any depth can
     exceed what the root authorized.

     Token lifetime (I3) is a mandatory attenuation dimension orthogonal
     to the capability lattice.  A derived token with C(child) ==
     C(parent) is still strictly more constrained if its exp is earlier
     than its parent's.  Time-to-live (TTL) bounds are enforced
     independently of capability monotonicity.  Both must hold for a chain
     to be valid.

     Invariants I1 through I6 are the normative enforcement mechanism for
     this property.  I4 (Section 4.5) directly enforces C(child) ⊆
     C(parent).  The remaining invariants enforce the conditions under
     which that comparison is meaningful: that the chain is
     cryptographically linked (I1, I5), that depth and time bounds are
     respected (I2, I3), and that the presenter holds the key (I6).

  4.2.  I1: Delegation Authority

     derived.iss == jwk_thumbprint_uri(parent.cnf.jwk)

     where jwk_thumbprint_uri constructs the [RFC9278] URI from the key's
     SHA-256 thumbprint.  The entity that signed the derived token MUST be
     the holder of the parent token.  Authority flows from parent holder
     to derived token issuer.  This invariant establishes an unambiguous
     audit trail: each link in the chain was signed by the party that held
     the preceding token.

  4.3.  I2: Depth Monotonicity

     derived.del_depth == parent.del_depth + 1
     derived.del_depth <= parent.del_max_depth
     derived.del_depth <= derived.del_max_depth
     derived.del_depth <= MAX_DELEGATION_DEPTH
     derived.del_max_depth <= parent.del_max_depth






  Niyikiza                Expires 17 September 2026              [Page 27]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     Delegation depth increments exactly by one at each link.  The chain
     cannot skip depths, branch, or exceed the maximum depth established
     in the root token. del_max_depth is an absolute ceiling, not a
     remaining count.  A token is terminal (its holder cannot derive
     further tokens) when del_depth == del_max_depth.  A root token with
     del_max_depth: 0 is therefore immediately terminal and cannot produce
     any derived tokens.

     The del_max_depth claim serves two related purposes.  First, it is a
     security boundary: each delegation hop is a trust extension,
     delegating authority through another agent whose key, runtime, and
     behavior must be trusted to maintain the attenuation invariant.
     Unbounded chains mean unbounded trust extensions; the depth limit
     constrains how far authority can propagate before it must be reissued
     from the root.  Second, it is a policy expression by the root issuer:
     a root delegation token with del_max_depth: 2 asserts that this grant
     of authority should pass through no more than two intermediate
     agents, regardless of what those agents might prefer.  Intermediate
     token holders can only lower del_max_depth, never raise it (I2), so
     the root issuer's topology constraint is cryptographically enforced
     across the entire chain.

     MAX_DELEGATION_DEPTH is an implementation-defined finite integer
     specifying the maximum permitted delegation chain depth.
     Implementations MUST enforce a finite maximum delegation depth to
     prevent resource exhaustion from pathologically deep chains.  The
     appropriate value depends on the deployment topology; swarm
     architectures with deep fan-out may require significantly larger
     values than linear delegation chains.  See Appendix B.5 for guidance.

     The del_max_depth claim in any token in the chain MUST NOT exceed the
     implementation's MAX_DELEGATION_DEPTH.

  4.3.1.  Implementation Resource Limits

     MAX_TOKEN_SIZE is an implementation-defined finite integer specifying
     the maximum encoded size of a single token in bytes.  Implementations
     MUST enforce this limit to prevent memory exhaustion from
     pathologically large tokens.  A value of 65536 bytes (64 KiB) is
     RECOMMENDED.

     MAX_STACK_SIZE is an implementation-defined finite integer specifying
     the maximum total encoded size of a chain in bytes.  Implementations
     MUST enforce this limit.  A value of 262144 bytes (256 KiB) is
     RECOMMENDED.

  4.4.  I3: TTL Monotonicity




  Niyikiza                Expires 17 September 2026              [Page 28]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     derived.exp  <= parent.exp
     derived.exp  >  now
     derived.exp  >  derived.iat
     derived.iat  >= parent.iat
     derived.iat  <= now + MAX_IAT_SKEW
     derived.exp  <= derived.iat + MAX_TOKEN_LIFETIME

     MAX_IAT_SKEW is an implementation-defined finite integer specifying
     the maximum number of seconds a token's iat may be in the future
     relative to the enforcement point's clock.  Implementations MUST
     enforce a finite MAX_IAT_SKEW.  A value of 30 seconds is RECOMMENDED.

     MAX_TOKEN_LIFETIME is an implementation-defined finite integer
     specifying the maximum permitted duration in seconds between a
     token's iat and exp.  Implementations MUST enforce a finite
     MAX_TOKEN_LIFETIME.  A value of 90 days is RECOMMENDED as an upper
     bound; deployments SHOULD use significantly shorter lifetimes in
     practice (see Appendix B.8).

     A derived token cannot outlive its parent.  Authority cannot extend
     beyond the lifetime of the token that granted it.  A derived token's
     issuance time MUST NOT precede its parent's issuance time.  A token
     with an earlier iat indicates clock manipulation or chain forgery.
     Tokens with iat more than MAX_IAT_SKEW in the future relative to the
     enforcement point's clock MUST be rejected.  A token's lifetime MUST
     NOT exceed MAX_TOKEN_LIFETIME.

  4.5.  I4: Capability Monotonicity

     tools(derived) ⊆ tools(parent)
     ∀ tool ∈ tools(derived):
       constraints(derived, tool) ⊑ constraints(parent, tool)

     A derived token MUST NOT authorize tools that the parent did not
     authorize.  For each tool that appears in both parent and derived
     token:

     *  If the parent's constraint map for that tool is non-empty, the
        derived token's constraint map MUST contain exactly the same set
        of argument keys.  Under closed-world semantics (Section 3.3), the
        constraint map keys define the required invocation shape: any
        argument not named is forbidden, and any named argument must be
        present.  Adding a key would produce invocations that the parent's
        closed-world check rejects (the extra argument is unknown).
        Dropping a key would produce invocations that omit a parent-
        required argument.  In both cases the derived invocation set is
        disjoint from the parent's, not a subset.




  Niyikiza                Expires 17 September 2026              [Page 29]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     *  If the parent's constraint map is empty (open-world), the derived
        token MAY introduce constraint keys, transitioning to closed-
        world.  Any closed-world constraint set is a subset of the
        unrestricted open-world set.

     For each argument constraint key present in both parent and derived
     token, the derived constraint MUST be at least as restrictive as the
     parent's constraint.

     Constraint subsumption is defined per constraint type.  The normative
     rules are:

     *  *exact:* A derived exact constraint subsumes a parent constraint
        of the same or different type as follows: it subsumes a parent
        exact if the values are identical; it subsumes a parent pattern if
        the exact value matches the parent pattern; it subsumes a parent
        range if the exact value falls within the parent range; it
        subsumes a parent one_of if the exact value is a member of the
        parent set; it subsumes a parent regex if the exact value matches
        the parent regex pattern; it subsumes a parent wildcard
        unconditionally.  All other parent types are invalid cross-type
        targets for a derived exact constraint.

     *  *pattern:* This specification does not define a general
        containment algorithm for glob patterns; therefore it uses a
        conservative syntactic strategy.  Enforcement points MUST apply
        the following rules, in order:

        1.  A derived exact constraint subsumes a parent pattern if the
            exact value matches the parent pattern.

        2.  If the parent pattern ends with a single * wildcard (a
            terminal wildcard), a derived pattern subsumes it if the
            derived pattern also ends with a single * wildcard and the
            derived pattern's fixed prefix (the portion before the
            terminal *) is equal to or longer than the parent's fixed
            prefix, and the derived prefix begins with the parent prefix.
            For example, a derived pattern /data/reports/* subsumes a
            parent pattern /data/* because /data/reports/ begins with
            /data/ and is longer.

        3.  In all other cases, a derived pattern subsumes a parent
            pattern if and only if the pattern strings are identical.

        This strategy applies to patterns containing character classes
        ([abc], [!abc]) without exception: a derived pattern with a
        different character class than its parent MUST be treated as non-
        subsuming even if semantically narrower.  Enforcement points MUST



  Niyikiza                Expires 17 September 2026              [Page 30]


  Internet-Draft          Attenuating Agent Tokens              March 2026


        NOT attempt semantic evaluation to determine pattern subsumption.
        Deployments requiring richer containment analysis SHOULD use a
        registered extension constraint type (see Appendix C).

     *  *range:* A derived range constraint is valid only if its bounds
        are at least as restrictive as the parent's (derived min >= parent
        min, derived max <= parent max).  A missing bound on the parent is
        treated as unbounded; a missing bound on the derived constraint is
        only valid if the parent bound is also missing.  A derived bound's
        inclusivity may only become more restrictive: a derived
        min_inclusive: false is valid when the parent has min_inclusive:
        true at the same min value (exclusive is strictly tighter), but
        the reverse is not.  The same applies to max_inclusive.

     *  *one_of:* A derived one_of constraint is valid only if its value
        set is a subset of the parent's value set.  Cross-type pairs
        involving a derived not_one_of against a parent one_of are
        invalid: a not_one_of constraint accepts values outside the
        parent's permitted set and cannot be verified as subsuming a
        one_of without domain knowledge.  Enforcement points MUST reject
        this cross-type pair.

     *  *not_one_of:* A derived not_one_of constraint is valid only if its
        excluded set is a superset of the parent's excluded set (can only
        add exclusions, never remove them).

     *  *regex:* This specification does not standardize a regex dialect
        or portable containment algorithm; equality of pattern strings is
        the normative conservative subsumption strategy.  A derived regex
        constraint is valid attenuation of a parent regex constraint if
        and only if the pattern strings are identical.  A derived exact
        constraint subsumes a parent regex constraint if and only if the
        exact value matches the parent regex pattern.  All other cross-
        type pairs involving regex are invalid.  Deployments requiring
        richer containment analysis SHOULD use a registered extension
        constraint type.

     *  *cel:* This specification does not define a general semantic
        containment algorithm for CEL expressions.  The normative
        subsumption strategy requires balanced-parentheses conjunction: a
        derived cel constraint subsumes a parent cel constraint if and
        only if the derived expression string is exactly
        (parent_expression) && (additional_clause).  The parent expression
        MUST appear verbatim inside the leading parentheses.  Each
        additional clause MUST be individually wrapped in balanced
        parentheses.  Multiple additional clauses are permitted: (parent)
        && (clause1) && (clause2).  No other form is considered subsuming.




  Niyikiza                Expires 17 September 2026              [Page 31]


  Internet-Draft          Attenuating Agent Tokens              March 2026


        This requirement is a security invariant, not a style guideline.
        CEL's && operator binds tighter than ||. Without balanced
        parentheses around the additional clause, an attacker can
        append || evil_predicate after the conjunction, which CEL parses
        as (parent && clause) || evil_predicate, a top-level disjunction
        that widens rather than narrows authority.  Wrapping each
        additional clause in balanced parentheses ensures that any ||
        inside the clause is contained within the conjunction and cannot
        widen authority.

        Enforcement points MUST verify balanced parentheses by bracket
        counting, not by semantic evaluation.  Enforcement points MUST NOT
        attempt semantic evaluation to determine subsumption.

        Issuers constructing a derived cel constraint MUST copy the parent
        expression string verbatim inside the leading parentheses and MUST
        wrap each additional clause in balanced parentheses.  If the
        issuer requires a structurally different expression that is
        semantically narrower, it MUST request a new root token from the
        root issuer rather than attempting to rewrite the parent clause.

        Deployments requiring richer policy expressiveness with full
        subsumption support SHOULD use a registered extension type built
        on a language with a decidable containment algorithm (see
        Appendix C).

     *  *wildcard:* A derived wildcard is valid only if the parent is also
        wildcard.  Any other constraint type subsumes a parent wildcard.

     *  *all:* A derived all constraint is valid attenuation of a parent
        all if the derived constraint contains all clauses present in the
        parent (none may be dropped) and each corresponding clause
        satisfies the subsumption relation.  The derived constraint MAY
        add additional clauses at any position, which only further
        restrict the accepted value set.  Dropping any parent clause from
        the derived all would expand authority and MUST be rejected.

        Clause matching for all is subsumption-keyed: for each clause C_p
        in the parent array, the enforcement point MUST find at least one
        clause C_d in the derived array with the same constraint_type such
        that C_d subsumes C_p per this section.  Each parent clause MUST
        be matched to a distinct derived clause (one-to-one assignment); a
        single derived clause MUST NOT be used to satisfy more than one
        parent clause.  If any parent clause cannot be matched, the check
        MUST fail.  Unmatched additional clauses in the derived array are
        permitted.





  Niyikiza                Expires 17 September 2026              [Page 32]


  Internet-Draft          Attenuating Agent Tokens              March 2026


        The following pseudocode describes the matching algorithm.
        Because the one-to-one assignment requirement is order- sensitive
        when multiple clauses share the same constraint_type, the
        algorithm backtracks when a greedy match leads to a dead end.
        (When each constraint_type appears at most once in the parent, no
        backtracking occurs and the algorithm reduces to a linear scan.)

        function check_all_subsumption(parent_clauses, derived_clauses):
          used = set()
          return match(parent_clauses, 0, derived_clauses, used)

        function match(parents, idx, derived, used):
          if idx == len(parents):
            return PASS
          C_p = parents[idx]
          for i, C_d in enumerate(derived):
            if i not in used and
               C_d.constraint_type == C_p.constraint_type and
               subsumes(C_d, C_p):
              used.add(i)
              if match(parents, idx + 1, derived, used) == PASS:
                return PASS
              used.remove(i)    // backtrack
          return FAIL

        The search space is bounded by the number of clauses sharing a
        constraint_type.  In typical usage each type appears at most once,
        giving O(n) behavior.  Implementations MAY employ Hopcroft-Karp or
        similar maximum matching algorithms for the general case.

     *  *any:* A derived any constraint subsumes a parent any constraint
        if every clause in the derived constraint is subsumed by at least
        one clause in the parent constraint, using the per-type
        subsumption rules defined in this section.  Formally: for each
        clause_d in derived.any.constraints, there MUST exist a clause_p
        in parent.any.constraints such that clause_d ⊑ clause_p.  Removing
        clauses is valid (it narrows the accepted set).  Adding clauses is
        invalid (it widens it).  The derived any MUST contain at least one
        clause.  Cross-type subsumption between clauses is permitted: for
        example, a derived clause of exact("pdf") is subsumed by a parent
        clause of pattern("*.pdf") under the cross-type rules in this
        section.









  Niyikiza                Expires 17 September 2026              [Page 33]


  Internet-Draft          Attenuating Agent Tokens              March 2026


        Example: a parent token carries any([exact("pdf"), exact("csv"),
        exact("xlsx")]).  A derived token MAY carry any([exact("pdf"),
        exact("csv")]) because each derived clause is subsumed by a parent
        clause.  A derived token MUST NOT carry any([exact("pdf"),
        exact("docx")]) because exact("docx") is not subsumed by any
        parent clause.

     *  *not:* This specification prescribes a conservative strategy for
        not → not attenuation.  A derived not constraint is valid
        attenuation of a parent not constraint if and only if the two
        constraints are structurally identical, compared as JCS-canonical
        JSON ([RFC8785]).  Although widening the inner constraint
        semantically narrows the negation and restricts authority,
        verifying this direction requires recursive subsumption in
        reverse, which introduces significant implementation complexity
        and risk of divergence.  Implementations MUST NOT attempt semantic
        evaluation to determine not → not subsumption.  Issuers that need
        to tighten a not constraint SHOULD re-issue from the root issuer
        or use a registered extension type with defined negation
        semantics.  Cross-type pairs involving not (for example, exact →
        not(X) or not(X) → exact) are not valid attenuations and MUST be
        rejected.

        Example: a parent token carries not(one_of(["a", "b"])), meaning
        the argument must not be "a" or "b".  A derived token MAY carry an
        identical not(one_of(["a", "b"])) constraint (identity is valid).

        A derived token MUST NOT carry not(one_of(["a"])).  That inner set
        is narrower, so the negation is wider: the derived token accepts
        "b", which the parent denies.  This is a privilege escalation and
        the JCS-identity check rejects it because the two constraints are
        not structurally identical.

        Conversely, a derived token MUST NOT carry not(one_of(["a", "b",
        "c"])).  That inner set is wider, so the negation is narrower: the
        derived token is genuinely more restrictive (it additionally
        denies "c").  However, verifying this direction requires reversing
        the subsumption check on the inner constraint, which introduces
        implementation complexity and risk of divergence.  Implementations
        MUST NOT attempt semantic evaluation to determine not → not
        subsumption.  The issuer MUST re-issue from root.

     *  *contains:* A derived contains constraint is valid attenuation of
        a parent contains if the derived required set is a superset of the
        parent's required set.  Requiring additional elements is a
        restriction; removing required elements would expand the set of
        accepted argument arrays and MUST be rejected.




  Niyikiza                Expires 17 September 2026              [Page 34]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     *  *subset:* A derived subset constraint is valid attenuation of a
        parent subset if the derived allowed set is a subset of the
        parent's allowed set.  Shrinking the allowed set is a restriction;
        adding allowed elements would expand the set of accepted argument
        arrays and MUST be rejected.

     Any (parent constraint type, derived constraint type) pair not
     explicitly permitted by the above rules, or by a registered extension
     constraint's cross-type subsumption declaration (Section 3.5.1), MUST
     be rejected.

  4.6.  I5: Cryptographic Linkage

     derived.par_hash ==
       base64url-nopad(SHA-256(parent JWS Signing Input))

     Each derived token is cryptographically bound to its parent by
     including the SHA-256 digest of the parent token's JWS Signing Input
     in the par_hash claim.  The JWS Signing Input is the ASCII string
     BASE64URL(JWS Protected Header) || '.' || BASE64URL(JWS Payload) as
     defined in [RFC7515] Section 5.1.

     This binding prevents chain splicing: an attacker cannot substitute a
     different parent token to weaken the attenuation constraints visible
     at a given depth.

  4.7.  I6: Proof of Possession

     pop_signature verifies under derived.cnf.jwk

     The presenter of a token chain MUST demonstrate control of the
     private key corresponding to the leaf token's cnf.jwk.  Proof of
     Possession is defined in Section 5.

  5.  Proof of Possession

  5.1.  Rationale

     A token without proof of possession can be replayed by any party that
     obtains a copy of the token.  In agent systems, tokens flow through
     model context, tool invocation results, and inter-agent message
     channels, all of which are observable by other components.  PoP binds
     a specific invocation to the private key of the leaf token's holder.








  Niyikiza                Expires 17 September 2026              [Page 35]


  Internet-Draft          Attenuating Agent Tokens              March 2026


  5.2.  PoP Token Structure

     The holder of the leaf execution token produces a PoP JWT for each
     tool invocation.  The PoP JWT is a compact serialization signed with
     the holder's private key.  It MUST contain the following claims.

     +==========+=============+=========================================+
     | Claim    | Type        | Description                             |
     +==========+=============+=========================================+
     | jti      | string      | Fresh random identifier.  Issuers MUST  |
     |          |             | NOT generate the same jti value for two |
     |          |             | different PoP JWTs.  When a UUID is     |
     |          |             | used, it MUST be encoded as a lowercase |
     |          |             | hyphenated string per [RFC9562].        |
     |          |             | Whether an enforcement point can detect |
     |          |             | reuse depends on whether stateful jti   |
     |          |             | tracking is deployed (see Section 8.6). |
     +----------+-------------+-----------------------------------------+
     | iat      | NumericDate | Time of PoP creation.  MUST reflect the |
     |          |             | actual time of creation.  Enforcement   |
     |          |             | points validate this against a clock    |
     |          |             | tolerance window (see Section 5.3).     |
     +----------+-------------+-----------------------------------------+
     | aat_id   | string      | The jti of the execution token being    |
     |          |             | presented.                              |
     +----------+-------------+-----------------------------------------+
     | aat_tool | string      | The tool identifier being invoked.      |
     |          |             | MUST exactly match a key in the tools   |
     |          |             | map of the leaf token's                 |
     |          |             | authorization_details.  Tool            |
     |          |             | identifiers are compared as byte        |
     |          |             | strings; no Unicode normalization is    |
     |          |             | applied.                                |
     +----------+-------------+-----------------------------------------+
     | hta      | object      | The tool arguments for this invocation. |
     |          |             | Keys are argument names; values are     |
     |          |             | argument values.                        |
     +----------+-------------+-----------------------------------------+

                                   Table 4











  Niyikiza                Expires 17 September 2026              [Page 36]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     The PoP JWT payload MUST be serialized as JCS-canonical JSON
     ([RFC8785]) before JWS signing.  This is a whole-payload requirement,
     not specific to the hta member.  The JWS signing input is therefore
     BASE64URL(JWS Protected Header) || '.' || BASE64URL(JCS(PoP claims)).
     Whole-payload JCS canonicalization ensures a deterministic byte
     representation; in particular, it gives hta stable equality semantics
     so that argument map comparison is unambiguous across implementations
     and languages regardless of JSON serialization choices.

     The PoP JWT MUST be signed using the private key corresponding to the
     leaf execution token's cnf.jwk.  The enforcement point verifies the
     PoP JWT signature against the leaf token's cnf.jwk.

     {
       "jti": "c980f2a1-4a37-4e88-bb3c-9defd37c1a45",
       "iat": 1741600300,
       "aat_id": "01957a41-0081-7c20-bf3a-00a0c91e1234",
       "aat_tool": "read_file",
       "hta": { "path": "/data/q3-report.pdf" }
     }

  5.3.  Verification

     PoP verification is only meaningful against a leaf token whose chain
     has been fully verified per Section 7.  An enforcement point MUST
     complete chain verification (Section 7, steps 1-6) before evaluating
     the PoP JWT.  A valid PoP JWT against an unverified or invalid chain
     MUST NOT result in authorization.

     The enforcement point MUST reject a PoP JWT that:

     1.  Has a signature that does not verify under the leaf token's
         cnf.jwk.

     2.  References an aat_id that does not match the jti of the presented
         leaf token.

     3.  Names a tool in aat_tool that is not authorized by the leaf
         token.

     4.  Presents arguments in hta that violate constraints in the leaf
         token, per the verification algorithm in Section 7 (step 6b).

     5.  Has iat that is outside the enforcement point's accepted clock
         tolerance window (RECOMMENDED: ±30 seconds).






  Niyikiza                Expires 17 September 2026              [Page 37]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     The PoP JWT iat timestamp and clock tolerance window bound the replay
     surface to a short interval.  Implementations that wish to avoid
     shared state MAY use fixed-width time buckets (for example, accepting
     PoP JWTs whose iat falls within the current or immediately preceding
     30-second bucket) to simplify enforcement point implementation.

     Note: The time bucket approach is stateless but probabilistic: a PoP
     JWT captured early in a bucket remains usable until the end of the
     following bucket.  This approach MUST NOT be used for tool
     invocations that have side effects or are not idempotent.  For any
     tool invocation where duplicate execution causes unintended side
     effects, stateful jti tracking MUST be used.

     Full replay prevention — guaranteeing that a given PoP JWT is
     accepted at most once — requires stateful tracking of presented jti
     values across all enforcement points in a deployment.  The mechanism
     for that state (shared cache, database, token-binding infrastructure)
     is deployment-specific and outside the scope of this specification.
     Deployments with strong replay prevention requirements SHOULD consult
     the security considerations in Section 8.6.

  6.  Token Derivation

     A holder of any AAT whose del_depth is strictly less than
     del_max_depth MAY derive a child token as follows.

     1.   Set jti to a fresh unique token identifier, RECOMMENDED to be a
          UUIDv7 value per [RFC9562].

     2.   Set iat to the current time.  Set exp to any value <=
          parent.exp, subject to the constraints in Section 4.4.  Token
          lifetime is a mandatory attenuation dimension.  Every derived
          token is temporally bounded by its parent regardless of
          capability scope.  TTL is the primary revocation mechanism in
          this specification; see Appendix B.8 for deployment guidance.

     3.   Select the aat_type of the child token.  The permitted
          transitions are defined in Section 3.1.  If the child's aat_type
          differs from the parent's, the child MUST use a different
          cnf.jwk than the parent (type-transition key separation).

     4.   Select the set of tools to authorize.  This set MUST be a subset
          of the tools authorized by the parent token.








  Niyikiza                Expires 17 September 2026              [Page 38]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     5.   For each tool, construct a constraint map with the same argument
          keys as the parent's constraint map for that tool (Section 4.5).
          For each key, select a constraint that is at least as
          restrictive as the parent's, per the subsumption rules in
          Section 4.5.  If the parent's constraint map is empty, the
          derived token MAY introduce constraint keys.

     6.   Set del_depth to parent.del_depth + 1.

     7.   Set del_max_depth to any integer value greater than or equal to
          child.del_depth and less than or equal to parent.del_max_depth.
          Setting del_max_depth equal to child.del_depth produces a
          terminal token that cannot be further delegated; higher values
          permit further delegation up to the parent's ceiling.  Both
          bounds are inclusive; the upper bound enforces I2.

     8.   Set par_hash to base64url(SHA-256(parent JWS Signing Input)),
          using base64url encoding without padding ([RFC7515] Appendix C).

     9.   Set cnf.jwk to the intended holder's public key.  The value MUST
          be a public key; private key material MUST NOT appear in this
          field.

     10.  Sign the token with the private key corresponding to the parent
          token's cnf.jwk.  The iss claim MUST be set to the JWK
          Thumbprint URI [RFC9278] of that signing key, using the SHA-256
          hash algorithm.

     Derivation is performed locally by the token holder.  No
     authorization server communication is required.

     A derivation in which none of the above dimensions is strictly
     narrowed (the tool set is identical, all constraints are unchanged,
     del_max_depth is unchanged, and exp is unchanged) is technically
     valid by the invariants.  However, it produces a child token with
     authority identical to its parent, while consuming one delegation
     depth.  Such derivations serve no purpose from a least-privilege
     standpoint and SHOULD NOT be issued.  Enforcement points MAY log
     same-scope derivations as anomalous.

  7.  Chain Verification Algorithm

     The enforcement point receives a chain of tokens ordered from root to
     leaf and MUST execute the following algorithm.  Any failure MUST
     result in denial.






  Niyikiza                Expires 17 September 2026              [Page 39]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     Verification requires only the token chain and the trust anchor
     public key.  No network calls or authorization server availability
     are required.  Chain verification itself is fully offline.  Strong
     replay protection for side-effecting tool invocations may
     additionally require stateful jti tracking as described in
     Section 8.6; that state is outside the inputs of this algorithm.

    Inputs:
      chain:         ordered array of signed JWTs, [root, ..., leaf]
      trust_anchors: set of public keys trusted as root issuers
      tool:          the tool being invoked
      args:          the arguments being passed to the tool
      pop_jwt:       the PoP JWT presented by the agent

    Algorithm:

    1. If chain is empty, DENY.

    2. Verify chain size limits:
       a. Verify the encoded size of each token does not exceed
          MAX_TOKEN_SIZE. If any token exceeds this limit, DENY.
       b. Verify the total encoded size of the chain does not exceed
          MAX_STACK_SIZE. If the chain exceeds this limit, DENY.
       c. For each token, decode the base64url payload segment and
          extract only the `jti` field using minimal JSON parsing.
          If the payload is not valid JSON or does not contain a
          string-valued `jti` field, DENY. Collect all extracted
          `jti` values; if any value appears more than once in the
          chain, DENY (cycle detection). This limited extraction
          prior to signature verification is permitted and required
          for this structural check; it does not constitute the
          application-layer claim deserialization prohibited by the
          post-algorithm note. The extracted `jti` values MUST be
          treated as untrusted until each token's signature is
          verified. Full claim parsing MUST still be deferred until
          after signature verification succeeds for each token.

    3. Verify root token:
       a. Verify the root token's JWS alg header is on the
          implementation's permitted algorithm allowlist and is
          consistent with the verifying trust anchor key's kty and
          crv parameters. If alg is "none", not on the allowlist,
          or inconsistent with the key type, DENY.       [Sec 8.14]
       b. Verify the root token signature against a key in
          trust_anchors. After signature verification succeeds,
          parse the root token's claims. All subsequent root
          checks (3c through 3n) operate on parsed claims.
       c. Verify root.aat_type is "delegation" or "execution".



  Niyikiza                Expires 17 September 2026              [Page 40]


  Internet-Draft          Attenuating Agent Tokens              March 2026


          If any other value, DENY.
       d. Verify root.del_depth == 0.
       e. Verify root.par_hash is absent.
       f. Verify root.exp > now.
       g. Verify root.iat <= now + MAX_IAT_SKEW.
       h. Verify root.exp > root.iat.
       i. Verify root.exp <= root.iat + MAX_TOKEN_LIFETIME.
       j. Verify root.del_max_depth is a non-negative integer not
          exceeding MAX_DELEGATION_DEPTH. If absent or invalid, DENY.
       k. Verify root.jti is present and is a non-empty string.
          If absent or not a string, DENY.
       l. Verify root.iss is present and is a URI. If absent or
          not a URI-formatted string, DENY.
       m. Verify root.cnf is present, contains a `jwk` member, and
          that the `jwk` encodes a public key (MUST NOT contain a
          private key parameter such as `d` for EC/OKP keys or
          `p`, `q` for RSA keys). If absent or invalid, DENY.
       n. Verify root.authorization_details is present and is a
          non-empty array containing at most one entry with type
          "attenuating_agent_token". If absent, empty, or more
          than one such entry is present, DENY.
          Note: for single-token chains where root is also the
          leaf, steps 3 and 6 are the only validation applied.
          Steps 3k through 3n ensure that required claims are
          present before step 6 depends on them, closing the
          bypass window that exists when step 4 does not run.

    4. For each adjacent pair (parent, child) in chain:
       a. Verify child token's JWS alg header is on the
          implementation's permitted algorithm allowlist and is
          consistent with parent.cnf.jwk's kty and crv parameters.
          If alg is "none", not on the allowlist, or inconsistent
          with the key type, DENY.                       [Sec 8.14]
       b. Verify child signature under the key in parent.cnf.jwk. [I1]
          After signature verification, verify required claims are
          present:
          b1. Verify child.jti is present and is a non-empty
              string. If absent or not a string, DENY.
          b2. Verify child.cnf is present, contains a `jwk`
              member, and that the `jwk` encodes a public key
              (MUST NOT contain a private key parameter such as
              `d` for EC/OKP keys or `p`, `q` for RSA keys). If
              absent or invalid, DENY.
          b3. Verify child.authorization_details is present and
              is a non-empty array. If absent or empty, DENY.
          b4. Verify child.del_depth and child.del_max_depth are
              both present and are non-negative integers. If
              absent or not integers, DENY.



  Niyikiza                Expires 17 September 2026              [Page 41]


  Internet-Draft          Attenuating Agent Tokens              March 2026


          b5. Verify child.iss, child.iat, child.exp, child.aat_type,
              and child.par_hash are all present. If any is absent, DENY.
       c. Verify child.iss equals jwk_thumbprint_uri(parent.cnf.jwk). [I1]
       d. Verify child.aat_type is "delegation" or "execution".
          If any other value, DENY.
       e. Verify child.del_depth == parent.del_depth + 1.    [I2]
       f. Verify child.del_depth <= parent.del_max_depth.    [I2]
       g. Verify child.del_depth <= MAX_DELEGATION_DEPTH.    [I2]
       h. Verify child.del_max_depth <= parent.del_max_depth.[I2]
          Note: the requirement that every token's
          del_max_depth <= MAX_DELEGATION_DEPTH is transitively
          satisfied: step 3j verifies this for the root, and
          step 4h at each link ensures the value can only
          decrease. Implementations MAY add this check
          explicitly as defense in depth.
       i. Verify child.exp <= parent.exp.                    [I3]
       j. Verify child.exp > now.                            [I3]
       k. Verify child.iat >= parent.iat.                    [I3]
       l. Verify child.iat <= now + MAX_IAT_SKEW.            [I3]
       m. Verify child.exp > child.iat.                      [I3]
          Note: the requirement child.exp <= child.iat +
          MAX_TOKEN_LIFETIME is transitively satisfied: by
          induction, child.exp <= root.exp (step 4i at each
          link), root.exp <= root.iat + MAX_TOKEN_LIFETIME
          (step 3i), and child.iat >= root.iat (step 4k at
          each link), therefore child.exp <= root.iat +
          MAX_TOKEN_LIFETIME <= child.iat + MAX_TOKEN_LIFETIME.
          Implementations MAY add this check explicitly as
          defense in depth.
       n. Verify child.del_depth <= child.del_max_depth.     [I2]
       o. Verify child.authorization_details contains at most
          one entry with type "attenuating_agent_token". If
          more than one such entry is present, DENY. Note: zero
          entries of this type is permitted for non-leaf tokens
          and represents an empty capability set. Step 4q will
          verify this is a valid attenuation of the parent
          (an empty tool set is always a subset).
       p. For each constraint in child.authorization_details,
          verify the constraint tree depth does not exceed
          MAX_CONSTRAINT_DEPTH. If any constraint tree exceeds
          this limit, DENY.
       q. Verify capability monotonicity (Section 4.5):   [I4]
          q1. Verify every tool in child's authorization_details
              is also present in parent's authorization_details.
              If any child tool is absent from the parent, DENY.
          q2. For each tool present in both parent and child: if
              the parent's constraint map is non-empty, verify the
              child's constraint map contains exactly the same set



  Niyikiza                Expires 17 September 2026              [Page 42]


  Internet-Draft          Attenuating Agent Tokens              March 2026


              of argument keys. If any key is added or removed, DENY.
          q3. For each tool present in both parent and child: if
              the parent's constraint map is empty, the child's
              constraint map MAY contain any set of keys.
          q4. For each argument key present in both parent and
              child constraint maps, verify the child's constraint
              subsumes the parent's per the per-type rules in
              Section 4.5. If any constraint fails subsumption,
              DENY.
       r. Verify child.par_hash equals base64url-nopad(      [I5]
          SHA-256(parent JWS Signing Input)), where
          base64url-nopad denotes base64url encoding without
          padding per {{RFC7515}} Appendix C.
       s. If child.aat_type differs from parent.aat_type, verify
          that the JWK Thumbprint ({{RFC7638}}) of child.cnf.jwk
          differs from the JWK Thumbprint of parent.cnf.jwk
          (type-transition key separation). Implementations MUST
          compare thumbprints, not raw JWK objects, to prevent
          bypasses through key serialization variance.

    5. (Defense in depth) Verify len(chain) equals
       leaf.del_depth + 1. A mismatch indicates a malformed
       or spliced chain assembly.

    6. Verify leaf token:
       a. Verify leaf.authorization_details contains exactly one
          entry with type "attenuating_agent_token". If zero or
          more than one such entry is present, DENY.
       b. If leaf.aat_type is "execution", verify tool is present
          in leaf.authorization_details. Then, for each argument
          in args: if the tool's constraint map is non-empty and
          the argument name is not present in the constraint map,
          DENY (closed-world mode). For each argument name present
          in the constraint map, if that argument is absent from
          args, DENY (constrained argument MUST be present). For
          each argument name present in both the constraint map
          and args, verify the argument value satisfies the
          constraint.
       c. If leaf.aat_type is "delegation", DENY (delegation
          tokens do not authorize direct tool invocation).

    7. Verify PoP JWT:
       a. Verify pop_jwt signature under leaf.cnf.jwk.       [I6]
       b. Verify pop_jwt.aat_id == leaf.jti.
       c. Verify pop_jwt.aat_tool == tool.
       d. Verify pop_jwt.hta, when JCS-canonicalized
          ({{RFC8785}}), equals the JCS-canonical form of the
          args map for this invocation. If the canonical byte



  Niyikiza                Expires 17 September 2026              [Page 43]


  Internet-Draft          Attenuating Agent Tokens              March 2026


          sequences differ, DENY.
       e. Verify pop_jwt.iat is within the clock tolerance
          window. If outside the window, DENY.

    8. PERMIT.

     Enforcement points MUST verify the JWS signature of each token before
     deserializing its payload claims into application-layer data
     structures.  Signature verification operates on the raw encoded
     header and payload bytes (the JWS Signing Input) and does not require
     claim parsing.  Full claim parsing MUST NOT occur until after
     signature verification succeeds for that token.  This ordering
     prevents parser-based denial-of-service attacks on maliciously
     crafted payloads.  The sole exception is step 2c: extracting only the
     jti string field for cycle detection prior to signature verification
     is permitted, provided the implementation treats the extracted value
     as untrusted until the corresponding signature is verified.
     Enforcement points MUST reject any token whose JWS alg header is
     "none".  The "none" algorithm provides no cryptographic protection
     and MUST NOT be used in any AAT or PoP JWT.

     The hta comparison in step 7d requires both the enforcement point and
     the PoP JWT issuer to use JCS canonicalization ([RFC8785]).  The
     enforcement point MUST canonicalize the args map independently and
     compare the resulting byte sequence against the canonical form
     committed to by the PoP JWT signature.  Implementations MUST NOT
     compare raw JSON strings; surface differences such as key ordering or
     numeric representation (e.g., 1.0 vs 1) are resolved by
     canonicalization before comparison.

     The JWS alg header value MUST be consistent with the key type of the
     key used to verify the signature: the trust anchor public key for
     root tokens, and the cnf.jwk of the parent token for derived tokens.
     Enforcement points MUST reject any token where the declared alg is
     not compatible with the verifying key's kty and crv parameters.  For
     example, a token whose alg is "EdDSA" MUST be verified against an OKP
     key with "crv": "Ed25519" or "crv": "Ed448".  A mismatch between the
     declared algorithm and the verifying key type MUST result in denial,
     regardless of whether the signature bytes would verify under an
     alternate interpretation.

  8.  Security Considerations









  Niyikiza                Expires 17 September 2026              [Page 44]


  Internet-Draft          Attenuating Agent Tokens              March 2026


  8.1.  Threat Model

     This section characterizes the threats that AATs mitigate and the
     threats that are outside the scope of this mechanism.
     Implementations SHOULD use this characterization to evaluate whether
     AATs are sufficient for their threat environment and to identify what
     complementary controls are required.

  8.1.1.  Threats Mitigated

     *Prompt injection leading to unauthorized tool invocation.* An
     attacker who injects instructions into an agent's input cannot cause
     the agent to invoke tools outside the scope encoded in its token.
     The enforcement point rejects any invocation of an unauthorized tool
     regardless of the agent's stated rationale.

     *Hallucinated tool invocations with out-of-scope arguments.* Even
     when an agent invokes an authorized tool, argument constraints in the
     leaf token restrict the argument values the enforcement point will
     accept.  An agent that hallucinates an argument value outside the
     authorized range is denied at the enforcement point before the tool
     executes.

     *Confused deputy attacks.* A sub-agent that receives a derived token
     cannot exercise authority beyond what its token encodes, even if it
     is invoked by a trusted orchestrator.  The token carries its own
     authorization ceiling.  There is no ambient authority to confuse.

     *Privilege escalation across delegation hops.* The capability
     monotonicity invariant (I4) ensures that authority can only narrow at
     each delegation step.  A derived token cannot authorize tools or
     argument values absent from its parent token.  An agent that attempts
     to mint a derived token with broader scope will produce a token that
     fails chain verification at the enforcement point.

     *Compromised sub-agents.* If a sub-agent is compromised, the blast
     radius is bounded by the scope of the token it holds.  The attacker
     cannot use the compromised agent to escalate to broader authority,
     invoke tools outside the token's scope, or derive tokens with wider
     permissions than the compromised token encodes.

     *Chain splicing.* The par_hash claim (I5) binds each derived token to
     the specific bytes of its parent token.  An attacker cannot
     substitute a different parent token into the chain to change the
     authority ceiling without invalidating the par_hash verification at
     the enforcement point.





  Niyikiza                Expires 17 September 2026              [Page 45]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     *Token replay for irreversible operations.* For irreversible or side-
     effecting tool invocations, stateful jti tracking at the enforcement
     point enables prevention of PoP JWT replay.  See Section 8.6 for the
     distinction between stateful and probabilistic replay controls and
     the deployment requirements for each.

  8.1.2.  Threats Not Mitigated

     *Malicious or compromised root issuer.* The security of all chains
     depends on the integrity of the trust anchor key.  A root issuer that
     mints tokens with overly broad scopes, or whose signing key is
     compromised, undermines the authorization guarantees of every chain
     it anchors.  AATs provide no mechanism to detect or constrain a
     malicious root issuer.  Key management, rotation procedures, and root
     issuer accountability are deployment concerns outside the scope of
     this specification.

     *Compromised enforcement point.* An enforcement point that skips
     chain verification, ignores constraint evaluation, or accepts forged
     tokens provides no security guarantee regardless of the token format.
     AATs assume enforcement points are honest and implement the
     verification algorithm in Section 7 correctly.  Enforcement point
     integrity is a deployment concern.

     *Actions within authorized argument constraints.* AATs restrict which
     tools an agent may invoke and what argument values are permitted.
     They do not restrict which authorized invocations an agent chooses to
     make, in what order, or how many times.  An agent that makes
     excessive or unintended use of its authorized tools within the bounds
     of its token is not detectable at the enforcement point.  Rate
     limiting, audit logging, and behavioral monitoring are complementary
     controls for this threat.

     *Compromised holder key.* If an agent's private key is stolen, the
     attacker can exercise the full authority encoded in that agent's
     token until the token expires.  The blast radius is bounded by the
     token scope, but within that scope the attacker has full
     authorization.  Short token lifetimes (Section 8.4) limit the
     exposure window.

     *Model exfiltration and side-channel attacks.* An attacker who
     extracts an agent's model weights, system prompt, or in-context state
     may be able to predict or manipulate the agent's behavior
     independently of its token constraints.  AATs operate at the
     authorization layer and have no visibility into the model layer.






  Niyikiza                Expires 17 September 2026              [Page 46]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     *Social engineering of the root issuer.* An attacker who convinces
     the root issuer to mint a root delegation token with broad scope
     obtains broad authority through legitimate token issuance.  This is
     not detectable by chain verification.

  8.2.  Attenuation as the Security Invariant

     The security guarantee of this specification rests entirely on the
     enforcement of the capability monotonicity invariant (I4).  An
     enforcement point that fails to check I4, or that checks it
     incorrectly, provides no blast radius containment.  Implementers MUST
     test I4 enforcement against the full constraint attenuation matrix in
     Section 4.5, including all (parent type, child type) pairs, and MUST
     reject all pairs not explicitly permitted.

     The other invariants (I1, I2, I3, I5, I6) rely on well-established
     cryptographic primitives and validation patterns with substantial
     prior art in deployed systems.  I4 is novel.  Formal verification of
     the I4 subsumption rules is in progress, using bounded model checking
     ([ALLOY]) for set-theoretic constraint types and SMT solving ([Z3])
     for domain-specific types requiring arithmetic or string reasoning.
     For the remaining constraint types, which use conservative syntactic
     strategies (Section 4.5), model-level verification is ongoing.
     Implementers are encouraged to treat the subsumption logic for those
     types with corresponding caution and to publish independent analyses.

     The reference implementation includes a test suite covering
     monotonicity of the attenuation invariants under arbitrary sequences,
     normalization idempotence across encode/decode round-trips, and
     enforcement agreement between in-memory and deserialized constraint
     evaluation.  See Appendix E for implementation status.

  8.3.  Root Key Compromise

     A compromised trust anchor key allows an attacker to issue arbitrary
     root tokens.  This breaks the security guarantees of all chains
     anchored to that key.  Deployments SHOULD implement key rotation
     procedures and revocation mechanisms appropriate to their risk model.
     The specific mechanism for root key revocation, including revocation
     list formats, distribution protocols, and enforcement point update
     procedures, is outside the scope of this specification.










  Niyikiza                Expires 17 September 2026              [Page 47]


  Internet-Draft          Attenuating Agent Tokens              March 2026


  8.4.  Holder Key Compromise

     A compromised holder key allows an attacker to present existing
     tokens issued to that holder.  The attacker cannot derive tokens with
     broader scope than the compromised token grants.  Mitigation is
     revocation of tokens bound to the compromised key, or expiry-based
     recovery for short-lived tokens.

  8.5.  Chain Splicing

     The par_hash invariant (I5) is the primary defense against chain
     splicing, as described in Section 8.1.1.  Enforcement points MUST
     verify par_hash at every chain link per step 4r of the verification
     algorithm (Section 7).

  8.6.  Replay Attacks

     The PoP JWT binds a specific invocation to a nonce, a timestamp, the
     target tool, and the presented arguments.  The timestamp window
     limits the interval during which a captured PoP JWT remains usable to
     approximately twice the clock tolerance (RECOMMENDED: ±30 seconds,
     giving a window of roughly 60 seconds).  This provides probabilistic
     replay resistance and is appropriate only for idempotent, read-only
     tool invocations where duplicate execution is harmless.

     For tool invocations that are irreversible or have significant side
     effects, including financial transactions, data deletion, writes to
     external systems, and any operation that cannot be undone:
     enforcement points MUST implement stateful jti tracking for PoP JWTs
     and MUST NOT rely solely on the timestamp window for replay
     protection.

     This specification requires stateful jti tracking for irreversible
     operations but does not define the storage backend, consistency
     model, or distribution protocol for that state.  The required
     consistency properties depend on the deployment topology and the risk
     tolerance of the application.  Deployments SHOULD treat the time-
     windowed PoP as a probabilistic control and layer additional
     idempotency mechanisms at the application level for high-value
     operations.











  Niyikiza                Expires 17 September 2026              [Page 48]


  Internet-Draft          Attenuating Agent Tokens              March 2026


  8.7.  Constraint Evaluation

     Several constraint types introduce potential for denial-of-service
     through expensive evaluation. regex patterns can cause catastrophic
     backtracking. cel expressions execute arbitrary logic at argument
     check time.  Enforcement points SHOULD impose evaluation timeouts on
     any constraint type whose check predicate is not O(n) in the length
     of the argument value.

     The subsumption check for cel constraints (the balanced-parentheses
     bracket counting described in Section 4.5) is O(n) in expression
     length and does not evaluate the expression.  Only the runtime check
     predicate, which evaluates the CEL expression against actual argument
     values at invocation time, carries unbounded cost.  These are
     distinct operations; implementations MUST NOT conflate them.

     Extension constraint types registered under Section 3.5 MUST document
     their computational complexity and any resource limits
     implementations SHOULD enforce.

  8.8.  Depth Limit

     Enforcement points MUST enforce a finite MAX_DELEGATION_DEPTH to
     prevent resource exhaustion from artificially deep chains.  The
     appropriate value is deployment-specific: linear orchestration chains
     require far fewer hops than swarm architectures with deep fan-out
     delegation.  Implementations SHOULD choose a value that reflects the
     maximum chain depth their deployment topology requires, without
     imposing an artificial ceiling on legitimate use cases.  See
     Appendix B.5 for guidance on selecting an appropriate value.

     The security rationale for depth limiting goes beyond resource
     exhaustion.  Each delegation hop introduces an additional agent into
     the trust chain: the enforcement point necessarily trusts not only
     that the leaf token holder is honest, but that every intermediate
     holder made sound attenuation decisions.  A compromised or
     misdirected intermediate agent can narrow constraints in ways that
     serve an attacker's goals while remaining within the invariants.  The
     depth limit bounds the number of such trust extensions that a single
     root grant can produce.

     The del_max_depth claim in the root token is the root issuer's
     explicit policy on chain topology.  An implementation that ignores
     del_max_depth or enforces only a global implementation limit without
     checking per-token values violates this policy.  Enforcement points
     MUST check both the per-token del_max_depth value (step 4f of
     Section 7) and the global MAX_DELEGATION_DEPTH (step 4g of
     Section 7).  Neither check alone is sufficient.



  Niyikiza                Expires 17 September 2026              [Page 49]


  Internet-Draft          Attenuating Agent Tokens              March 2026


  8.9.  Unknown Constraint Types

     Enforcement points MUST deny authorization when they encounter an
     unknown constraint type.  Permitting invocation in the presence of an
     unrecognized constraint would silently remove a restriction the
     issuer intended to enforce.

  8.10.  Token Revocation

     Revocation of individual AATs, including derived tokens, is outside
     the scope of this specification.  The offline delegation model trades
     per-token revocation granularity for verifiability without
     authorization server availability.  This is a deliberate design
     choice, not an oversight.

     Deployments SHOULD use short token lifetimes as the primary recovery
     mechanism.  A short-lived execution token provides a bounded damage
     window that is operationally equivalent to revocation for most threat
     models, without the availability and consistency requirements that a
     revocation list imposes.  Root tokens SHOULD be issued with the
     shortest lifetime compatible with the intended delegation chain
     depth.

     Root trust anchor rotation (replacing the trust anchor signing key
     and re-issuing root tokens) is the appropriate response to a root key
     compromise.  Enforcement points SHOULD support configurable trust
     anchor sets to enable rotation without downtime.

     Revocation list distribution, token status list integration, and per-
     token introspection mechanisms are deferred to a companion document.

  8.11.  Clock Skew

     This specification uses clock-based checks in two distinct contexts
     with different semantics.  MAX_IAT_SKEW (Section 4.4, RECOMMENDED: 30
     seconds) is a one-sided future-dating tolerance applied to token iat
     values: it prevents a token issued slightly in the future from being
     rejected due to minor clock drift between issuer and enforcement
     point.  The PoP JWT timestamp window (Section 5.3, RECOMMENDED: ±30
     seconds) is a bilateral replay window applied to PoP JWT iat values:
     it bounds how long a captured PoP JWT remains usable.  These are
     independent parameters enforced at different points in the
     verification algorithm and SHOULD be configured separately.

     PoP JWT timestamp verification requires synchronized clocks.  The
     RECOMMENDED tolerance window is ±30 seconds, which accommodates
     typical Network Time Protocol (NTP) synchronized deployments with
     generous margin.  Deployments running on cloud infrastructure with



  Niyikiza                Expires 17 September 2026              [Page 50]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     guaranteed NTP synchronization SHOULD target ±5 to ±10 seconds.
     Deployments with stricter security requirements MAY reduce this
     window further.

     Implementations MUST enforce a finite maximum tolerance window.
     Values beyond ±60 seconds provide negligible additional clock skew
     tolerance while meaningfully expanding the PoP replay window and are
     NOT RECOMMENDED.  A value of ±30 seconds is the conservative
     baseline; the ±60 second ceiling is intended only for heterogeneous
     environments such as embedded systems or degraded connectivity
     scenarios.

  8.12.  Type-Transition Key Separation

     The requirement that any type transition use a distinct key
     (Section 3.1) is not an architectural preference; it closes specific
     escalation paths.  In traditional capability systems, same-key self-
     issuance across authority types is often benign because the principal
     model is static and the runtime is trusted.  Agentic systems have
     neither property: agents operate autonomously across untrusted
     environments, may be subject to prompt injection or context
     manipulation, and act on behalf of humans without per-action
     confirmation.

     If a single key can move between planning authority and tool
     invocation authority, the delegation/execution boundary collapses
     under any compromise.  The restriction ensures that a compromised
     orchestrator holding a delegation token cannot directly invoke tools
     without involving a distinct execution-bound key, and that a
     compromised executor cannot create new delegation branches under the
     same identity.  This preserves the accountability boundary between
     authority types and ensures that key separation is enforced
     structurally rather than by policy.

  8.13.  CEL Conjunction Privilege Escalation

     The cel constraint subsumption strategy (Section 4.5) requires that
     additional clauses in a derived expression be individually wrapped in
     balanced parentheses: (parent) && (clause).  This requirement is a
     security invariant.

     Without balanced parentheses, an attacker constructing a derived cel
     constraint can append a top-level disjunction to widen authority.
     For example, given a parent expression amount < 10000, the derived
     expression (amount < 10000) && true || amount < 1000000 passes a
     naive prefix check but CEL parses it as ((amount < 10000) && true) ||
     (amount < 1000000), which simplifies to amount < 1000000, a 100x
     privilege escalation.



  Niyikiza                Expires 17 September 2026              [Page 51]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     Enforcement points MUST implement the subsumption check using
     balanced-parentheses bracket counting as specified in Section 4.5.
     Implementations MUST reject any derived cel expression where the
     additional clause is not wrapped in balanced parentheses, regardless
     of whether the expression appears semantically narrower.
     Implementations MUST NOT attempt semantic evaluation to determine
     subsumption.

  8.14.  Algorithm Confusion

     AATs are signed JWTs.  Implementations are subject to the full class
     of JWT algorithm confusion attacks, including alg: "none" acceptance,
     symmetric/asymmetric key confusion (RS256/HS256 key reuse), and
     algorithm substitution across tokens in the same chain.

     Enforcement points MUST maintain an explicit allowlist of permitted
     signature algorithms and MUST reject any token whose alg header value
     is not on that list.  Implementations MUST reject tokens with alg:
     "none" unconditionally and MUST NOT treat the absence of an alg
     header as equivalent to any permitted algorithm.

     In chains where multiple token types are verified, implementations
     MUST apply the algorithm allowlist independently to each token.
     Accepting a weaker algorithm on an intermediate token because the
     leaf token used a strong algorithm is a verification failure.

     The RECOMMENDED algorithm set is the same as for DPoP [RFC9449]:
     ES256, ES384, ES512, RS256, RS384, RS512, PS256, PS384, PS512, EdDSA.
     Symmetric algorithms (HS256, HS384, HS512) MUST NOT be used for AAT
     signatures; symmetric keys cannot provide the per-holder key binding
     that PoP requires.

  8.15.  Token Content Visibility

     AAT payloads are integrity-protected but not encrypted.  Token
     contents, including tool identifiers, argument constraints, and
     delegation chain structure, are visible to any party that observes
     the token in transit or at rest.  Deployments SHOULD transmit AAT
     chains over encrypted transport (e.g., TLS) and SHOULD treat stored
     tokens as sensitive material.  Token encryption is outside the scope
     of this specification.

  9.  IANA Considerations

  9.1.  JWT Claims Registry

     This document requests registration of the following claims in the
     IANA JSON Web Token Claims Registry [RFC7519].



  Niyikiza                Expires 17 September 2026              [Page 52]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     *AAT claims:*

     +===============+==========================+============+===========+
     | Claim Name    | Claim                    | Change     | Reference |
     |               | Description              | Controller |           |
     +===============+==========================+============+===========+
     | aat_type      | Attenuating              | IETF       | This      |
     |               | Authorization            |            | document  |
     |               | Token type               |            |           |
     +---------------+--------------------------+------------+-----------+
     | del_depth     | Delegation               | IETF       | This      |
     |               | chain depth              |            | document  |
     +---------------+--------------------------+------------+-----------+
     | del_max_depth | Maximum                  | IETF       | This      |
     |               | delegation               |            | document  |
     |               | chain depth              |            |           |
     +---------------+--------------------------+------------+-----------+
     | par_hash      | Parent token             | IETF       | This      |
     |               | JWS Signing              |            | document  |
     |               | Input hash               |            |           |
     +---------------+--------------------------+------------+-----------+

                                    Table 5

     The tools map is not a top-level JWT claim; it is a member nested
     inside the authorization_details array entry with type:
     "attenuating_agent_token", as defined in Section 3.3.  Its structure
     and semantics are governed by the AAT Constraint Type Registry
     (Section 9.3) and the RAR profile defined in this document, not by
     the JWT Claims Registry.

     *PoP JWT claims:*

      +============+===================+===================+===========+
      | Claim Name | Claim Description | Change Controller | Reference |
      +============+===================+===================+===========+
      | aat_id     | AAT jti being     | IETF              | This      |
      |            | presented         |                   | document  |
      +------------+-------------------+-------------------+-----------+
      | aat_tool   | Tool identifier   | IETF              | This      |
      |            | for PoP binding   |                   | document  |
      +------------+-------------------+-------------------+-----------+
      | hta        | Tool arguments    | IETF              | This      |
      |            | for PoP binding   |                   | document  |
      +------------+-------------------+-------------------+-----------+

                                   Table 6




  Niyikiza                Expires 17 September 2026              [Page 53]


  Internet-Draft          Attenuating Agent Tokens              March 2026


  9.2.  OAuth Authorization Details Types Registry

     This document requests registration of the following type in the IANA
     OAuth Authorization Details Types Registry established by [RFC9396].

                  +=========================+===============+
                  | Type Name               | Reference     |
                  +=========================+===============+
                  | attenuating_agent_token | This document |
                  +-------------------------+---------------+

                                    Table 7

  9.3.  AAT Constraint Type Registry

     This document requests IANA create the "Attenuating Authorization
     Token Constraint Types" registry.  The registration policy for this
     registry is Specification Required [RFC8126].

  9.3.1.  Designated Expert Instructions

     Designated experts MUST verify that each submitted registration
     satisfies all of the following criteria before approving it:

     1.  The type name is a lowercase string containing only letters,
         digits, and underscores, and does not conflict with an existing
         registered type name.

     2.  The check predicate is fully specified: given any argument value,
         an independent implementer can determine without ambiguity
         whether the predicate returns true or false.

     3.  The subsumes verification procedure satisfies the decidable,
         sound, and deterministic properties defined in Section 3.5.1.  If
         the constraint language does not support a general containment
         algorithm, the registration prescribes a conservative syntactic
         strategy and formally justifies its soundness.

     4.  The cross-type subsumption rules enumerate every (parent type,
         child type) pair involving both the new type and all existing
         core types that the registration declares valid, with explicit
         conditions.  Unlisted pairs are implicitly invalid; the
         registration MUST NOT rely on the catch-all rejection rule to
         handle pairs that deserve explicit treatment.

     5.  The reference is a stable, publicly accessible document.
         Internet-Drafts that have not yet been published as RFCs are not
         acceptable as stable references.



  Niyikiza                Expires 17 September 2026              [Page 54]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     Designated experts SHOULD request clarification when cross-type rules
     are incomplete, when the subsumption procedure's soundness is not
     formally justified, or when the check predicate leaves ambiguous
     cases unresolved.

  9.3.2.  Registration Template

     Registration requests MUST use the following template:











































  Niyikiza                Expires 17 September 2026              [Page 55]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     Type name:
       (A lowercase string. Example: "path_containment")

     Additional members:
       (List each JSON member name, its JSON type, whether it is required
       or optional, its default value if optional, and its semantics.
       Example: "root (string, required): An absolute path prefix.")

     check predicate:
       (A complete, unambiguous specification of the boolean predicate
       evaluated against an argument value at invocation time. Must
       cover all edge cases including null, empty, and out-of-range
       inputs.)

     subsumes verification procedure:
       (A complete formal definition of what it means for one instance
       of this constraint type to be at least as restrictive as another.
       Must state whether the procedure is conservative and, if so, which
       semantically subsuming pairs it rejects. Must include a soundness
       argument: if the procedure returns true for (C_parent, C_child),
       then for all values v: C_child.check(v) implies C_parent.check(v).)

     cross-type subsumption rules:
       (An explicit enumeration of every (parent type, child type) pair
       involving this type that is a valid attenuation, and the conditions
       under which it is valid. List both directions: this type as parent
       and this type as child. All unlisted pairs are implicitly invalid.
       Example:
         - (exact, this_type): valid if the exact value satisfies this
           type's check predicate.
         - (this_type, exact): invalid.
         - (this_type, this_type): valid if [condition].)

     security considerations:
       (Any security properties, limitations, or attack surfaces specific
       to this constraint type, including known cases where the check
       predicate or subsumption procedure can be bypassed or confused.)

     reference:
       (A stable, publicly accessible document defining all of the above.)

  9.3.3.  Initial Registry Entries

     The core constraint types defined in Section 3.4 of this document
     constitute the initial registry entries.  For each type, the check
     predicate and additional members are defined in Section 3.4, and the
     subsumption rules and cross-type pairs are defined in Section 4.5.




  Niyikiza                Expires 17 September 2026              [Page 56]


  Internet-Draft          Attenuating Agent Tokens              March 2026


              +============+===================================+
              | Type Name  | Reference                         |
              +============+===================================+
              | exact      | This document (Sections 3.4, 4.5) |
              +------------+-----------------------------------+
              | pattern    | This document (Sections 3.4, 4.5) |
              +------------+-----------------------------------+
              | range      | This document (Sections 3.4, 4.5) |
              +------------+-----------------------------------+
              | one_of     | This document (Sections 3.4, 4.5) |
              +------------+-----------------------------------+
              | not_one_of | This document (Sections 3.4, 4.5) |
              +------------+-----------------------------------+
              | contains   | This document (Sections 3.4, 4.5) |
              +------------+-----------------------------------+
              | subset     | This document (Sections 3.4, 4.5) |
              +------------+-----------------------------------+
              | regex      | This document (Sections 3.4, 4.5) |
              +------------+-----------------------------------+
              | cel        | This document (Sections 3.4, 4.5) |
              +------------+-----------------------------------+
              | wildcard   | This document (Sections 3.4, 4.5) |
              +------------+-----------------------------------+
              | all        | This document (Sections 3.4, 4.5) |
              +------------+-----------------------------------+
              | any        | This document (Sections 3.4, 4.5) |
              +------------+-----------------------------------+
              | not        | This document (Sections 3.4, 4.5) |
              +------------+-----------------------------------+

                                   Table 8

  9.4.  OAuth Authorization Server Metadata Registry

     This document requests registration of the following parameter in the
     IANA OAuth Authorization Server Metadata registry established by
     [RFC8414].

     +====================+====================+============+===========+
     | Metadata Parameter | Metadata           | Change     | Reference |
     |                    | Description        | Controller |           |
     +====================+====================+============+===========+
     | aat_issuer         | Indicates root AAT | IETF       | This      |
     |                    | issuance support   |            | document  |
     +--------------------+--------------------+------------+-----------+

                                   Table 9




  Niyikiza                Expires 17 September 2026              [Page 57]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     aat_issuer is a boolean value.  When present and true, it indicates
     that the root issuer supports issuance of AAT root tokens as
     described in Section 3.7.  When absent, the AS is assumed not to
     support AAT issuance.

  9.5.  OAuth Token Type Registration

     This document requests registration of the following token type in
     the OAuth Token Type Registry ([RFC6749] Section 11.1):

     *  Type name: aat

     *  Additional Token Endpoint Response Parameters: (none)

     *  HTTP Authentication Scheme(s): (none; not a bearer token)

     *  Change controller: IETF

     *  Specification document(s): This document

  9.6.  OAuth Token Endpoint Parameters Registry

     This document requests registration of the following parameter in the
     OAuth Parameters Registry established by [RFC6749] Section 11.2:

     *  Parameter name: cnf

     *  Parameter usage location: token request

     *  Change controller: IETF

     *  Specification document(s): This document, [RFC7800] Section 3.1

     The cnf parameter carries a key confirmation object as defined in
     [RFC7800].  When used at the token endpoint, its value MUST be a JSON
     object containing a jwk member with the requesting agent's public
     key.  The authorization server binds this key into the issued AAT's
     cnf.jwk claim.  The semantics of the cnf object are defined by
     [RFC7800]; this registration documents its use at the OAuth token
     endpoint for AAT issuance.

  10.  References

  10.1.  Normative References







  Niyikiza                Expires 17 September 2026              [Page 58]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
                Resource Identifier (URI): Generic Syntax", STD 66,
                RFC 3986, DOI 10.17487/RFC3986, January 2005,
                <https://www.rfc-editor.org/info/rfc3986>.

     [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
                Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
                2015, <https://www.rfc-editor.org/info/rfc7515>.

     [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
                DOI 10.17487/RFC7517, May 2015,
                <https://www.rfc-editor.org/info/rfc7517>.

     [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
                (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
                <https://www.rfc-editor.org/info/rfc7519>.

     [RFC7638]  Jones, M. and N. Sakimura, "JSON Web Key (JWK)
                Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September
                2015, <https://www.rfc-editor.org/info/rfc7638>.

     [RFC7800]  Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
                Possession Key Semantics for JSON Web Tokens (JWTs)",
                RFC 7800, DOI 10.17487/RFC7800, April 2016,
                <https://www.rfc-editor.org/info/rfc7800>.

     [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
                Signature Algorithm (EdDSA)", RFC 8032,
                DOI 10.17487/RFC8032, January 2017,
                <https://www.rfc-editor.org/info/rfc8032>.

     [RFC8785]  Rundgren, A., Jordan, B., and S. Erdtman, "JSON
                Canonicalization Scheme (JCS)", RFC 8785,
                DOI 10.17487/RFC8785, June 2020,
                <https://www.rfc-editor.org/info/rfc8785>.

     [RFC9278]  Jones, M. and K. Yasuda, "JWK Thumbprint URI", RFC 9278,
                DOI 10.17487/RFC9278, August 2022,
                <https://www.rfc-editor.org/info/rfc9278>.

     [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
                Representation (CBOR)", STD 94, RFC 8949,
                DOI 10.17487/RFC8949, December 2020,
                <https://www.rfc-editor.org/info/rfc8949>.







  Niyikiza                Expires 17 September 2026              [Page 59]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     [RFC9396]  Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
                Rich Authorization Requests", RFC 9396,
                DOI 10.17487/RFC9396, May 2023,
                <https://www.rfc-editor.org/info/rfc9396>.

     [RFC9562]  Davis, K., Peabody, B., and P. Leach, "Universally Unique
                IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
                2024, <https://www.rfc-editor.org/info/rfc9562>.

     [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
                RFC 6749, DOI 10.17487/RFC6749, October 2012,
                <https://www.rfc-editor.org/info/rfc6749>.

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/info/rfc2119>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/info/rfc8174>.

  10.2.  Informative References

     [RFC8414]  Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
                Authorization Server Metadata", RFC 8414,
                DOI 10.17487/RFC8414, June 2018,
                <https://www.rfc-editor.org/info/rfc8414>.

     [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
                Writing an IANA Considerations Section in RFCs", BCP 26,
                RFC 8126, DOI 10.17487/RFC8126, June 2017,
                <https://www.rfc-editor.org/info/rfc8126>.

     [RFC8392]  Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
                "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
                May 2018, <https://www.rfc-editor.org/info/rfc8392>.

     [RFC8693]  Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
                and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
                DOI 10.17487/RFC8693, January 2020,
                <https://www.rfc-editor.org/info/rfc8693>.

     [RFC9052]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
                Structures and Process", STD 96, RFC 9052,
                DOI 10.17487/RFC9052, August 2022,
                <https://www.rfc-editor.org/info/rfc9052>.




  Niyikiza                Expires 17 September 2026              [Page 60]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     [RFC9449]  Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
                Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
                Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
                September 2023, <https://www.rfc-editor.org/info/rfc9449>.

     [BISCUIT]  Eclipse Foundation, "Biscuit: Distributed Authorization
                Tokens", n.d., <https://doc.biscuitsec.org/reference/
                specifications.html>.

     [MACAROONS]
                Birgisson, A., Politz, J. G., Erlingsson, U., Taly, A.,
                Vrable, M., and M. Lentczner, "Macaroons: Cookies with
                Contextual Caveats for Decentralized Authorization in the
                Cloud", NDSS 2014, 2014,
                <https://research.google/pubs/pub41892/>.

     [SALTZER75]
                Saltzer, J. H. and M. D. Schroeder, "The Protection of
                Information in Computer Systems", Proceedings of the
                IEEE Vol. 63, No. 9, 1975,
                <https://doi.org/10.1109/PROC.1975.9939>.

     [HARDY88]  Hardy, N., "The Confused Deputy (or why capabilities might
                have been invented)", ACM SIGOPS Operating Systems
                Review Vol. 22, No. 4, 1988,
                <https://dl.acm.org/doi/10.1145/54289.871709>.

     [CAMEL25]  Debenedetti, E., Shumailov, I., Fan, T., Hayes, J.,
                Carlini, N., Fabian, D., Kern, C., Shi, C., Terzis, A.,
                and F. Tramèr, "Defeating Prompt Injections by Design",
                2025, <https://arxiv.org/abs/2503.18813>.

     [DEEPMIND26]
                Tomašev, N., Franklin, M., and S. Osindero, "Intelligent
                AI Delegation", 2026, <https://arxiv.org/abs/2602.11865>.

     [WIMSE-ARCH]
                Salowey, J., Rosomakho, Y., and H. Tschofenig, "Workload
                Identity in a Multi System Environment (WIMSE)
                Architecture", March 2026,
                <https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/>.

     [WIMSE-S2S]
                Campbell, B., Salowey, J. A., Schwenkschuster, A., and Y.
                Sheffer, "WIMSE Workload-to-Workload Authentication",
                October 2025, <https://datatracker.ietf.org/doc/draft-
                ietf-wimse-s2s-protocol/>.




  Niyikiza                Expires 17 September 2026              [Page 61]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     [DENNIS66] Dennis, J. B. and E. C. Van Horn, "Programming Semantics
                for Multiprogrammed Computations", Communications of the
                ACM Vol. 9, No. 3, 1966,
                <https://doi.org/10.1145/365230.365252>.

     [MILLER06] Miller, M. S., "Robust Composition: Towards a Unified
                Approach to Access Control and Concurrency Control", PhD
                Dissertation Johns Hopkins University, 2006,
                <http://www.erights.org/talks/thesis/>.

     [ALLOY]    Jackson, D., "Alloy: A Lightweight Object Modelling
                Notation", ACM Transactions on Software Engineering and
                Methodology Vol. 11, No. 2, 2002,
                <https://doi.org/10.1145/505145.505149>.

     [Z3]       de Moura, L. and N. Bjørner, "Z3: An Efficient SMT
                Solver", TACAS 2008, LNCS 4963, 2008,
                <https://github.com/Z3Prover/z3>.

  Appendix A.  Comparison with Related OAuth Mechanisms (Non-Normative)

  A.1.  Token Exchange (RFC 8693)

     RFC 8693 allows a client to exchange one token for another,
     potentially with reduced scope, by contacting the authorization
     server.  The server enforces scope reduction.  This requires network
     connectivity to the authorization server at each delegation hop and
     cannot be performed offline.

     This specification allows a token holder to derive a new token
     locally, without contacting the authorization server.  The
     attenuation invariant is enforced by the chain verification
     algorithm, not by a server-side policy check.

  A.2.  Rich Authorization Requests (RFC 9396)

     RFC 9396 defines a structured format for expressing fine-grained
     authorization details in OAuth tokens.  This specification uses the
     authorization_details claim format from RFC 9396 and extends it with:
     (1) a delegation chain model that links tokens via cryptographic
     hashes, (2) monotonic attenuation invariants that constrain what
     derived tokens may express, and (3) proof-of-possession binding that
     ties invocations to specific key holders.








  Niyikiza                Expires 17 September 2026              [Page 62]


  Internet-Draft          Attenuating Agent Tokens              March 2026


  A.3.  DPoP (RFC 9449)

     DPoP ([RFC9449]) is a token theft prevention mechanism that binds an
     existing OAuth access token to a holder key, ensuring that a stolen
     token cannot be presented without the corresponding private key.
     DPoP does not change what the access token authorizes; the token's
     authorization claims are unchanged.  The resource server grants
     whatever the access token permits; DPoP adds a cryptographic proof
     that the presenter holds the bound key.

     AATs encode the authorization itself.  The token specifies which
     tools may be invoked, with what argument constraints, and by which
     key holder.  Holders can derive tokens with authority equal to or
     narrower than their own, without contacting the authorization server.
     The PoP JWT in Section 5 serves a similar cryptographic role to a
     DPoP proof, binding a specific invocation to the leaf token's holder
     key, but operates in a different context.  Everything else in this
     specification (the chain model, the attenuation invariants, the
     constraint type registry, the subsumption matrix) addresses questions
     outside DPoP's scope.

     Structurally, DPoP is a two-party protocol between a client and a
     resource server.  There is no delegation model, no parent-child
     chain, and no attenuation invariant.  The chain model of this
     specification (del_depth, par_hash, del_max_depth, and the six
     attenuation invariants) has no DPoP analog.

     At the proof level, DPoP binds to an HTTP method (htm) and URI (htu).
     AAT PoP JWTs bind to a tool name (aat_tool) and a structured argument
     map (hta).  Tool invocations are function calls, not HTTP requests,
     and a URI alone carries insufficient information for argument-level
     constraint evaluation.  This is why aat_tool and hta differ
     structurally from htm and htu: (1) hta carries the full argument map
     required for constraint evaluation at the enforcement point; (2)
     aat_id binds the proof to a specific leaf token jti and chain
     position, for which DPoP has no equivalent.

     The cryptographic mechanism is the same: an asymmetric key in
     cnf.jwk, compact JWT serialization, verified against the leaf token's
     bound key.  DPoP could in principle be layered alongside AATs as a
     transport-level binding for chain delivery, but that combination is
     outside the scope of this specification.









  Niyikiza                Expires 17 September 2026              [Page 63]


  Internet-Draft          Attenuating Agent Tokens              March 2026


  A.4.  Biscuit

     Biscuit [BISCUIT] is a capability-based authorization token format
     that combines asymmetric public key signatures with offline
     attenuation, building on the Macaroons model.  Like AATs, Biscuit
     tokens support offline derivation and monotonic attenuation: a holder
     can produce a more restricted token without contacting the original
     issuer, and the resulting token cannot exceed the authority of its
     parent.

     The primary structural difference is the policy language.  Biscuit
     encodes authorization logic in a Datalog variant that is evaluated at
     verification time, requiring a logic engine at the enforcement point.
     This enables expressive relational policies but introduces a runtime
     dependency and non-trivial computational bounds to manage.

     AATs encode authorization as a structured capability map with typed
     argument constraints.  The core constraint types are decidable by
     structural analysis, requiring no logic engine.  For cases where
     structural constraints are insufficient, CEL expressions provide a
     bounded escape hatch, and a registered extension type mechanism
     supports domain-specific constraint types.  This tradeoff favors
     simplicity and predictability at the enforcement point, at the cost
     of the relational expressiveness Datalog provides.

     A second difference is scope.  Biscuit is a general-purpose
     authorization token format.  It does not natively encode token roles
     such as delegation versus execution authority, depth-limit claims, or
     explicit chain position declarations.  This specification defines a
     typed delegation-chain structure with those properties in the token
     model itself, making the chain independently verifiable as a
     delegation protocol rather than as a sequence of policy blocks.

  Appendix B.  Implementation Notes (Non-Normative)

  B.1.  Algorithm Recommendations

     *  *Signing algorithm:* Ed25519 [RFC8032].  The normative requirement
        is in Section 3.2.  EdDSA provides compact 64-byte signatures
        suitable for constrained agent environments.  The JWS alg header
        value for Ed25519 is "EdDSA".

     *  *Key representation:* JWK [RFC7517] with "kty": "OKP" and "crv":
        "Ed25519".

     *  *Token identifier:* UUIDv7 is recommended for jti values,
        providing time-ordered identifiers without central coordination.




  Niyikiza                Expires 17 September 2026              [Page 64]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     The algorithm allowlist requirement is normatively defined in
     Section 7 (steps 3a and 4a) and discussed in Section 8.14.

     Post-quantum migration: the cnf.jwk key type is not hardcoded to
     Ed25519.  Implementations should be designed to support key type
     migration.  NIST finalized ML-DSA (FIPS 204, formerly Dilithium) in
     2024 as a post-quantum digital signature standard.  Deployments with
     long-term security requirements should design their key management
     infrastructure to support algorithm migration without requiring
     changes to token structure.

  B.2.  Performance

     Chain verification requires one signature verification per chain
     link.  Ed25519 verification is computationally lightweight; for
     typical chain depths of 3 to 5 links, verification overhead is
     negligible relative to network latency in most deployment contexts.
     Constraint evaluation for exact, one_of, range, and similar
     structural types is O(n) in the number of constraints.  For regex and
     cel, evaluation cost depends on expression complexity and input size;
     see Section 8.7 for resource limit guidance.

  B.3.  Recognizing Derived Token iss Values in Middleware

     In both root and derived AATs, iss is a URI.  For root tokens it is a
     conventional issuer URI.  For derived tokens it is a JWK Thumbprint
     URI ([RFC9278]) with the urn:ietf:params:oauth:jwk-thumbprint:sha-
     256: prefix.  Middleware that routes or policy-evaluates based on iss
     should recognize the JWK Thumbprint URI scheme and apply chain-aware
     processing rather than attempting to resolve the URI as an issuer
     endpoint.  The verification key for derived tokens is parent.cnf.jwk,
     resolved from the preceding chain link.

  B.4.  Relationship to WIMSE

     The WIMSE architecture [WIMSE-ARCH] and service-to-service protocol
     [WIMSE-S2S] address workload identity and authentication for entities
     that hold and present AATs.  A WIMSE workload credential identifies
     an agent; the iss claim in a root AAT issued to that agent may
     reference the agent's WIMSE workload identifier.  The two
     specifications are complementary: WIMSE establishes workload identity
     and authentication; this specification defines a holder-derivable,
     invocation-scoped delegation and attenuation mechanism that WIMSE
     does not standardize.







  Niyikiza                Expires 17 September 2026              [Page 65]


  Internet-Draft          Attenuating Agent Tokens              March 2026


  B.5.  Delegation Depth Guidance

     The normative requirement is only that implementations enforce a
     finite MAX_DELEGATION_DEPTH.  This appendix provides non-normative
     guidance for selecting an appropriate value.

     The appropriate MAX_DELEGATION_DEPTH depends on the deployment
     topology.  Linear orchestration chains — root issuer, one or two
     planning layers, leaf executor — require few hops.  Swarm
     architectures with dynamic fan-out, sub-task delegation, or
     hierarchical agent groups may require significantly deeper chains.
     The implementation ceiling should reflect the maximum depth the
     deployment actually needs, not an arbitrary conservative default.

     Regardless of the implementation ceiling, issuers should set
     del_max_depth in individual tokens to the minimum depth the specific
     workflow requires.  A grant with a lower del_max_depth than the
     implementation ceiling is always permitted and limits blast radius if
     a token is misused.  The security value comes from tight per-chain
     policy, not from a low implementation ceiling.

  B.6.  Implementation Size Limits

     The normative requirement is only that implementations enforce finite
     limits on token size, chain size, constraint nesting depth, and tool
     count to prevent resource exhaustion.  This appendix provides non-
     normative recommended defaults for implementations with no specific
     deployment constraints:

          +==================================+=====================+
          | Parameter                        | Recommended Default |
          +==================================+=====================+
          | Maximum token size               | 64 KB               |
          +----------------------------------+---------------------+
          | Maximum chain size               | 256 KB              |
          +----------------------------------+---------------------+
          | Maximum tools per token          | 256                 |
          +----------------------------------+---------------------+
          | Maximum constraints per tool     | 64                  |
          +----------------------------------+---------------------+
          | Maximum constraint nesting depth | 32                  |
          +----------------------------------+---------------------+
          | Maximum tool name length         | 256 bytes           |
          +----------------------------------+---------------------+
          | Maximum constraint value length  | 4 KB                |
          +----------------------------------+---------------------+

                                   Table 10



  Niyikiza                Expires 17 September 2026              [Page 66]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     Deployments should document their enforced limits.  Interoperating
     parties should verify that their respective limits are compatible
     before deployment.

     Implementations should prefer exact and one_of constraints over
     pattern, regex, or cel where the policy permits, as these types
     produce significantly more compact tokens and simpler subsumption
     checks.

     Implementations concerned about parser exposure on unverified
     payloads in step 2c of the chain verification algorithm (Section 7)
     may extract jti using a length-limited byte scan rather than a full
     JSON parser, provided the extraction correctly handles JSON
     whitespace and string escaping.

     A single AAT is typically 1-4 KB when base64url-encoded.  Chains of
     two or more tokens will commonly exceed the 4-8 KB header size limits
     enforced by common reverse proxies and load balancers, resulting in
     431 errors.  Deployments should transmit AAT chains in a request body
     field rather than an HTTP header.  For size-constrained environments,
     the CBOR/CWT profile in Appendix D reduces chain size by 30-50% and
     is recommended when HTTP header transport is required.

  B.7.  Signed Passthrough Metadata

     Deployments may need to convey additional signed metadata through the
     delegation chain, such as a request trace identifier, a tenant
     context used for logging or routing, or a human-readable subject
     identifier.  This specification does not define a mechanism for such
     metadata, but the JWT format accommodates it naturally.

     Implementations may include additional JWT claims in AATs beyond
     those defined in Section 3.  Claims used for passthrough metadata
     should use collision-resistant names (e.g., reverse domain notation
     such as com.example.trace_id) and should not encode tool permissions
     or argument constraints that this specification models in
     authorization_details.














  Niyikiza                Expires 17 September 2026              [Page 67]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     Because additional claims are included in the token's JWS signature,
     they are integrity-protected within each individual token.  However,
     this specification's chain verification algorithm (Section 7) does
     not enforce preservation of unrecognized claims across derivation
     steps.  Per Section 3.4, enforcement points ignore unrecognized top-
     level JWT claims; the fail-closed rule applies only to constraint
     types within authorization_details.  A token carrying a
     com.example.trace_id claim will not be rejected solely for containing
     that claim.  Deployments that require chain-wide preservation of
     passthrough metadata must define and enforce their own derivation and
     verification rules for those claims, either through deployment-
     specific policy or in a companion profile.

  B.8.  TTL Guidance

     The normative requirement is only that derived tokens cannot outlive
     their parents and that token lifetime does not exceed
     MAX_TOKEN_LIFETIME (Section 4.4).  This appendix provides non-
     normative guidance for selecting appropriate TTL values.

     TTL is the primary revocation mechanism in this specification.  A
     token that has expired cannot be used regardless of whether a
     revocation list exists.  Short lifetimes reduce the window of
     exposure from key compromise, token theft, or scope misconfiguration.
     The operational cost of short TTLs is re-issuance frequency; this
     cost is low when the root issuer is available and derivation is
     offline.

     The appropriate TTL for each token role depends on the deployment
     context.  Root delegation tokens should be long enough to cover the
     full orchestration and execution window for the task, but no longer.
     Leaf execution tokens should be scoped to the expected duration of a
     single tool invocation.  Deployments with intermittent connectivity
     (edge, embedded, or air-gapped) may need longer lifetimes, with the
     awareness that longer lifetimes expand the compromise window.

     Deployments should treat TTL as a policy expression rather than a
     convenience parameter.  A root delegation token with a 24-hour TTL
     effectively grants the holder 24 hours of authority regardless of how
     narrowly the capability scope is defined.

  Appendix C.  Policy Languages with Decidable Containment (Non-Normative)

     This appendix provides non-normative guidance for implementers
     considering extension constraint types that use structured policy
     languages.





  Niyikiza                Expires 17 September 2026              [Page 68]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     The core constraint types regex and cel use conservative syntactic
     subsumption strategies because this specification does not define
     general containment algorithms for their respective languages.  This
     conservatism limits expressiveness: two semantically subsuming
     expressions that do not satisfy the syntactic criteria will be
     rejected by enforcement points applying the normative strategy, even
     if a human reviewer could determine that subsumption holds.

     Implementers requiring richer policy expressiveness without
     sacrificing subsumption decidability should consider languages that
     were designed specifically for authorization use cases and that
     provide formal containment algorithms as a first-class operation.
     Such languages are better positioned to provide conforming extension
     constraint registrations under Section 3.5.1, because their
     containment algorithms are decidable and formally verified rather
     than approximated by conservative syntactic rules.

     The key property to look for is whether the language's policy
     containment problem ("does every input permitted by policy A also
     satisfy policy B?") is decidable and implemented in available
     tooling.  Languages with this property allow a registration to
     specify a subsumption verification procedure that is both decidable
     and non-conservative: it returns true for all semantically subsuming
     pairs, not just syntactically obvious ones.

     This document takes no position on which specific policy language
     implementers should choose.  The choice depends on the deployment
     environment, existing infrastructure, tooling availability, and the
     specific authorization semantics required.  The normative requirement
     is only that whatever language is used, the resulting extension
     constraint registration satisfies the three properties defined in
     Section 3.5.1: decidable, sound, and deterministic.

  Appendix D.  CBOR/CWT Profile (Normative)

     The claim semantics, attenuation invariants, constraint subsumption
     rules, and chain verification algorithm defined in this document are
     format-agnostic.  They describe a protocol, not an encoding.  This
     appendix notes the relationship to CBOR-based token formats for
     implementers operating in constrained or throughput-sensitive
     environments.  The normative content of this appendix is limited to
     encoding constraints (deterministic CBOR per [RFC8949]); integer CWT
     claim key assignments are deferred to a companion document and are
     not normative here.







  Niyikiza                Expires 17 September 2026              [Page 69]


  Internet-Draft          Attenuating Agent Tokens              March 2026


  D.1.  CWT Representation

     CBOR Web Tokens [RFC8392] and COSE message signing [RFC9052] are the
     IETF-native binary analogs of JWT and JOSE respectively.  An AAT can
     be represented as a CWT with no change to its semantic content.  The
     attenuation invariants in Section 4 apply identically.  The chain
     verification algorithm in Section 7 applies identically, substituting
     COSE_Sign1 verification for JWS signature verification.

     CBOR encoding offers meaningful size advantages over base64url-
     encoded JSON for token payloads.  In typical AAT payloads with
     several constraint entries, CBOR encoding reduces token size by
     30-50% relative to compact JWT serialization.  For high-throughput
     agent pipelines or resource-constrained edge deployments, this
     difference is operationally significant.

  D.2.  Deterministic Encoding

     CWT implementations of this protocol MUST use deterministic CBOR
     encoding as defined in [RFC8949] Section 4.2.  Deterministic encoding
     requires that integer keys be used for all map entries where
     assignments exist, that map keys be sorted in length-first, bytewise
     lexicographic order, and that the shortest-form encoding be used for
     all values.  This ensures that two compliant implementations produce
     identical byte sequences for the same AAT payload, which is required
     for correct par_hash computation and cross-implementation chain
     verification.

     The hta map within a CWT PoP token MUST also use deterministic CBOR
     encoding.  Implementations MUST NOT use indefinite-length encoding
     for any AAT or PoP token structure.

  D.3.  Claim Key Assignments

     JWT uses string claim names.  CWT uses integer claim keys for
     registered claims to achieve compact encoding.  The AAT-specific
     claims defined in Sections 3 and 5 — namely aat_type, del_depth,
     del_max_depth, par_hash, aat_tool, hta, and aat_id — require integer
     key assignments in the IANA CWT Claims Registry [RFC8392] before a
     normative CWT profile can be published.

     Those registrations, along with COSE algorithm guidance and CWT-
     specific serialization rules, are deferred to a companion Internet-
     Draft.  That companion document will reference [RFC8392] and
     [RFC9052] normatively; this document references them informatively.
     This document makes no CWT claim key assignments.





  Niyikiza                Expires 17 September 2026              [Page 70]


  Internet-Draft          Attenuating Agent Tokens              March 2026


  D.4.  Companion Document

     A normative CWT profile is intended to be published as a companion
     Internet-Draft.  That document will define integer CWT claim key
     assignments for all AAT-specific claims, COSE algorithm requirements,
     and any CWT-specific serialization considerations.  The protocol
     defined in this document serves as the common specification that both
     profiles reference.

  Appendix E.  Implementation Status (Non-Normative)

     This appendix describes the implementation status of this
     specification at the time of submission, per the practice described
     in RFC 7942.

  E.1.  Reference Implementation

     A reference implementation of this protocol exists.  The chain
     verification algorithm (Section 7) and token derivation procedure
     (Section 6) are both implemented.  The implementation uses CBOR
     encoding for the wire format, with Ed25519 signatures carried in
     COSE_Sign1 structures, and demonstrates that the Section 7
     verification algorithm operates correctly over both JWT and CWT
     representations of the same chain, confirming format independence of
     the core protocol.

     RFC Editor Note: Implementation attribution will be updated or
     removed prior to WG adoption per IETF norms.

  E.2.  Formal Verification

     Formal verification of the attenuation algebra is in progress, using
     three complementary techniques: bounded model checking ([ALLOY]) for
     set-theoretic constraint types, SMT solving ([Z3]) for domain-
     specific types requiring arithmetic or string reasoning, and
     property-based testing against the Rust implementation for all
     constraint types.  Bounded model checking has found no
     counterexamples for scopes up to 8 constraints and 8 values.  The
     combination is intended to provide evidence toward monotonicity of
     the I4 invariant across the full constraint attenuation matrix.

     RFC Editor Note: Implementation details will be updated or removed
     per IETF norms prior to publication.

  Author's Address

     Niki Aimable Niyikiza
     Tenuo



  Niyikiza                Expires 17 September 2026              [Page 71]


  Internet-Draft          Attenuating Agent Tokens              March 2026


     Email: niki@tenuo.ai


















































  Niyikiza                Expires 17 September 2026              [Page 72]


name: draft-liu-agent-metadata-sync-protocol
rev: 00
title: Agent Metadata Synchronization Protocol
time: 2026-03-19T08:25:51Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-20T08:25:51Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent discovery/reg", "Autonomous netops", "Data formats/interop"]
tags: []
fetched_at: 2026-05-22T09:24:40.604526+00:00
source: ietf
abstract:
  The Internet of Agents (IoA) requires a robust infrastructure to
     manage the lifecycle, discovery, and interaction of autonomous agents
     across distributed network domains.  While the Agent Gateway (AGW)
     provides a localized control point, large-scale deployments
     necessitate a mechanism for multiple gateways to synchronize agent
     metadata and routing information.  This document specifies the Agent
     Metadata Synchronization Protocol (AMSP).  AMSP facilitates the
     exchange of Agent Records between hierarchical gateways (Level-1 and
     Level-2), ensuring global reachability, efficient resource
     utilization, and loop-free metadata propagation.

full_text:
  Network Working Group                                             B. Liu
  Internet-Draft                                       Huawei Technologies
  Intended status: Standards Track                                  M. Han
  Expires: 20 September 2026                                  China Unicom
                                                             19 March 2026


                  Agent Metadata Synchronization Protocol
                 draft-liu-agent-metadata-sync-protocol-00

  Abstract

     The Internet of Agents (IoA) requires a robust infrastructure to
     manage the lifecycle, discovery, and interaction of autonomous agents
     across distributed network domains.  While the Agent Gateway (AGW)
     provides a localized control point, large-scale deployments
     necessitate a mechanism for multiple gateways to synchronize agent
     metadata and routing information.  This document specifies the Agent
     Metadata Synchronization Protocol (AMSP).  AMSP facilitates the
     exchange of Agent Records between hierarchical gateways (Level-1 and
     Level-2), ensuring global reachability, efficient resource
     utilization, and loop-free metadata propagation.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 20 September 2026.

  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.



  Liu & Han               Expires 20 September 2026               [Page 1]


  Internet-Draft                    AMSP                        March 2026


     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     2.  Functional Requirements of Interaction between Agent
             Gateways  . . . . . . . . . . . . . . . . . . . . . . . .   3
       2.1.  Agent Gateway Discovery . . . . . . . . . . . . . . . . .   3
       2.2.  Metadata Synchronization  . . . . . . . . . . . . . . . .   4
       2.3.  Forwarding Table Forming for Agent Messages . . . . . . .   4
     3.  Gap Analysis of Current Approaches  . . . . . . . . . . . . .   4
       3.1.  Routing Protocols . . . . . . . . . . . . . . . . . . . .   4
       3.2.  Pub/Sub Protocols . . . . . . . . . . . . . . . . . . . .   5
     4.  Design Principles of AMSP . . . . . . . . . . . . . . . . . .   5
       4.1.  Protocol Layer  . . . . . . . . . . . . . . . . . . . . .   5
       4.2.  Agent Gateway Identification  . . . . . . . . . . . . . .   5
       4.3.  Gateway Hierarchy (Level-1, Level-2)  . . . . . . . . . .   6
       4.4.  Gateway Discovery . . . . . . . . . . . . . . . . . . . .   6
       4.5.  Synchronization mechanisms  . . . . . . . . . . . . . . .   7
         4.5.1.  Synchronization between Level-1 and Level-2
                 Gateways  . . . . . . . . . . . . . . . . . . . . . .   7
         4.5.2.  Synchronization between Level-2 Gateways  . . . . . .   7
         4.5.3.  Synchronization Policies  . . . . . . . . . . . . . .   8
       4.6.  Agent-specific Routing Table Forming  . . . . . . . . . .   9
     5.  Protocol Specification  . . . . . . . . . . . . . . . . . . .   9
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
       9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

  1.  Introduction

     The Internet of Agents (IoA) paradigm shifts communication from host-
     to-host towards dynamic, autonomous Agent-to-Agent interactions.  As
     discussed in [I-D.liu-rtgwg-agent-gateway-requirements], the
     introduction of Agent Gateways (AGWs) is crucial for addressing the
     scalability, security, and efficiency challenges inherent in large-
     scale, unmanaged Agent networks.  An Agent Gateway acts as a
     specialized intermediary that facilitates secure and efficient
     interaction between agents that either within a network domain or



  Liu & Han               Expires 20 September 2026               [Page 2]


  Internet-Draft                    AMSP                        March 2026


     across different network domains.

     A natural progression in this architecture is the deployment of
     multiple, possibly distributed, Agent Gateways.  For instance, an
     organization may deploy AGWs in different geographic locations,
     across various cloud environments, or to serve distinct business
     units to optimize for latency, locality, data sovereignty, or fault
     tolerance.  In such scenarios, while Agents interact with their local
     gateway, the gateways themselves must collaborate to enable seamless
     communication and service continuity across the entire multi-gateway
     infrastructure.

     This document specifies the Agent Metadata Synchronization Protocol
     (AMSP).  AMSP defines the mechanisms for interconnection between
     Agent Gateways, the procedures for efficient metadata exchange, and
     the underlying design principles.  By enabling a unified view of
     available agents across multiple gateway instances, AMSP ensures that
     the "Internet of Agents" (IoA) can scale effectively while
     maintaining robust governance and reachability.

  1.1.  Requirements Language

     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 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  2.  Functional Requirements of Interaction between Agent Gateways

     This sections discusses the high-level requirements of the
     interaction between agent gateways.  Gap analysis of current
     protocols and designing of AMSP is described in below scetions
     accordingly.

  2.1.  Agent Gateway Discovery

     For inter-gateway communication to be established, an Agent Gateway
     must first discover its peers.  This discovery process can be static
     (via configuration) or dynamic.  The protocol MUST support mechanisms
     for an AGW to discover and establish control sessions with other
     gateways, particularly in a hierarchical architecture where Level-1
     gateways need to locate their designated Level-2 gateway(s), and
     Level-2 gateways need to discover each other.  The discovery
     mechanism must be resilient and allow for network topology changes.






  Liu & Han               Expires 20 September 2026               [Page 3]


  Internet-Draft                    AMSP                        March 2026


  2.2.  Metadata Synchronization

     The core function of inter-gateway interaction is the synchronization
     of Agent metadata.  The primary metadata unit is the Agent Record.  A
     standardized format for this record, such as the AgentCard format
     [AgentCard], SHOULD be used to ensure interoperability.  The metadata
     to be synchronized includes, but is not limited to:

     *  Agent Identifier (Agent ID)

     *  Agent Capabilities/Skills

     *  Reachability Information (e.g., the URI of the gateway serving the
        Agent)

     *  Associated Security Policies and Trust Attributes

     The synchronization process MUST ensure that metadata is propagated
     efficiently and consistently across the inter-gateway network,
     respecting the defined hierarchy and any configured policies.

  2.3.  Forwarding Table Forming for Agent Messages

     Based on the synchronized Agent Records, particularly the Agent IDs,
     skills, and capabilities, each Agent Gateway MUST be able to
     construct and maintain a logical forwarding table.  This table maps a
     target Agent ID/skill to the next-hop gateway (or directly to the
     Agent, if local) for the purpose of routing application-layer Agent
     messages.  The formation of this table is a direct outcome of the
     metadata synchronization process and is fundamental to enabling
     inter-domain Agent communication.

  3.  Gap Analysis of Current Approaches

     An examination of existing protocols reveals that they are not fully
     suited to meet the specific requirements of inter-gateway Agent
     metadata exchange.

  3.1.  Routing Protocols

     Traditional routing protocols (e.g., BGP, OSPF, IS-IS) are designed
     to exchange network-layer reachability information (IP prefixes).
     They operate on network and transport layer identifiers and are not
     equipped to handle the semantics of application-layer entities like
     Agents.  They lack the ability to carry and process rich, variable-
     length metadata such as capability descriptions, skill sets, or
     application-specific security policies.  Extending these protocols to
     support such data would be complex and would deviate from their core



  Liu & Han               Expires 20 September 2026               [Page 4]


  Internet-Draft                    AMSP                        March 2026


     design principles.

     Furthermore, the high churn rate of Agents would lead to excessive
     route flapping if mapped directly to traditional routing tables.

  3.2.  Pub/Sub Protocols

     General-purpose publish/subscribe protocols (e.g., MQTT, XMPP) are
     efficient for distributing messages based on topics.  However, they
     are typically designed for data distribution rather than state
     synchronization with strong consistency and routing table computation
     requirements.  They often lack built-in mechanisms for loop
     prevention, policy-based filtering on the publisher side, and the
     construction of a forwarding state that maps identifiers to next
     hops.  And they typically require a centralized broker or a flat
     cluster, which does not align with the hierarchical and decentralized
     nature of cross-domain IoA deployments.

     While a Pub/Sub model could be a component of the AMSP, it alone does
     not fulfill the complete set of requirements for a routing and
     synchronization protocol between gateways.

  4.  Design Principles of AMSP

     To address the identified gaps and requirements, the Agent Metadata
     Synchronization Protocol (AMSP) is designed according to the
     following principles.

  4.1.  Protocol Layer

     AMSP is designed as an application-layer (Layer 7) protocol.  It is
     intended to operate on top of reliable transport protocols.  The
     initial specification will define bindings to two common application
     frameworks:

     *  JSON + HTTP

     *  gRPC + HTTP

     This approach leverages widely adopted web technologies, facilitating
     implementation, debugging, and integration with existing network
     services and orchestration platforms.

  4.2.  Agent Gateway Identification

     An Agent Gateway participating in AMSP MUST be uniquely identifiable.
     Two primary methods are supported:




  Liu & Han               Expires 20 September 2026               [Page 5]


  Internet-Draft                    AMSP                        March 2026


     *  IP Address + Port: A gateway can be identified by its IP address
        and a designated AMSP service port.  This is a straightforward
        method suitable for many deployments.

     *  Uniform Resource Identifier (URI): A gateway can be identified by
        a URL (e.g., https://gw1.example.io/amsp).  This method offers
        greater flexibility, enabling the use of DNS for addressing, load
        balancing, and the colocation of AMSP services.

  4.3.  Gateway Hierarchy (Level-1, Level-2)

     To ensure scalability and operational efficiency, AMSP defines a two-
     level hierarchical model for gateway interconnection:

     *  Level-1 Gateway (L1 AGW): These gateways are deployed closer to
        the edge, serving specific localities such as a campus, a data
        center, or a broadband access network (BRAS).  A Level-1 gateway
        maintains Agent Records only for the Agents directly connected to
        or registered with it.  It discovers and connects to its
        designated Level-2 gateway(s) to report local records and to query
        or subscribe to records for Agents outside its local domain.

     *  Level-2 Gateway (L2 AGW): These are core nodes that maintain a
        global or regional view of Agent metadata.  A Level-2gateway could
        be operated by a network provider, a large enterprise, or a major
        Agent service provider.  Level-2 gateways maintain the full set of
        Agent Records for their domain and are responsible for
        synchronizing this full view with other Level-2 gateways.  The
        addresses (IP/port or URL) of Level-2 gateways can be publicly
        advertised (similar to public DNS servers) or privately disclosed
        to authorized Level-1 gateways.

     This hierarchical structure provides two key advantages:

     *  Improved Convergence: Full-mesh synchronization of all records is
        confined to a smaller set of Level-2 gateways, enhancing overall
        synchronization speed and stability.

     *  Reduced State at the Edge: Level-1 gateways only need to store
        local records and a subset of remote records that are actively
        being used (via subscription), significantly reducing their memory
        and processing requirements.

  4.4.  Gateway Discovery

     The discovery process follows the established hierarchy.





  Liu & Han               Expires 20 September 2026               [Page 6]


  Internet-Draft                    AMSP                        March 2026


     *  Level-1 Discovers Level-2 Gateway: A Level-1 gateway is
        configured, either manually or via automated mechanisms (e.g.,
        DHCP options, anycast), with the address of its upstream Level-2
        gateway(s).  It then initiates a connection to this Level-2
        gateway to establish an AMSP peering session.

     *  Level-2 Gateway Inter-Discovery: Level-2 gateways are typically
        configured with the addresses of their peers (neighboring Level-2
        gateways).  This configuration can be done manually by an operator
        or through a controller or orchestration system.  Once configured,
        Level-2 gateways establish AMSP sessions with their peers to
        facilitate full-mesh or partial-mesh synchronization of the global
        metadata set.

  4.5.  Synchronization mechanisms

     The synchronization of Agent Records is the core function of AMSP.
     The mechanisms are defined separately for the two levels of the
     hierarchy.  Per current common practise, an Agent Record is estimated
     to be between 5-12 KB in size.  For example, storing records for 1
     million Agents would therefore require approximately 12GB of storage,
     which is feasible for a Level-2 gateway.

  4.5.1.  Synchronization between Level-1 and Level-2 Gateways

     The interaction between a Level-1 and its Level-2 gateway follows a
     hybrid push-and-pull model.

      1) Local Registration and Upstream Push: When an Agent registers with its local Level-1 gateway, the gateway stores the Agent's Record locally.  It then immediately pushes this record to its connected Level-2 gateway(s).  This ensures the upper layer has an up-to-date view of all edge Agents.

      2) On-Demand Subscription from Level-1: When a Level-1 gateway receives a resolution request from a local Agent (e.g., a natural language query to find Agents with a specific capability), it first checks its local cache.  If the required information is not present, it sends a subscription request to its Level-2 gateway for the relevant topic or capability.  This is a pull-based, on-demand mechanism.

      3) Targeted Push from Level-2: The Level-2 gateway, upon receiving a subscription, pushes the relevant Agent Records to the requesting Level-1 gateway.  This ensures that the edge gateway only receives the metadata it actually needs.

      4) Update Propagation: If an Agent Record changes (e.g., an Agent goes offline or its capabilities are updated), the change is first pushed from the Level-1 to the Level-2 gateway. The Level-2 gateway then propagates this update to all Level-1 gateways that have subscribed to that specific record or its topic. It also propagates the update to other Level-2 gateways.

      5) Subscription Cleanup: To manage resources, a Level-1 gateway MAY unsubscribe from a topic or a set of records if they have not been used for a defined period.

  4.5.2.  Synchronization between Level-2 Gateways

     Synchronization among Level-2 gateways aims to maintain a consistent
     global view.  This process requires robust loop-prevention
     mechanisms, drawing inspiration from path-vector protocols like BGP.

  *  Full State Synchronization: Level-2 gateways exchange complete
     views of their Agent Record database upon session establishment.
     Subsequently, only incremental updates (changes) are propagated.




  Liu & Han               Expires 20 September 2026               [Page 7]


  Internet-Draft                    AMSP                        March 2026


  *  Loop Prevention Mechanisms:

    -- Source Pruning (Split Horizon): When a Level-2 gateway sends records to its peers, it MUST implement a form of source pruning. Records received from a specific neighbor are not transmitted back to that same neighbor. This is analogous to maintaining a separate Routing Information Base (RIB) per peer.

    -- PATH Attribute: Each update message for an Agent Record MUST carry a PATH attribute.  This attribute is an ordered list of the URIs of the Level-2 gateways through which the record update has passed.

            a) When a gateway sends an update, it prepends its own URI to the PATH attribute.

            b) Upon receiving an update, a gateway checks the PATH attribute.  If its own URI is already present in the PATH, the update is silently discarded to prevent a loop.

            c) If a gateway receives multiple updates for the same Agent Record from different paths, it SHOULD select the update with the shortest PATH length (i.e., the one that has traversed the fewest Level-2 gateways) as the best path. This helps in selecting the most direct path to the originating gateway.

  4.5.3.  Synchronization Policies

     The protocol should be flexible enough to support different policy
     models for controlling the flow of metadata.  Several approaches are
     possible:

  *  Send-Filter Policy: In this model, the sending gateway applies
     filters to determine which records to transmit to which neighbors.

    -- Advantage: Allows for strong policy control at the source, which is useful in scenarios with strict data governance.

    -- Disadvantage: May result in the transmission of many records that are not of interest to the receiver, leading to bandwidth waste as the receiver drops them.

    -- Use Case: Suitable for more controlled environments where outbound policy is paramount.

  *  Pub/Sub Model: The receiving gateways explicitly subscribe to the
     topics or specific records they are interested in.  The sending
     gateway only publishes updates related to those active
     subscriptions.

    -- Advantage: Highly efficient, as data is only sent where it is needed.  This model is receiver-driven.

    -- Disadvantage: It is more complex to implement, requiring the management of subscription state.  It may offer less fine-grained control to the publisher over what is being sent.

    -- Use Case: Well-suited for open, large-scale discovery scenarios where edge gateways only want relevant information.

  *  Hybrid Model: A combination of both approaches.  A sending gateway
     can have its own export policies, while also respecting
     subscriptions from its neighbors.  This offers maximum
     flexibility.

    -- Advantage: Combines the policy control of the send-filter model with the efficiency of the pub/sub model.

    -- Disadvantage: Results in the most complex implementation, requiring both policy engines and subscription state management.

    -- Use Case: Complex operational environments where both publisher control and receiver efficiency are required.



  Liu & Han               Expires 20 September 2026               [Page 8]


  Internet-Draft                    AMSP                        March 2026


     AMSP SHOULD be designed to accommodate all three models, allowing
     implementations and deployments to choose the most appropriate
     mechanism.

  4.6.  Agent-specific Routing Table Forming

     The synchronization of metadata directly leads to the formation of
     application-layer routing tables on each gateway.  This process is
     illustrated with a simple example.

     Consider a network with three Agent Gateways: GW1, GW2, and GW3.  GW2
     is a Level-2 gateway, while GW1 and GW3 are Level-1 gateways
     connected to GW2.  Agent2 is directly connected to GW2, and Agent1 is
     connected to GW1.

     1) Record Synchronization and Forwarding Table Generation:

      - Agent2 registers with its local gateway, GW2. GW2 stores Agent2's Record locally. It then generates a local forwarding table entry indicating a direct connection to Agent2: `<Agent ID2, Interface/Connection to Agent2>`.

      - GW2, acting as a Level-2 gateway, synchronizes Agent2's Record to its neighbor, GW3.  The synchronization message includes the Agent Record and a PATH attribute containing GW2's URI.

      - GW3 receives the Record for Agent2, stores it, and installs a forwarding table entry pointing to GW2 as the next hop: `<Agent ID2, Connection to GW2>`.

      - GW3 further synchronizes the Record to its neighbor, GW1, appending its own URI to the PATH attribute (PATH: GW3 -> GW2).

      - GW1 receives the Record for Agent2.  It stores the Record and installs a forwarding table entry pointing to GW3 as the next hop for Agent2: `<Agent ID2, Connection to GW3>`.

     2) Data Plane Forwarding:

      - Agent1 sends a request to its local gateway, GW1, to resolve a target, Agent2.  GW1's semantic resolution process matches the request to Agent2's Record and returns a response to Agent1. In this response, the reachability URI for Agent2 can be replaced with GW1's own URI to simplify routing for the Agent.

      - Agent1 establishes a data connection to the provided URI (which points to GW1) and sends its message for Agent2.

      - GW1 receives the message.  It examines the destination Agent ID (Agent2) and looks up its application-layer forwarding table. The table entry `<Agent ID2, Connection to GW3>` instructs GW1 to forward the message to GW3.

      - GW3 receives the message, performs its own forwarding table lookup, and forwards the message to GW2 based on its entry`<Agent ID2, Connection to GW2>`.

      - GW2 receives the message, looks up its table, and delivers the message directly to Agent2. The complete forwarding path is: `Agent1 --> GW1 --> GW3 --> GW2 --> Agent2`.

     This example demonstrates how AMSP's control plane (metadata sync)
     automatically builds the necessary state for the data plane
     (application-layer message forwarding) across multiple gateways.

  5.  Protocol Specification

     TBD.





  Liu & Han               Expires 20 September 2026               [Page 9]


  Internet-Draft                    AMSP                        March 2026


  6.  Security Considerations

     Authentication: All AGW peering MUST be authenticated using
     mechanisms such as TLS certificates or pre-shared keys.

     Integrity: Sync messages SHOULD be signed to prevent tampering with
     Agent URIs or PATH attributes.

     Privacy: Agent Records may contain sensitive metadata.  AGWs SHOULD
     support attribute-level encryption or policy-based redaction during
     synchronization between domains.

     DDoS Mitigation: L2 AGWs SHOULD implement rate-limiting for
     subscriptions from L1 AGWs to prevent resource exhaustion attacks.

  7.  IANA Considerations

     TBD.

  8.  Acknowledgements

     TBD

  9.  References

  9.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/info/rfc2119>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/info/rfc8174>.

  9.2.  Informative References

     [I-D.liu-rtgwg-agent-gateway-requirements]
                Liu, B., Geng, N., Shang, X., Gao, Q., Li, Z., and J. Gao,
                "Requirements for Agent Gateway", Work in Progress,
                Internet-Draft, draft-liu-rtgwg-agent-gateway-
                requirements-01, 27 November 2025,
                <https://datatracker.ietf.org/doc/html/draft-liu-rtgwg-
                agent-gateway-requirements-01>.






  Liu & Han               Expires 20 September 2026              [Page 10]


  Internet-Draft                    AMSP                        March 2026


     [AgentCard]
                "Agent2Agent (A2A) Protocol Specification (Release
                Candidate v1.0)", 5 March 2026,
                <https://github.com/a2aproject/A2A/blob/main/docs/
                specification.md#5-agent-discovery-the-agent-card>.

  Authors' Addresses

     Bing Liu
     Huawei Technologies
     No. 156 Beiqing Road
     Beijing
     China
     Email: leo.liubing@huawei.com


     Mengyao Han
     China Unicom
     No. 9 Shouti South Road
     Beijing
     China
     Email: hanmy12@chinaunicom.cn





























  Liu & Han               Expires 20 September 2026              [Page 11]


name: draft-hood-agtp-agent-cert
rev: 00
title: AGTP Agent Certificate Extension
time: 2026-03-23T16:37:48Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-24T16:37:48Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "A2A protocols"]
tags: []
fetched_at: 2026-05-22T09:24:41.698215+00:00
source: ietf
abstract:
  The Agent Transfer Protocol (AGTP) base specification defines agent
     identity headers (Agent-ID, Principal-ID, Authority-Scope) that are
     self-asserted: present on every request and mandatory for logging,
     but not cryptographically verified at the transport layer.  This
     document specifies the AGTP Agent Certificate Extension: an optional
     mechanism that binds Agent-ID, Principal-ID, and Authority-Scope to
     an X.509 v3 certificate presented during TLS mutual authentication.
     The extension enables infrastructure components including Scope-
     Enforcement Points (SEPs), load balancers, and governance gateways to
     verify agent identity and enforce authority scope without
     application-layer access, at O(1) cost per request header check.  The
     extension also defines session-level revocation propagation via AGTP
     NOTIFY broadcast and a Certificate Transparency Log for tamper-
     evident governance metadata.

     Note: Certain mechanisms described in this document may be subject to
     pending patent applications by the author.  The licensor is prepared
     to grant a royalty-free license to implementers consistent with the
     IETF's IPR framework.  See the IPR Notice and Section 7.

full_text:
  Independent Submission                                           C. Hood
  Internet-Draft                                             Nomotic, Inc.
  Intended status: Informational                             23 March 2026
  Expires: 24 September 2026


                      AGTP Agent Certificate Extension
                       draft-hood-agtp-agent-cert-00

  Abstract

     The Agent Transfer Protocol (AGTP) base specification defines agent
     identity headers (Agent-ID, Principal-ID, Authority-Scope) that are
     self-asserted: present on every request and mandatory for logging,
     but not cryptographically verified at the transport layer.  This
     document specifies the AGTP Agent Certificate Extension: an optional
     mechanism that binds Agent-ID, Principal-ID, and Authority-Scope to
     an X.509 v3 certificate presented during TLS mutual authentication.
     The extension enables infrastructure components including Scope-
     Enforcement Points (SEPs), load balancers, and governance gateways to
     verify agent identity and enforce authority scope without
     application-layer access, at O(1) cost per request header check.  The
     extension also defines session-level revocation propagation via AGTP
     NOTIFY broadcast and a Certificate Transparency Log for tamper-
     evident governance metadata.

     Note: Certain mechanisms described in this document may be subject to
     pending patent applications by the author.  The licensor is prepared
     to grant a royalty-free license to implementers consistent with the
     IETF's IPR framework.  See the IPR Notice and Section 7.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 24 September 2026.




  Hood                    Expires 24 September 2026               [Page 1]


  Internet-Draft                  AGTP-CERT                     March 2026


  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  The Identity Gap in Base AGTP . . . . . . . . . . . . . .   3
       1.2.  The Agent Certificate Extension . . . . . . . . . . . . .   3
       1.3.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  AGTP Agent Certificate Schema . . . . . . . . . . . . . . . .   4
       3.1.  Certificate Structure . . . . . . . . . . . . . . . . . .   4
         3.1.1.  Standard Subject Fields . . . . . . . . . . . . . . .   5
         3.1.2.  Agent-Governance X.509 v3 Extensions  . . . . . . . .   5
     4.  Certificate Issuance Protocol . . . . . . . . . . . . . . . .   6
       4.1.  Eligibility . . . . . . . . . . . . . . . . . . . . . . .   6
       4.2.  Issuance Steps  . . . . . . . . . . . . . . . . . . . . .   6
       4.3.  Certificate Validity  . . . . . . . . . . . . . . . . . .   7
     5.  TLS Integration . . . . . . . . . . . . . . . . . . . . . . .   7
       5.1.  Mutual Authentication . . . . . . . . . . . . . . . . . .   7
       5.2.  Scope Enforcement at SEPs . . . . . . . . . . . . . . . .   7
     6.  Revocation and Session Propagation  . . . . . . . . . . . . .   8
       6.1.  Revocation Events . . . . . . . . . . . . . . . . . . . .   8
       6.2.  Session-Level Revocation Propagation  . . . . . . . . . .   8
       6.3.  Session Manager Responsibilities  . . . . . . . . . . . .   9
     7.  AGTP Certificate Transparency Log . . . . . . . . . . . . . .   9
       7.1.  Purpose . . . . . . . . . . . . . . . . . . . . . . . . .   9
       7.2.  Log Structure . . . . . . . . . . . . . . . . . . . . . .  10
       7.3.  Privacy Considerations  . . . . . . . . . . . . . . . . .  10
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
       8.1.  Certificate Pinning . . . . . . . . . . . . . . . . . . .  11
       8.2.  Scope Commitment Forgery  . . . . . . . . . . . . . . . .  11
       8.3.  Cross-Certificate Confusion . . . . . . . . . . . . . . .  11
       8.4.  IPR Notice  . . . . . . . . . . . . . . . . . . . . . . .  11
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
       9.1.  X.509 Extension OID Registrations . . . . . . . . . . . .  11
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
       10.1.  Normative References . . . . . . . . . . . . . . . . . .  12
       10.2.  Informative References . . . . . . . . . . . . . . . . .  13
     Appendix A.  Relationship to Birth Certificate  . . . . . . . . .  13



  Hood                    Expires 24 September 2026               [Page 2]


  Internet-Draft                  AGTP-CERT                     March 2026


     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  14

  1.  Introduction

  1.1.  The Identity Gap in Base AGTP

     The AGTP base specification requires every request to carry Agent-ID,
     Principal-ID, and Authority-Scope headers.  These headers are self-
     asserted: an AGTP client declares its identity and scope, and the
     server logs the declaration.  In the base spec, there is no
     transport-layer mechanism to verify that the declared Agent-ID
     corresponds to a registered agent, that the Principal-ID is accurate,
     or that the Authority-Scope does not exceed what was granted.

     This is a deliberate design choice in the core spec: self-asserted
     identity with mandatory logging provides a useful baseline and
     enables broad adoption.  For many deployments, anomaly detection and
     audit trails over self-asserted headers are sufficient.

     For higher-stakes deployments -- financial transactions, healthcare
     operations, legal actions, multi-organization agent federations --
     the self-assertion model is insufficient.  Infrastructure needs to
     verify agent identity and enforce scope at the transport layer
     without parsing application payloads.

  1.2.  The Agent Certificate Extension

     The AGTP Agent Certificate Extension provides cryptographic identity
     binding at the transport layer.  An AGTP Agent Certificate is an
     X.509 v3 certificate with agent-governance-specific extensions.  It
     is presented during TLS mutual authentication, enabling the server
     and any AGTP-aware infrastructure component to verify the agent's
     identity and authority scope from the certificate alone, without
     inspecting the request headers or body.

     This document specifies:

     *  The AGTP Agent Certificate schema and X.509 v3 extension fields

     *  The certificate issuance and renewal protocol

     *  The authority scope commitment mechanism for O(1) per-request
        scope enforcement

     *  Session-level revocation propagation via AGTP NOTIFY

     *  The AGTP Certificate Transparency Log (AGTP-CTL)




  Hood                    Expires 24 September 2026               [Page 3]


  Internet-Draft                  AGTP-CERT                     March 2026


  1.3.  Scope

     This extension is OPTIONAL.  Core AGTP implementations that do not
     implement this extension remain fully compliant with [AGTP].  The
     extension is required only for Trust Tier 1 agent identity
     verification and for SEP-enforced scope constraint without
     application-layer access.

  2.  Terminology

     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 [RFC2119] [RFC8174] when, and only
     when, they appear in all capitals.

     AGTP Agent Certificate:  An X.509 v3 certificate carrying agent-
        governance-specific extensions, presented during TLS mutual
        authentication to establish cryptographic agent identity and
        authority scope at the transport layer.

     Scope-Enforcement Point (SEP):  An AGTP-aware infrastructure
        component that enforces Authority-Scope constraints on AGTP
        requests.  With the Agent Certificate Extension, SEPs verify scope
        from the certificate at O(1) cost per request without application-
        layer access.

     Authority-Scope Commitment:  A cryptographic binding of the agent's
        declared Authority-Scope tokens to the Agent Certificate, enabling
        SEPs to verify scope token membership after a single session-
        establishment signature verification.

     AGTP Certificate Transparency Log (AGTP-CTL):  A Merkle-tree-based
        append-only log of issued AGTP Agent Certificates, providing
        tamper-evident public accountability for certificate issuance and
        revocation.

  3.  AGTP Agent Certificate Schema

  3.1.  Certificate Structure

     The AGTP Agent Certificate is an X.509 v3 certificate per [RFC5280]
     with the following subject fields and extensions:








  Hood                    Expires 24 September 2026               [Page 4]


  Internet-Draft                  AGTP-CERT                     March 2026


  3.1.1.  Standard Subject Fields

        +====================+==========+============================+
        | Field              | Required | Value                      |
        +====================+==========+============================+
        | CN (Common Name)   | *MUST*   | Human-readable agent label |
        +--------------------+----------+----------------------------+
        | O (Organization)   | *MUST*   | Organization name (maps to |
        |                    |          | principal_org)             |
        +--------------------+----------+----------------------------+
        | OU (Organizational | *MAY*    | Governance zone identifier |
        | Unit)              |          |                            |
        +--------------------+----------+----------------------------+
        | emailAddress       | *SHOULD* | Contact email of the       |
        |                    |          | responsible principal      |
        +--------------------+----------+----------------------------+

                Table 1: AGTP Agent Certificate Subject Fields

  3.1.2.  Agent-Governance X.509 v3 Extensions

     The following extensions are defined for AGTP Agent Certificates.
     OIDs for these extensions are specified in Section 8 (IANA
     Considerations).

     *subject-agent-id* (CRITICAL)  The canonical AGTP Agent-ID derived
        from the governance-layer Birth Certificate's certificate_hash.
        This is the transport-layer Agent-ID used in the AGTP Agent-ID
        header.  Format: hex-encoded 256-bit value.

     *principal-id* (CRITICAL)  The identifier of the human principal
        accountable for this agent's actions.  Maps to the AGTP Principal-
        ID header.  Format: UTF-8 string, maximum 256 characters.

     *authority-scope-commitment* (CRITICAL)  A cryptographic commitment
        to the agent's Authority-Scope token set, enabling SEPs to verify
        token membership without storing the full scope list per session.
        The commitment is computed as an Ed25519 signature over the
        canonical lexicographically sorted Authority-Scope token set.
        SEPs verify token membership by checking the token against the
        commitment after session-establishment signature verification.

     *governance-zone* (NON-CRITICAL)  The governance zone identifier in
        which the agent is registered.  Format: UTF-8 string following the
        zone: prefix convention.

     *trust-tier* (NON-CRITICAL)  The agent's Trust Tier (1, 2, or 3) as
        defined in [AGTP] Section 6.2.  Format: INTEGER.



  Hood                    Expires 24 September 2026               [Page 5]


  Internet-Draft                  AGTP-CERT                     March 2026


     *archetype* (NON-CRITICAL)  The agent's behavioral archetype as
        defined in [AGTP] Section 6.7.3.  Format: UTF-8 string; one of:
        assistant, analyst, executor, orchestrator, monitor.

     *activation-certificate-id* (NON-CRITICAL)  Cross-layer reference to
        the governance-layer Birth Certificate certificate_hash.  Enables
        audit reconstruction without a cryptographic dependency between
        the transport certificate and the governance certificate.  Format:
        hex-encoded 256-bit value.

     *agtp-ctl-sct* (NON-CRITICAL)  Signed Certificate Timestamp from the
        AGTP Certificate Transparency Log, proving the certificate was
        submitted to the AGTP-CTL before delivery.  Format: SCT structure
        per [RFC6962] Section 3.2.

  4.  Certificate Issuance Protocol

  4.1.  Eligibility

     Certificate Signing Requests (CSRs) for AGTP Agent Certificates
     *MUST* only be accepted for agents in Active lifecycle state in the
     AGTP registry.  A governance platform *MUST* verify the agent's
     lifecycle state at CSR submission time and *MUST* reject CSRs for
     agents in Suspended, Revoked, or Deprecated state.

  4.2.  Issuance Steps

     1.  The governance platform generates a key pair for the agent (or
         accepts a CSR with an agent-generated key pair).

     2.  The governance platform populates the certificate subject fields
         and all AGTP-specific extensions from the agent's Birth
         Certificate and registry record.

     3.  The governance platform verifies that the proposed authority-
         scope- commitment does not exceed the scope granted in the
         agent's Birth Certificate.  If it does, the CSR *MUST* be
         rejected.

     4.  The governance platform signs the certificate using its issuing
         CA key per [RFC5280].

     5.  The governance platform submits the certificate to the AGTP-CTL
         and obtains a Signed Certificate Timestamp (SCT).

     6.  The SCT is embedded in the agtp-ctl-sct extension and the
         certificate is delivered to the agent.




  Hood                    Expires 24 September 2026               [Page 6]


  Internet-Draft                  AGTP-CERT                     March 2026


     7.  The governance platform publishes the new certificate to the
         agent's registry record, triggering a registry state update.

  4.3.  Certificate Validity

     AGTP Agent Certificates *SHOULD* have a validity period of no more
     than 90 days.  Short validity periods limit the exposure window of a
     compromised certificate and reduce reliance on revocation mechanisms.
     Renewal *SHOULD* begin at 80% of the validity period.

     Certificate renewal carries forward the predecessor's subject-agent-
     id and activation-certificate-id unchanged.  The renewed certificate
     receives a new serial number, new validity period, and a new SCT.

  5.  TLS Integration

  5.1.  Mutual Authentication

     AGTP connections using the Agent Certificate Extension *MUST* use TLS
     1.3 mutual authentication.  The agent presents its AGTP Agent
     Certificate as the client certificate during the TLS handshake.

     The server verifies the client certificate chain against the issuing
     CA trust anchors.  Following successful handshake:

     1.  The server extracts the subject-agent-id extension value and
         verifies it matches the Agent-ID header on the first request.

     2.  The server extracts the principal-id extension value and verifies
         it matches the Principal-ID header on the first request.

     3.  The server extracts the authority-scope-commitment extension
         value and uses it to verify Authority-Scope header tokens on each
         request.

     Any mismatch between certificate extension values and AGTP header
     values *MUST* cause the server to return 401 Unauthorized and *MUST*
     be logged.

  5.2.  Scope Enforcement at SEPs

     A SEP operating with the Agent Certificate Extension verifies
     Authority- Scope at O(1) cost per request:

     1.  At session establishment, the SEP extracts the authority-scope-
         commitment from the client certificate.  (One-time per session.)





  Hood                    Expires 24 September 2026               [Page 7]


  Internet-Draft                  AGTP-CERT                     March 2026


     2.  On each request, the SEP checks whether the Authority-Scope
         header tokens are covered by the commitment.  (O(1) per request
         after session setup.)

     3.  If any header token is not covered by the commitment, the SEP
         returns 451 Scope Violation without forwarding the request to the
         application layer.

     This enables governance enforcement at line rate without application-
     layer parsing.

  6.  Revocation and Session Propagation

  6.1.  Revocation Events

     An AGTP Agent Certificate *MUST* be revoked when any of the following
     occur:

     *  The agent's lifecycle state transitions to Revoked or Deprecated

     *  The Birth Certificate's certificate_hash is invalidated

     *  The agent's authority-scope-commitment requires modification

     *  The principal requests revocation

     *  A trust violation is detected

  6.2.  Session-Level Revocation Propagation

     Standard certificate revocation (CRL, OCSP) operates on polling
     cycles, leaving a window during which revoked certificates may still
     be used.  For agent systems, this window is unacceptable for high-
     stakes operations.

     AGTP Agent Certificate revocation *MUST* be propagated to active
     sessions via AGTP NOTIFY broadcast:

     1.  The governance platform issues a revocation event to the AGTP-
         CTL.

     2.  The governance platform broadcasts an AGTP NOTIFY to all
         infrastructure components holding active sessions for the revoked
         certificate's subject-agent-id:







  Hood                    Expires 24 September 2026               [Page 8]


  Internet-Draft                  AGTP-CERT                     March 2026


     {
       "method": "NOTIFY",
       "parameters": {
         "recipient": "infrastructure:broadcast",
         "content": {
           "event_type": "certificate_revoked",
           "subject_agent_id": "[agent-id]",
           "certificate_serial": "[serial]",
           "revocation_reason": "[reason]",
           "effective_at": "2026-04-01T00:00:00Z"
         },
         "urgency": "critical"
       }
     }

     1.  Infrastructure components receiving this NOTIFY *MUST*
         immediately terminate all active sessions for the identified
         subject-agent-id.  Session termination *MUST* occur before the
         next request is processed on the affected session.

     2.  The target revocation-to-termination latency is 30 seconds.  This
         is materially shorter than standard CRL or OCSP cache-based
         models.

  6.3.  Session Manager Responsibilities

     AGTP Session Managers in deployments using the Agent Certificate
     Extension *MUST* maintain a per-certificate-serial active session
     registry.  On receiving a revocation NOTIFY, the Session Manager
     *MUST* terminate all sessions associated with the revoked serial
     before processing the next request on any affected session.

  7.  AGTP Certificate Transparency Log

  7.1.  Purpose

     The AGTP Certificate Transparency Log (AGTP-CTL) is an append-only,
     Merkle-tree-based log of all issued AGTP Agent Certificates.  It
     provides tamper-evident public accountability for certificate
     issuance and revocation, enabling:

     *  Fleet-level analytics: population-wide trust score distributions,
        archetype frequencies, governance zone composition

     *  Anomaly detection: detection of certificates issued outside normal
        governance flows





  Hood                    Expires 24 September 2026               [Page 9]


  Internet-Draft                  AGTP-CERT                     March 2026


     *  Audit reconstruction: verifiable history of certificate issuance
        and revocation for compliance

  7.2.  Log Structure

     The AGTP-CTL follows the Certificate Transparency log structure
     defined in [RFC6962], adapted for agent governance metadata.  Each
     leaf entry contains:

     *  Certificate serial number

     *  subject-agent-id

     *  principal-id

     *  governance-zone

     *  trust-tier

     *  archetype

     *  activation-certificate-id

     *  Issuance timestamp

     *  Revocation status (updated on revocation)

     *  Merkle leaf hash

     The leaf hash covers all governance metadata fields.  Any
     modification to a log entry is detectable by any party with access to
     the log.

  7.3.  Privacy Considerations

     The principal-id field in the AGTP-CTL leaf entries *MAY* be
     pseudonymized to protect individual principal identity while
     maintaining audit integrity.  Pseudonymous principal IDs *MUST* be
     resolvable by authorized parties (regulators, compliance auditors)
     via a trusted resolution service.  The pseudonymization mapping
     *MUST* be maintained separately from the _*RECOMMENDED_ public log.

  8.  Security Considerations








  Hood                    Expires 24 September 2026              [Page 10]


  Internet-Draft                  AGTP-CERT                     March 2026


  8.1.  Certificate Pinning

     Deployments with strict security requirements *MAY* implement
     certificate pinning for known agents, rejecting connections from
     agents whose certificate serial or key does not match a pre-
     registered value.  Certificate pinning interacts with renewal; pinned
     agents *MUST* update pins on each certificate renewal before the old
     certificate expires.

  8.2.  Scope Commitment Forgery

     The authority-scope-commitment is an Ed25519 signature over the
     canonical scope token set, signed by the governance platform's
     issuing key.  An attacker who compromises the issuing key can forge
     scope commitments.  Issuing key compromise *MUST* trigger immediate
     revocation of all certificates issued by that key and issuance of
     replacement certificates from a new key pair.  Issuing keys *SHOULD*
     be stored in hardware security modules.

  8.3.  Cross-Certificate Confusion

     An agent MAY hold multiple certificates (e.g., during renewal
     overlap).  Infrastructure *MUST* use the subject-agent-id extension
     value as the authoritative agent identifier, not the certificate
     subject CN, to prevent cross-certificate identity confusion during
     renewal windows.

  8.4.  IPR Notice

     Certain mechanisms described in this document may be subject to
     pending patent applications by the author, specifically: the
     authority-scope-commitment mechanism and the session-level revocation
     propagation architecture.  The licensor (Chris Hood / Nomotic, Inc.)
     is prepared to grant a royalty-free license to implementers for any
     patent claims covering these mechanisms, consistent with the IETF's
     IPR framework under the normative reference in [AGTP] Section 8.7.

  9.  IANA Considerations

  9.1.  X.509 Extension OID Registrations

     This document requests registration of the following Object
     Identifiers in the IANA Private Enterprise Numbers registry or an
     appropriate OID arc for IETF use.  Specific OID assignments are
     subject to IANA allocation:






  Hood                    Expires 24 September 2026              [Page 11]


  Internet-Draft                  AGTP-CERT                     March 2026


             +============================+===========+==========+
             | Extension                  | OID (TBD) | Critical |
             +============================+===========+==========+
             | subject-agent-id           | TBD       | Yes      |
             +----------------------------+-----------+----------+
             | principal-id               | TBD       | Yes      |
             +----------------------------+-----------+----------+
             | authority-scope-commitment | TBD       | Yes      |
             +----------------------------+-----------+----------+
             | governance-zone            | TBD       | No       |
             +----------------------------+-----------+----------+
             | trust-tier                 | TBD       | No       |
             +----------------------------+-----------+----------+
             | archetype                  | TBD       | No       |
             +----------------------------+-----------+----------+
             | activation-certificate-id  | TBD       | No       |
             +----------------------------+-----------+----------+
             | agtp-ctl-sct               | TBD       | No       |
             +----------------------------+-----------+----------+

              Table 2: AGTP Agent Certificate X.509 Extension OIDs

  10.  References

  10.1.  Normative References

     [AGTP]     Hood, C., "Agent Transfer Protocol (AGTP)", Work in
                Progress, Internet-Draft, draft-hood-independent-agtp-02,
                2026, <https://datatracker.ietf.org/doc/html/draft-hood-
                independent-agtp-02>.

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
                Housley, R., and W. Polk, "Internet X.509 Public Key
                Infrastructure Certificate and Certificate Revocation List
                (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
                <https://www.rfc-editor.org/rfc/rfc5280>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.






  Hood                    Expires 24 September 2026              [Page 12]


  Internet-Draft                  AGTP-CERT                     March 2026


     [RFC8555]  Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
                Kasten, "Automatic Certificate Management Environment
                (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
                <https://www.rfc-editor.org/rfc/rfc8555>.

  10.2.  Informative References

     [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
                RFC 6749, DOI 10.17487/RFC6749, October 2012,
                <https://www.rfc-editor.org/rfc/rfc6749>.

     [RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate
                Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
                <https://www.rfc-editor.org/rfc/rfc6962>.

     [RFC9334]  Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
                W. Pan, "Remote ATtestation procedureS (RATS)
                Architecture", RFC 9334, DOI 10.17487/RFC9334, January
                2023, <https://www.rfc-editor.org/rfc/rfc9334>.

  Appendix A.  Relationship to Birth Certificate

     The AGTP Agent Certificate and the Agent Birth Certificate (defined
     in [AGTP] Section 6.7) are complementary but distinct:



























  Hood                    Expires 24 September 2026              [Page 13]


  Internet-Draft                  AGTP-CERT                     March 2026


     +=================+=====================+===========================+
     | Property        | Birth               | Agent Certificate         |
     |                 | Certificate         |                           |
     +=================+=====================+===========================+
     | Layer           | Governance /        | Transport / TLS           |
     |                 | registry            |                           |
     +-----------------+---------------------+---------------------------+
     | Format          | JSON document       | X.509 v3                  |
     +-----------------+---------------------+---------------------------+
     | Issued by       | Governance          | Governance platform CA    |
     |                 | platform            |                           |
     +-----------------+---------------------+---------------------------+
     | Lifetime        | Permanent           | 90 days (renewable)       |
     |                 | (archived on        |                           |
     |                 | revoke)             |                           |
     +-----------------+---------------------+---------------------------+
     | Carries         | Full identity +     | Transport identity +      |
     |                 | archetype +         | scope commitment          |
     |                 | scope               |                           |
     +-----------------+---------------------+---------------------------+
     | Purpose         | Genesis record,     | TLS mutual auth, SEP      |
     |                 | registry anchor     | enforcement               |
     +-----------------+---------------------+---------------------------+
     | Cross-reference | certificate_hash    | activation-certificate-id |
     +-----------------+---------------------+---------------------------+

                                    Table 3

     The activation-certificate-id field in the Agent Certificate contains
     the Birth Certificate's certificate_hash, creating a verifiable
     cross-layer link between the transport certificate and the governance
     record without introducing a cryptographic dependency that would
     require re-issuance of the Agent Certificate whenever the governance
     record is updated.

  Author's Address

     Chris Hood
     Nomotic, Inc.
     Email: chris@nomotic.ai
     URI:   https://nomotic.ai










  Hood                    Expires 24 September 2026              [Page 14]


name: draft-sharif-agent-payment-trust
rev: 00
title: Trust Scoring and Identity Verification for Autonomous AI Agent Payment Transactions
time: 2026-03-25T12:42:19Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-26T12:42:19Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Policy/governance"]
tags: []
fetched_at: 2026-05-22T09:24:41.698245+00:00
source: ietf
abstract:
  This document specifies a protocol for trust scoring, identity
     verification, and spend limit enforcement for autonomous AI agents
     that initiate financial transactions.  As AI agents gain the
     capability to make payments via protocols such as the Machine
     Payments Protocol (MPP), a standardised mechanism is needed to
     verify agent identity, assess trustworthiness, and enforce
     financial limits based on behavioural history.

     The protocol defines a five-dimension trust scoring model, per-
     agent cryptographic identity using ECDSA P-256 key pairs,
     challenge-response identity verification, spend limit tiers
     derived from trust scores, anomaly detection for financial
     behaviour, and a public trust query API for third-party platforms.

     This specification complements draft-sharif-mcps-secure-mcp, which
     provides message-level cryptographic security for the Model Context
     Protocol (MCP).  Together, the two specifications address protocol
     security (MCPS) and financial trust (this document) for the AI
     agent economy.

full_text:
  Internet Engineering Task Force                               R. Sharif
  Internet-Draft                                           CyberSecAI Ltd
  Intended status: Standards Track                          25 March 2026
  Expires: 26 September 2026


          Trust Scoring and Identity Verification for Autonomous
                      AI Agent Payment Transactions

                   draft-sharif-agent-payment-trust-00

  Abstract

     This document specifies a protocol for trust scoring, identity
     verification, and spend limit enforcement for autonomous AI agents
     that initiate financial transactions.  As AI agents gain the
     capability to make payments via protocols such as the Machine
     Payments Protocol (MPP), a standardised mechanism is needed to
     verify agent identity, assess trustworthiness, and enforce
     financial limits based on behavioural history.

     The protocol defines a five-dimension trust scoring model, per-
     agent cryptographic identity using ECDSA P-256 key pairs,
     challenge-response identity verification, spend limit tiers
     derived from trust scores, anomaly detection for financial
     behaviour, and a public trust query API for third-party platforms.

     This specification complements draft-sharif-mcps-secure-mcp, which
     provides message-level cryptographic security for the Model Context
     Protocol (MCP).  Together, the two specifications address protocol
     security (MCPS) and financial trust (this document) for the AI
     agent economy.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other documents
     at any time.  It is inappropriate to use Internet-Drafts as
     reference material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 26 September 2026.

  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents
     (https://trustee.ietf.org/license-info) in effect on the date of
     publication of this document.  Please review these documents
     carefully, as they describe your rights and restrictions with
     respect to this document.

  Table of Contents

     1.  Introduction
     2.  Terminology
     3.  Problem Statement
     4.  Architecture Overview
     5.  Agent Identity
         5.1.  Key Pair Generation
         5.2.  Public Key Registration
         5.3.  Agent Passport
     6.  Challenge-Response Identity Verification
         6.1.  Challenge Issuance
         6.2.  Challenge Signing
         6.3.  Signature Verification
         6.4.  Failure Handling
     7.  Trust Scoring Model
         7.1.  Scoring Dimensions
         7.2.  Dimension Weights
         7.3.  Score Computation
         7.4.  Trust Levels
         7.5.  Dynamic Adjustment
         7.6.  Dormancy Decay
     8.  Spend Limit Enforcement
         8.1.  Per-Transaction Limits
         8.2.  Daily Aggregate Limits
         8.3.  Developer Aggregate Limits
         8.4.  Promotion Rate Limiting
     9.  Anomaly Detection
         9.1.  Magnitude Anomaly
         9.2.  Velocity Anomaly
         9.3.  Temporal Anomaly
         9.4.  Recipient Anomaly
         9.5.  Probing Anomaly
         9.6.  Self-Dealing Detection
     10. Public Trust Query API
         10.1. Request Format
         10.2. Response Format
         10.3. Batch Queries
         10.4. Rate Limiting
         10.5. Information Disclosure Controls
     11. Transaction Signing and Receipts
         11.1. Transaction Envelope
         11.2. Hash Chain
         11.3. Non-Repudiable Receipts
     12. Revocation
         12.1. Agent Revocation
         12.2. Key Rotation
         12.3. Emergency Freeze
     13. Security Considerations
         13.1. Key Management
         13.2. Trust Farming Mitigation
         13.3. Sybil Attack Prevention
         13.4. Impersonation Detection
         13.5. Race Condition Handling
         13.6. Score Transparency and Gaming
     14. Privacy Considerations
     15. IANA Considerations
     16. References
         16.1. Normative References
         16.2. Informative References
     Appendix A.  PSD2 SCA Mapping
     Appendix B.  PCI DSS v4.0.1 Mapping
     Appendix C.  Trust Level Reference Implementation
     Author's Address


  1.  Introduction

     The emergence of autonomous AI agents capable of initiating
     financial transactions represents a fundamental shift in payment
     infrastructure.  Protocols such as Stripe's Machine Payments
     Protocol (MPP) [STRIPE-MPP], launched in March 2026, enable AI
     agents to create payment intents, process charges, and manage
     subscriptions without human intervention.

     Existing payment security mechanisms -- Strong Customer
     Authentication (SCA) under PSD2 [PSD2], fraud detection systems,
     and Know Your Customer (KYC) processes -- are designed for human
     users who are present at the point of transaction.  These
     mechanisms do not address the unique characteristics of AI agent
     transactions:

     o  Agents operate at machine speed, potentially executing thousands
        of transactions per minute.

     o  Agents act autonomously, without real-time human oversight for
        each transaction.

     o  Multiple agents may operate under a single developer account,
        each with different behavioural patterns and risk profiles.

     o  Agent identity is typically established through static API keys
        that provide no per-agent differentiation.

     o  There is no standardised mechanism for a platform to assess an
        agent's trustworthiness before granting financial access.

     This document specifies a protocol that addresses these gaps
     through four mechanisms:

     1.  Per-agent cryptographic identity using ECDSA P-256 key pairs
         with challenge-response verification.

     2.  A five-dimension behavioural trust scoring model that
         dynamically adjusts based on observed agent behaviour.

     3.  Spend limit tiers derived from trust scores, enforced at the
         protocol level before transactions reach payment networks.

     4.  A public trust query API that enables any platform to assess
         agent trustworthiness without requiring a pre-existing
         relationship with the trust authority.


  2.  Terminology

     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 [RFC2119] [RFC8174] when, and only when, they appear in
     all capitals, as shown here.

     Agent:  An autonomous software entity that initiates financial
        transactions on behalf of a principal (human or organisation)
        via standardised protocols.

     Agent Passport:  A cryptographically signed identity document
        containing the agent's public key hash, developer identity,
        authorised scope, and issuance metadata.

     Challenge:  A cryptographically random value issued by a verifier
        to test whether a claimant possesses a specific private key.

     Developer:  The human or organisational entity that creates,
        manages, and is accountable for one or more agents.

     Trust Authority:  The service that maintains agent registrations,
        computes trust scores, verifies identities, and responds to
        trust queries.

     Trust Score:  A numerical value (0-100) representing the assessed
        trustworthiness of an agent based on multiple behavioural
        dimensions.

     Trust Level:  A discrete classification (L0-L4) derived from the
        trust score, with associated financial limits.


  3.  Problem Statement

     Consider the following scenario: an AI agent operating as a
     procurement assistant for a small business is authorised to
     purchase cloud computing resources.  The agent holds an API key
     for a payment processor and can create payment intents
     autonomously.

     An attacker who obtains the agent's API key -- through a
     compromised development environment, leaked configuration file,
     or man-in-the-middle attack -- can:

     o  Impersonate the agent and make unauthorised purchases.

     o  Exceed the intended spending authority of the agent.

     o  Create transactions at machine speed before the compromise is
        detected.

     o  Operate across multiple platforms simultaneously using the
        same stolen credentials.

     Current mitigations (API key rotation, IP allowlisting) are
     reactive rather than preventive.  They do not address the
     fundamental question: "Is this specific agent, making this
     specific transaction, trustworthy?"

     This document specifies a protocol that answers that question
     through cryptographic identity verification and behavioural
     trust scoring.


  4.  Architecture Overview

     The protocol defines interactions between four roles:

                    +----------+
                    |Developer |
                    +----+-----+
                         |
                    Creates and manages
                         |
                    +----v-----+
                    |  Agent   |
                    +----+-----+
                         |
                    Requests payment
                         |
                +--------v---------+
                | Trust Authority  |
                | (AgentPass)      |
                +--------+---------+
                         |
                Issues challenge, verifies identity,
                checks trust score, enforces limits
                         |
                +--------v---------+
                | Platform / Store |
                +--------+---------+
                         |
                Queries trust API, decides to
                allow or deny the transaction
                         |
                +--------v---------+
                | Payment Network  |
                | (Stripe, etc.)   |
                +------------------+

     The Trust Authority MUST NOT be in the critical path of payment
     processing.  Platforms query the Trust Authority before initiating
     payments; if the Trust Authority is unavailable, platforms SHOULD
     apply a fail-closed policy for new agents and a cached-trust
     policy for previously verified agents.


  5.  Agent Identity

  5.1.  Key Pair Generation

     Each agent MUST have a unique ECDSA key pair using the P-256
     curve [FIPS186-4].

     Key pairs MAY be generated by the Trust Authority and provided
     to the developer (the private key MUST be returned exactly once
     and MUST NOT be stored by the Trust Authority), or generated by
     the developer and the public key registered with the Trust
     Authority (RECOMMENDED for production deployments).

  5.2.  Public Key Registration

     The developer MUST register the agent's public key with the
     Trust Authority at agent creation time.  The Trust Authority
     stores ONLY the public key.  The private key MUST remain under
     the developer's control at all times.

     For production deployments, the private key SHOULD be stored in
     a Hardware Security Module (HSM), cloud Key Management Service
     (KMS), or platform-native secure storage (e.g., iOS Keychain
     with kSecAttrAccessibleWhenUnlockedThisDeviceOnly).

  5.3.  Agent Passport

     Upon registration, the Trust Authority issues an Agent Passport
     -- a signed JSON document containing:

     o  agentId: Unique identifier for the agent.
     o  agentPublicKeyHash: SHA-256 hash of the agent's public key,
        binding the passport to a specific key pair.
     o  developerId: Identifier of the owning developer.
     o  scope: Array of authorised action categories.
     o  issuedAt: ISO 8601 timestamp of issuance.
     o  issuer: Identifier of the Trust Authority.

     The passport is signed by the developer's key (not the agent's
     key), establishing an issuance chain: Trust Authority issues to
     Developer, Developer delegates to Agent.


  6.  Challenge-Response Identity Verification

     When a platform needs to verify an agent's identity before
     granting access or processing a payment, it uses the following
     challenge-response protocol.

  6.1.  Challenge Issuance

     The platform (or Trust Authority on behalf of the platform)
     generates a challenge:

     o  challenge: 32 bytes of cryptographically random data, hex-
        encoded (64 characters).
     o  expiresAt: Timestamp, MUST be no more than 60 seconds from
        issuance.
     o  agentId: The agent for which the challenge is issued.

     Each challenge MUST be single-use.  The Trust Authority MUST
     reject any attempt to verify a challenge that has already been
     used (replay prevention).

  6.2.  Challenge Signing

     The agent signs the challenge using its private key:

        signature = ECDSA-Sign(SHA-256(challenge), agentPrivateKey)

     The signature is hex-encoded for transmission.

  6.3.  Signature Verification

     The Trust Authority verifies the signature using the agent's
     registered public key:

        valid = ECDSA-Verify(SHA-256(challenge), signature,
                             agentPublicKey)

     If valid, the Trust Authority returns the agent's current trust
     score, level, and recommendation.

  6.4.  Failure Handling

     If verification fails:

     o  The Trust Authority MUST log the failure as a potential
        impersonation attempt.
     o  The agent's trust score MUST be penalised (RECOMMENDED:
        -10 points per failed attempt).
     o  The agent's anomaly counter MUST be incremented.
     o  The response MUST include an error code indicating the
        failure type: IMPERSONATION_DETECTED, CHALLENGE_EXPIRED,
        CHALLENGE_REPLAYED, or AGENT_MISMATCH.


  7.  Trust Scoring Model

  7.1.  Scoring Dimensions

     The trust score is computed from five dimensions, each
     contributing a weighted component to the overall score:

     1.  Code Attestation (CA): Whether the agent's code has been
         cryptographically verified against its declared specification.

     2.  Execution Success Rate (ES): The proportion of the agent's
         past transactions that completed without anomaly, dispute,
         or reversal.

     3.  Behavioural Consistency (BC): The statistical consistency
         of the agent's transaction patterns (amounts, recipients,
         timing) relative to its established baseline.

     4.  Operational Tenure (OT): The duration the agent has been
         registered and actively transacting.

     5.  Anomaly History (AH): The inverse of the count and severity
         of detected anomalies (fewer anomalies = higher score).

  7.2.  Dimension Weights

     Each dimension contributes 20% to the overall score:

        W_CA = W_ES = W_BC = W_OT = W_AH = 0.20

     Implementations MAY adjust weights provided the sum equals 1.0
     and no single dimension exceeds 0.40.

  7.3.  Score Computation

     The raw trust score is computed as:

        raw = (CA * W_CA) + (ES * W_ES) + (BC * W_BC) +
              (OT * W_OT) + (AH * W_AH)

     Each dimension value is in the range [0, 100].

     The final score incorporates a trust bonus (earned through
     successful transactions, capped at +/- 30) and a dormancy
     penalty:

        score = clamp(raw + bonus + dormancy, 0, 100)

  7.4.  Trust Levels

     The trust score maps to discrete levels with associated financial
     limits:

     +---------+-------+----------------+---------------+
     |  Level  | Score | Per-TX Limit   | Daily Limit   |
     +---------+-------+----------------+---------------+
     |   L0    | 0-19  | $0             | $0            |
     |   L1    | 20-39 | $10            | $50           |
     |   L2    | 40-59 | $100           | $500          |
     |   L3    | 60-79 | $1,000         | $5,000        |
     |   L4    | 80-100| $50,000        | $200,000      |
     +---------+-------+----------------+---------------+

     No trust level SHALL have unlimited financial access.  L4
     represents the maximum tier with mandatory enhanced auditing.

  7.5.  Dynamic Adjustment

     The trust score adjusts dynamically based on observed behaviour:

     o  Successful transaction: +0.5 trust bonus.
     o  Blocked transaction (over limit): -2 trust bonus.
     o  Anomaly detected: -5 per anomaly.
     o  Critical anomaly (3+ simultaneous): -20 trust bonus.
     o  Failed identity verification: -10 trust bonus.
     o  Probing detected: -15 trust bonus.

     Self-dealing transactions (agent-to-agent payments within the
     same developer account) MUST earn zero trust bonus.

  7.6.  Dormancy Decay

     Agents that are inactive for extended periods MUST have their
     trust score reduced:

     o  30 days inactive: -10 penalty.
     o  60 days inactive: -20 penalty.
     o  90+ days inactive: -30 penalty (effectively drops to L0).

     The dormancy penalty is applied at score computation time and
     is removed when the agent resumes activity.


  8.  Spend Limit Enforcement

  8.1.  Per-Transaction Limits

     Each transaction MUST be checked against the per-transaction
     limit of the agent's current trust level.  Transactions
     exceeding the limit MUST be rejected with error code
     MCPS-SPEND-TX-LIMIT.

  8.2.  Daily Aggregate Limits

     The Trust Authority MUST track daily aggregate spending per
     agent within a rolling 24-hour window.  Transactions that
     would cause the aggregate to exceed the daily limit MUST be
     rejected with error code MCPS-SPEND-DAILY-LIMIT.

  8.3.  Developer Aggregate Limits

     To prevent Sybil attacks (creating many agents to circumvent
     per-agent limits), the Trust Authority MUST enforce aggregate
     daily spending limits across ALL agents belonging to a single
     developer.

  8.4.  Promotion Rate Limiting

     To prevent trust farming, agents MUST NOT be promoted to a
     higher trust level until a minimum period has elapsed at the
     current level:

     o  L0 to L1: No minimum.
     o  L1 to L2: 7 days.
     o  L2 to L3: 14 days.
     o  L3 to L4: 30 days.


  9.  Anomaly Detection

     The Trust Authority MUST monitor agent financial behaviour for
     the following anomaly types.

  9.1.  Magnitude Anomaly

     A transaction amount that exceeds 5x the agent's historical
     average.

  9.2.  Velocity Anomaly

     More than 10 transactions within a 60-second window.

  9.3.  Temporal Anomaly

     Transactions initiated outside the agent's established
     operational time window.

  9.4.  Recipient Anomaly

     Transactions to recipients the agent has never previously
     transacted with, flagged after the agent has established a
     baseline of 5+ transactions (informational severity only).

  9.5.  Probing Anomaly

     Three or more transactions within one hour where the amount
     exceeds 85% of the per-transaction limit.  This pattern
     indicates systematic probing of authorisation boundaries.

     Probing detection MUST trigger immediate blocking and an
     accelerated trust penalty.

  9.6.  Self-Dealing Detection

     Transactions between agents belonging to the same developer
     MUST be flagged as self-dealing.  Self-dealing transactions
     MUST NOT contribute positive trust bonus to either agent.


  10.  Public Trust Query API

  10.1.  Request Format

     Platforms query agent trustworthiness via HTTP GET:

        GET /api/public/trust/{agentId}

     No authentication is required for public trust queries (same
     model as DNS lookups or certificate transparency logs).

  10.2.  Response Format

     The response includes:

     o  agentId: Agent identifier.
     o  status: ACTIVE or REVOKED.
     o  trust.score: Numerical trust score (0-100).
     o  trust.level: Trust level (0-4).
     o  recommendation: ALLOW, ALLOW_WITH_LIMITS, or DENY.
     o  spendLimits: Per-transaction and daily limits.
     o  history: Transaction count, success rate, operational days.

  10.3.  Batch Queries

     For efficiency, platforms MAY query multiple agents in a single
     request:

        POST /api/public/trust/batch
        Body: { "agentIds": ["agent_abc", "agent_def"] }

  10.4.  Rate Limiting

     The Trust Authority MUST enforce rate limiting on public trust
     queries to prevent abuse (RECOMMENDED: 120 queries per minute
     per source IP).

  10.5.  Information Disclosure Controls

     The public trust API MUST NOT return trust scoring dimension
     breakdowns.  Full dimension data is available only via
     authenticated API to the agent's owner.  This prevents
     attackers from identifying the weakest dimension and gaming
     it specifically.


  11.  Transaction Signing and Receipts

  11.1.  Transaction Envelope

     Each authorised transaction MUST be wrapped in a signed
     envelope containing: agent identity, trust level at time of
     authorisation, unique transaction nonce, timestamp, and ECDSA
     signature covering the canonical serialisation of all fields.

  11.2.  Hash Chain

     Each transaction record MUST include a reference to the SHA-256
     hash of the previous transaction in the agent's audit trail.
     This creates a tamper-evident chain where modification of any
     historical record is computationally detectable.

  11.3.  Non-Repudiable Receipts

     The signed transaction envelope constitutes a non-repudiable
     receipt proving: which agent made the request, the exact
     parameters at the time of signing, when the request was
     created, and the agent's trust level at authorisation time.


  12.  Revocation

  12.1.  Agent Revocation

     An agent MAY be revoked by its developer at any time.
     Revocation MUST take effect within 1 second and MUST be
     reflected in all subsequent trust queries.  Revoked agents
     MUST receive a DENY recommendation on all trust queries.

  12.2.  Key Rotation

     Developers SHOULD rotate agent key pairs periodically
     (RECOMMENDED: every 90 days).  Key rotation MUST NOT reset
     the agent's trust score.

  12.3.  Emergency Freeze

     The Trust Authority MUST support an emergency freeze mechanism
     that immediately halts all financial transactions for a
     specific agent, developer, or globally.


  13.  Threat Model

     This section defines the adversary profiles, attack vectors,
     and mitigations that the protocol is designed to address.

  13.1.  Adversary Profiles

     The protocol considers four adversary types:

     A1.  External Attacker: Has no legitimate access to the system.
          Goal: impersonate a trusted agent to make unauthorised
          payments.  Capabilities: network interception, credential
          harvesting from public sources, brute-force key guessing.

     A2.  Compromised Developer: A legitimate developer whose
          infrastructure has been breached.  Goal: use stolen agent
          credentials to make payments before the compromise is
          detected.  Capabilities: possesses valid API keys and
          potentially agent private keys.

     A3.  Malicious Developer: A legitimate account holder who
          intentionally abuses the system.  Goal: extract maximum
          financial value through trust manipulation, Sybil attacks,
          or self-dealing.  Capabilities: full control over their
          agents and account.

     A4.  Compromised Trust Authority: The Trust Authority itself
          is breached.  Goal: forge trust scores, issue false
          identity verifications, or exfiltrate stored data.
          Capabilities: access to public keys, trust scores, and
          transaction metadata (but NOT agent private keys if the
          protocol is correctly implemented).

  13.2.  Attack Tree: Agent Impersonation

     Attack goal: Make a payment as Agent X without possessing
     Agent X's private key.

     Attack Path 1: Steal the private key
     |-- 1a. Compromise developer infrastructure (A2)
     |   |-- Mitigation: HSM/KMS storage (Section 5.2)
     |   |-- Mitigation: Keychain with device-only access
     |   |-- Residual risk: If key is in plaintext on disk,
     |       attacker succeeds. Protocol CANNOT prevent this;
     |       it can only detect anomalous behaviour post-compromise.
     |
     |-- 1b. Intercept key during generation (A1)
     |   |-- Mitigation: TLS on all API communications
     |   |-- Mitigation: Developer-managed keys (key never
     |       transmitted)
     |
     |-- 1c. Extract from Trust Authority (A4)
         |-- Mitigation: Trust Authority MUST NOT store private
             keys (Section 5.2). This path is blocked by design.

     Attack Path 2: Bypass identity verification
     |-- 2a. Replay a valid challenge-response (A1)
     |   |-- Mitigation: Single-use challenges (Section 6.1)
     |   |-- Mitigation: 60-second expiry window
     |
     |-- 2b. Forge a signature without the key (A1)
     |   |-- Mitigation: ECDSA P-256 computational infeasibility
     |   |-- Estimated cost: >2^128 operations
     |
     |-- 2c. Present a different agent's passport (A1)
     |   |-- Mitigation: Passport contains agentPublicKeyHash
     |       (Section 5.3), binding it to a specific key pair
     |
     |-- 2d. Skip identity verification entirely (A1)
         |-- Mitigation: Platform policy. If the platform does
             not require challenge-response, this succeeds.
             RECOMMENDATION: Platforms SHOULD require identity
             verification for transactions above L2 limits.

     Attack Path 3: Social engineering
     |-- 3a. Convince a platform to trust a low-score agent (A3)
         |-- Mitigation: Public trust API provides objective score.
             Platform makes its own decision.

  13.3.  Attack Tree: Trust Score Manipulation

     Attack goal: Artificially inflate an agent's trust score to
     gain higher spending authority.

     Attack Path 1: Trust farming
     |-- Make many small legitimate payments to build score
     |-- Then make one large fraudulent payment at elevated level
     |-- Mitigation: Promotion rate limiting (Section 8.4)
     |   Minimum 7/14/30 days per level before promotion.
     |-- Mitigation: Magnitude anomaly detection (Section 9.1)
     |   Sudden increase in transaction size is flagged.
     |-- Residual risk: Patient attacker over 60+ days could
         reach L4. Mitigated by L4 cap ($50,000/tx) and
         mandatory enhanced auditing.

     Attack Path 2: Self-dealing
     |-- Create two agents, send payments back and forth
     |-- Mitigation: Self-dealing detection (Section 9.6)
     |   Agent-to-agent payments within same developer earn
     |   zero trust bonus.

     Attack Path 3: Sybil attack
     |-- Create 100 agents at L1 ($50/day each = $5,000/day)
     |-- Mitigation: Developer aggregate limits (Section 8.3)
     |   Total spending across ALL agents is capped.

     Attack Path 4: Score gaming via dimension targeting
     |-- Query public API, identify weakest dimension, game it
     |-- Mitigation: Public API hides dimension breakdown
     |   (Section 10.5). Full dimensions only via authenticated
     |   API for the agent's owner.

  13.4.  Attack Tree: Denial of Service

     Attack goal: Prevent legitimate agents from making payments.

     Attack Path 1: Exhaust rate limits
     |-- Flood trust API queries to trigger rate limiting
     |-- Mitigation: Per-IP rate limiting (Section 10.4)
     |-- Residual risk: Distributed attack from many IPs.
         Mitigation: WAF/CDN layer (implementation-specific).

     Attack Path 2: Trigger false anomalies
     |-- Make unusual payments to trigger anomaly flags on a
         target agent
     |-- Mitigation: Only the agent's own developer can make
         payments from that agent. External attackers cannot
         trigger anomalies without the agent's credentials.

     Attack Path 3: Challenge flooding
     |-- Request thousands of challenges for an agent
     |-- Mitigation: Rate limiting on challenge issuance.
     |   Challenges are lightweight (no crypto operations
     |   until verification).

  13.5.  Attack Tree: Financial Fraud Post-Compromise

     Attack goal: Maximise financial extraction after obtaining
     valid agent credentials.

     Scenario: Attacker has stolen Agent X's private key and
     API key (Adversary A2).

     |-- Step 1: Verify identity to confirm credentials work
     |   Detection: Challenge-response succeeds, but from
     |   a new IP/location. Implementations SHOULD log IP
     |   and alert on geographic anomalies.
     |
     |-- Step 2: Make payments up to current trust level limit
     |   Detection: Magnitude anomaly if patterns differ from
     |   historical baseline. Velocity anomaly if transactions
     |   are rapid. Temporal anomaly if outside normal hours.
     |
     |-- Step 3: Attempt to maximise extraction speed
     |   Mitigation: Daily aggregate limits cap total damage.
     |   At L3: max $5,000/day. At L4: max $200,000/day.
     |   Per-TX limits prevent single catastrophic transactions.
     |
     |-- Step 4: Developer detects and revokes
     |   Mitigation: Instant revocation (Section 12.1).
     |   All trust queries immediately return DENY.
     |
     |-- Maximum exposure window: Time between compromise and
         detection. Anomaly detection reduces this window.
         RECOMMENDED: Developers configure webhook alerts for
         unusual activity.

     Maximum financial exposure by trust level:

     +---------+------------------+-------------------+
     |  Level  | Max per day      | Max before likely |
     |         |                  | detection (est.)  |
     +---------+------------------+-------------------+
     |   L1    | $50              | $50               |
     |   L2    | $500             | $500              |
     |   L3    | $5,000           | $5,000            |
     |   L4    | $200,000         | $200,000          |
     +---------+------------------+-------------------+

     Note: These are worst-case figures assuming the attacker
     perfectly mimics the agent's historical behaviour to avoid
     anomaly detection. In practice, behavioural differences
     between the legitimate agent and the attacker will trigger
     anomalies earlier, reducing the exposure window.

  13.6.  Residual Risks

     The following risks are acknowledged but not fully mitigated
     by this protocol:

     R1.  Private key compromise with HSM bypass: If an attacker
          obtains the private key through a zero-day HSM
          vulnerability, the protocol cannot distinguish the
          attacker from the legitimate agent until behavioural
          anomalies are detected.

     R2.  Trust Authority compromise: If the Trust Authority is
          breached, the attacker can forge trust scores. Mitigation:
          trust query responses SHOULD be signed by the Trust
          Authority's own key, enabling platforms to verify response
          authenticity.

     R3.  Collusion between developer and attacker: A malicious
          developer who intentionally provides their agent
          credentials to a third party cannot be distinguished
          from a compromised developer. Mitigation: developer
          aggregate limits cap total exposure. Legal/contractual
          controls are out of scope.

     R4.  Race conditions in distributed deployments: Under high
          concurrency, two transactions may simultaneously pass
          limit checks. Mitigation: implementations MUST use
          atomic operations. Residual risk depends on
          implementation correctness.

     R5.  Currency arbitrage: Limits are enforced on raw
          transaction amounts. An agent transacting in a volatile
          currency could exploit exchange rate differences.
          Mitigation: implementations SHOULD normalise all amounts
          to a base currency (RECOMMENDED: USD) at transaction time.

     R6.  Long-horizon trust farming: A patient adversary who
          operates legitimately for 60+ days can reach L4.
          Mitigation: L4 has finite limits ($50,000/tx, $200,000/
          day), mandatory enhanced auditing, and 30-day promotion
          cooldown from L3. The cost of maintaining a legitimate
          operation for 60+ days to reach L4 limits may exceed the
          potential fraud proceeds.


  14.  Privacy Considerations

     The public trust API returns agent-level data (trust score,
     transaction count, operational tenure) that may reveal
     information about the developer's agent deployment patterns.
     Implementations SHOULD consider whether this level of
     disclosure is appropriate for their deployment context.

     Agent private keys MUST NOT be transmitted to or stored by the
     Trust Authority in production deployments.


  15.  IANA Considerations

     This document has no IANA actions.


  16.  References

  16.1.  Normative References

     [FIPS186-4]
                National Institute of Standards and Technology, "Digital
                Signature Standard (DSS)", FIPS PUB 186-4, July 2013.

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
                RFC 2119 Key Words", BCP 14, RFC 8174,
                DOI 10.17487/RFC8174, May 2017.

  16.2.  Informative References

     [MCPS]     Sharif, R., "Secure Model Context Protocol (MCPS):
                Cryptographic Message Security for AI Agent
                Communication", Internet-Draft
                draft-sharif-mcps-secure-mcp-00, March 2026.

     [PSD2]     European Parliament and Council, "Directive (EU)
                2015/2366 on payment services in the internal market",
                November 2015.

     [STRIPE-MPP]
                Stripe, Inc., "Machine Payments Protocol",
                March 2026.

     [PCI-DSS]  PCI Security Standards Council, "Payment Card
                Industry Data Security Standard v4.0.1", March 2024.


  Appendix A.  PSD2 SCA Mapping

     This appendix maps the protocol's mechanisms to PSD2 Strong
     Customer Authentication requirements.  The cryptographic
     delegation certificate (Agent Passport) serves as the human
     principal's pre-signed authorisation, satisfying the "something
     the user has" factor through possession of the signing key used
     to create the delegation.

     Full PSD2 mapping: See CyberSecAI EBA Position Paper (2026).


  Appendix B.  PCI DSS v4.0.1 Mapping

     This appendix provides a high-level mapping of the protocol to
     PCI DSS v4.0.1 requirements.  The protocol's cryptographic
     signing, access controls, audit logging, and anomaly detection
     address requirements across all 12 PCI DSS requirement families.

     Full PCI mapping: See CyberSecAI PCI DSS Paper (2026).


  Appendix C.  Trust Level Reference Implementation

     A reference implementation of the trust scoring model is
     available as an npm package (@proofxhq/agentpass) and an iOS
     Swift SDK, both with zero external dependencies.


  Author's Address

     Raza Sharif
     CyberSecAI Ltd
     United Kingdom

     Email: contact@agentsign.dev
     URI:   https://agentpass.co.uk


