



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]
