# drafts

name: draft-helixar-hdp-agentic-delegation
rev: 00
title: Human Delegation Provenance Protocol (HDP): Cryptographic Chain-of-Custody for Agentic AI Systems
time: 2026-03-26T04:07:16Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-27T04:07:16Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Human-agent interaction", "Policy/governance"]
tags: []
fetched_at: 2026-05-22T09:24:41.698254+00:00
source: ietf
abstract:
  Agentic AI systems operate on behalf of human principals, often
     delegating tasks through multi-step chains of AI agents.  There is
     currently no standard mechanism to record who authorized an agent to
     act, under what scope, and through what chain of delegation , in a
     way that can be verified offline, without a central registry, and
     without third-party trust anchors.

     This document specifies the Human Delegation Provenance Protocol
     (HDP) version 0.1, a lightweight token-based protocol that captures,
     structures, cryptographically signs, and verifies human delegation
     context in agentic AI systems.  An HDP token binds a human
     authorization event to a session, records each agent's delegation
     action as a signed hop in an append-only chain, and enables any
     participant to verify the full provenance record using only the
     issuer's Ed25519 public key and the current session identifier.
     Verification is fully offline.  No registry lookup, no network call,
     and no third-party trust anchor is required.

full_text:
  Internet Engineering Task Force                                  Helixar
  Internet-Draft                                           Helixar Limited
  Intended status: Informational                                March 2026
  Expires: 26 September 2026


    Human Delegation Provenance Protocol (HDP): Cryptographic Chain-of-
                       Custody for Agentic AI Systems
                  draft-helixar-hdp-agentic-delegation-00

  Abstract

     Agentic AI systems operate on behalf of human principals, often
     delegating tasks through multi-step chains of AI agents.  There is
     currently no standard mechanism to record who authorized an agent to
     act, under what scope, and through what chain of delegation , in a
     way that can be verified offline, without a central registry, and
     without third-party trust anchors.

     This document specifies the Human Delegation Provenance Protocol
     (HDP) version 0.1, a lightweight token-based protocol that captures,
     structures, cryptographically signs, and verifies human delegation
     context in agentic AI systems.  An HDP token binds a human
     authorization event to a session, records each agent's delegation
     action as a signed hop in an append-only chain, and enables any
     participant to verify the full provenance record using only the
     issuer's Ed25519 public key and the current session identifier.
     Verification is fully offline.  No registry lookup, no network call,
     and no third-party trust anchor is required.

  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 2 September 2026.





  Helixar                 Expires 26 September 2026               [Page 1]


  Internet-Draft           HDP Agentic Delegation               March 2026


  Copyright Notice

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

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   4
       1.2.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .   4
       1.3.  Relationship to IPP (draft-haberkamp-ipp-00)  . . . . . .   4
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5
     3.  Token Structure . . . . . . . . . . . . . . . . . . . . . . .   5
       3.1.  Header  . . . . . . . . . . . . . . . . . . . . . . . . .   6
       3.2.  Principal . . . . . . . . . . . . . . . . . . . . . . . .   6
       3.3.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   7
       3.4.  Chain . . . . . . . . . . . . . . . . . . . . . . . . . .   8
       3.5.  Signature . . . . . . . . . . . . . . . . . . . . . . . .   9
     4.  Cryptographic Signing . . . . . . . . . . . . . . . . . . . .   9
       4.1.  Root Signature  . . . . . . . . . . . . . . . . . . . . .   9
       4.2.  Hop Signature . . . . . . . . . . . . . . . . . . . . . .  10
       4.3.  Chain Integrity Rules . . . . . . . . . . . . . . . . . .  10
     5.  Verification Pipeline . . . . . . . . . . . . . . . . . . . .  11
     6.  Re-Authorization  . . . . . . . . . . . . . . . . . . . . . .  12
     7.  Multi-Principal Delegation  . . . . . . . . . . . . . . . . .  13
     8.  Transport . . . . . . . . . . . . . . . . . . . . . . . . . .  13
       8.1.  HTTP Header: X-HDP-Token  . . . . . . . . . . . . . . . .  13
       8.2.  Token by Reference: X-HDP-Token-Ref . . . . . . . . . . .  14
       8.3.  Key Distribution: Well-Known Endpoint . . . . . . . . . .  14
     9.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  14
       9.1.  Minimum-Disclosure Principal Fields . . . . . . . . . . .  14
       9.2.  Data Retention and the Right to Erasure . . . . . . . . .  15
       9.3.  Proof of Humanity . . . . . . . . . . . . . . . . . . . .  15
     10. Security Considerations . . . . . . . . . . . . . . . . . . .  16
       10.1.  Threat Model . . . . . . . . . . . . . . . . . . . . . .  16
       10.2.  Token Forgery  . . . . . . . . . . . . . . . . . . . . .  16
       10.3.  Chain Tampering  . . . . . . . . . . . . . . . . . . . .  16
       10.4.  Replay Attack Defense  . . . . . . . . . . . . . . . . .  16
       10.5.  Prompt Injection . . . . . . . . . . . . . . . . . . . .  17



  Helixar                 Expires 26 September 2026               [Page 2]


  Internet-Draft           HDP Agentic Delegation               March 2026


       10.6.  Key Management . . . . . . . . . . . . . . . . . . . . .  17
       10.7.  Offline Verification Guarantee . . . . . . . . . . . . .  17
     11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
       11.1.  HTTP Header Field Registration . . . . . . . . . . . . .  18
       11.2.  Media Type Registration  . . . . . . . . . . . . . . . .  18
     12. Comparison with Related Work  . . . . . . . . . . . . . . . .  18
       12.1.  IPP (draft-haberkamp-ipp-00) . . . . . . . . . . . . . .  18
       12.2.  OAuth 2.0 Token Exchange (RFC 8693)  . . . . . . . . . .  19
       12.3.  JSON Web Token (RFC 7519)  . . . . . . . . . . . . . . .  19
       12.4.  UCAN (User Controlled Authorization Networks)  . . . . .  20
     13. Normative References  . . . . . . . . . . . . . . . . . . . .  20
     14. Informative References  . . . . . . . . . . . . . . . . . . .  20
     Appendix A.  Complete Token Example . . . . . . . . . . . . . . .  21
     Change Log  . . . . . . . . . . . . . . . . . . . . . . . . . . .  22
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  22

  1.  Introduction

     Autonomous AI agents are increasingly used to execute consequential
     actions: sending emails, modifying files, running code, calling APIs,
     and transacting on behalf of users.  When a human authorizes an
     orchestrator agent, which in turn delegates to sub-agents, which
     further delegate to tool-execution agents, the originating human
     authorization becomes disconnected from the terminal action.  There
     is no standard record of the authorization chain.

     This gap creates accountability, auditability, and safety problems:

     *  Downstream agents cannot verify that the action they are being
        asked to perform was actually authorized by a human.

     *  Post-hoc audits cannot reconstruct who approved what, and when.

     *  Prompt injection attacks , where malicious content in the
        environment instructs an agent to act , cannot be distinguished
        from legitimate human delegation.

     HDP addresses this by defining a token that:

     *  Records the human principal, their declared scope, and the session
        binding at issuance.

     *  Accumulates a cryptographically signed hop record for each agent
        that handles the token.

     *  Allows any recipient to verify the entire chain , root signature
        plus all hop signatures , using only the issuer's Ed25519 public
        key and the session identifier.



  Helixar                 Expires 26 September 2026               [Page 3]


  Internet-Draft           HDP Agentic Delegation               March 2026


  1.1.  Motivation

     The need for agentic delegation provenance is not hypothetical.
     Production deployments of AI orchestration systems (LangChain,
     AutoGPT, CrewAI, and similar frameworks) today pass natural language
     task descriptions between agents with no cryptographic binding to the
     original human authorization.  The operational risk compounds as
     models become more capable and agents are granted access to higher-
     consequence tools.

     A provenance token that travels alongside the task , tamper-evident,
     offline-verifiable, and scoped to what the human actually approved ,
     provides the foundation for auditable, accountable agentic systems.

  1.2.  Design Goals

     HDP is designed with the following goals in order of priority:

     1.  *Offline verifiability.* Verification MUST require only a public
         key and session ID.  No network call, registry lookup, or third-
         party endpoint is required.

     2.  *Self-sovereignty.* Any organization MUST be able to issue and
         verify HDP tokens without registering with a central authority or
         anchoring to a third-party key.

     3.  *Tamper evidence.* Any modification to a token , in its header,
         principal, scope, or any hop , MUST be detectable by the
         verification pipeline.

     4.  *Minimal footprint.* The protocol MUST be implementable in any
         language with Ed25519 and JSON support.  No mandatory
         infrastructure beyond key management is required.

     5.  *Privacy by design.* Principal identity fields MUST be separable
         from the audit-relevant parts of the token, so tokens can be
         transmitted to agents without exposing PII.

  1.3.  Relationship to IPP (draft-haberkamp-ipp-00)

     The Intent Provenance Protocol [I-D.haberkamp-ipp] addresses the same
     problem space.  HDP and IPP share the use of Ed25519 signatures and
     append-only provenance chains but make different architectural trade-
     offs, which are detailed in Section 12.  The two protocols are not
     interoperable.  HDP is offered as a distinct design point, not a
     revision of IPP.





  Helixar                 Expires 26 September 2026               [Page 4]


  Internet-Draft           HDP Agentic Delegation               March 2026


     The full HDP protocol specification is available at [HDP-SPEC].  A
     TypeScript reference implementation is available at [HDP-IMPL].

  2.  Conventions and Definitions

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

     Issuer:  The system or person that creates and signs an HDP token on
        behalf of a human principal.

     Principal:  The human who authorized the agentic task.  Represented
        in the token's principal object.

     Agent:  Any AI system, model, or automated process that receives and
        acts upon an HDP token.

     Hop:  A single delegation event, recorded as a signed entry in the
        token's chain array.

     Root signature:  The Ed25519 signature over the token's header,
        principal, and scope, computed by the issuer at token creation
        time.

     Hop signature:  The Ed25519 signature computed by an extending agent
        over the cumulative chain state at the time of extension.

     Session:  A logical unit of work identified by a session_id string,
        established between the issuer and the agent framework before the
        token is issued.

  3.  Token Structure

     An HDP token is a JSON object with six top-level fields.  The token
     MUST conform to the following structure.  All integer timestamps are
     Unix milliseconds (milliseconds since 1970-01-01T00:00:00Z).

     {
       "hdp"       : "0.1",          // protocol version
       "header"    : { ... },        // session binding + lifecycle
       "principal" : { ... },        // authorizing human
       "scope"     : { ... },        // authorized intent + constraints
       "chain"     : [ ... ],        // delegation hops (append-only)
       "signature" : { ... }         // root Ed25519 signature
     }



  Helixar                 Expires 26 September 2026               [Page 5]


  Internet-Draft           HDP Agentic Delegation               March 2026


                    Figure 1: HDP Token Top-Level Structure

  3.1.  Header

     The header object carries token lifecycle and session binding fields.

     {
       "token_id"        : "550e8400-e29b-41d4-a716-446655440000",
       "issued_at"       : 1711483200000,
       "expires_at"      : 1711569600000,
       "session_id"      : "sess-20260326-abc123",
       "version"         : "0.1",
       "parent_token_id" : "..."     // OPTIONAL: re-authorization linkage
     }

     token_id:  REQUIRED.  UUID v4.  Unique identifier for this token.

     issued_at:  REQUIRED.  Unix milliseconds.  Time of issuance.

     expires_at:  REQUIRED.  Unix milliseconds.  Token MUST NOT be
        accepted after this time.  Default lifetime is 24 hours.

     session_id:  REQUIRED.  Opaque string.  Established out-of-band
        between issuer and agent framework before token issuance.
        Provides replay defense: a token is only valid within the session
        for which it was issued.

     version:  REQUIRED.  MUST equal the value of the top-level hdp field.

     parent_token_id:  OPTIONAL.  If present, identifies the token this
        token supersedes in a re-authorization chain.  See Section 6.

  3.2.  Principal

     The principal object identifies the authorizing human.  It MUST
     contain id and id_type.  All other fields are OPTIONAL.

     {
       "id"             : "usr_alice_opaque",
       "id_type"        : "opaque",
       "display_name"   : "Alice Chen",
       "poh_credential" : "...",
       "metadata"       : {}
     }

     The id_type field MUST be one of the following registered values, or
     a custom string prefixed with x-:




  Helixar                 Expires 26 September 2026               [Page 6]


  Internet-Draft           HDP Agentic Delegation               March 2026


     *  opaque: Application-defined identifier.  No resolution semantics
        are implied.

     *  email: RFC 5321 email address.

     *  uuid: RFC 4122 UUID.

     *  did: W3C Decentralized Identifier [W3C.DID].  DID resolution is
        application- defined and not required by this protocol.

     *  poh: A Proof-of-Humanity credential identifier.  Verification
        semantics are application-defined; see Section 9.3.

     HDP does not mandate any specific identity model.  The did id_type is
     available for deployments with existing DID infrastructure; it is not
     required.

  3.3.  Scope

     The scope object records what the human authorized.  It is signed as
     part of the root signature and MUST NOT be modified after issuance.

     {
       "intent"               : "Analyze Q1 sales data and produce a report.",
       "authorized_tools"     : ["database_read", "file_write"],
       "authorized_resources" : ["db://sales/q1-2026"],
       "data_classification"  : "confidential",
       "network_egress"       : false,
       "persistence"          : true,
       "max_hops"             : 3
     }

     intent:  REQUIRED.  Natural language description of the authorized
        task.  Free-form string.  This is the human-readable authorization
        statement.

     authorized_tools:  OPTIONAL.  Array of tool identifiers the principal
        has explicitly authorized.  Enforcement is application-defined.

     authorized_resources:  OPTIONAL.  Array of resource identifiers
        (URIs, paths, etc.) the principal has authorized access to.

     data_classification:  REQUIRED.  One of: public, internal,
        confidential, restricted.  Expresses the sensitivity level of data
        the agent is authorized to access.

     network_egress:  REQUIRED.  Boolean.  Whether the agent is authorized
        to make outbound network requests.



  Helixar                 Expires 26 September 2026               [Page 7]


  Internet-Draft           HDP Agentic Delegation               March 2026


     persistence:  REQUIRED.  Boolean.  Whether the agent is authorized to
        write persistent state.

     max_hops:  OPTIONAL.  Positive integer.  Maximum number of delegation
        hops permitted.  Verification MUST reject tokens whose chain
        length exceeds this value.

     HDP does not mandate a central taxonomy for intent, authorized_tools,
     or authorized_resources.  These are self-described by the issuer.
     Semantic validation of agent actions against declared scope is an
     application-layer concern.

  3.4.  Chain

     The chain array is append-only.  Each element records a single
     delegation event (hop).  The array is empty at issuance and grows as
     the token passes through agents.  Agents MUST NOT remove or modify
     existing entries.

     {
       "seq"               : 1,
       "agent_id"          : "orchestrator-v2",
       "agent_type"        : "orchestrator",
       "agent_fingerprint" : "sha256:abc123...",
       "timestamp"         : 1711483260000,
       "action_summary"    : "Decompose analysis task; delegate to sub-agents.",
       "parent_hop"        : 0,
       "hop_signature"     : "<base64url-encoded Ed25519 signature>"
     }

     seq:  REQUIRED.  Positive integer.  Sequential index, starting at 1.
        MUST be exactly one greater than the previous hop's seq.  Gaps in
        sequence are a protocol violation.

     agent_id:  REQUIRED.  Identifier of the agent adding this hop.

     agent_type:  REQUIRED.  One of: orchestrator, sub-agent, tool-
        executor, custom.

     agent_fingerprint:  OPTIONAL.  Model or binary fingerprint for the
        acting agent.

     timestamp:  REQUIRED.  Unix milliseconds.  Time of hop extension.

     action_summary:  REQUIRED.  Human-readable description of the action
        this agent intends to take.

     parent_hop:  REQUIRED.  Non-negative integer.  Index of the hop that



  Helixar                 Expires 26 September 2026               [Page 8]


  Internet-Draft           HDP Agentic Delegation               March 2026


        triggered this delegation, where 0 indicates the root (human)
        authorization.

     hop_signature:  REQUIRED.  Base64url-encoded Ed25519 signature.  See
        Section 4.2.  Absence is a protocol violation per Rule 6 of
        Section 4.3.

  3.5.  Signature

     The signature object carries the root signature computed by the
     issuer.

     {
       "kid"   : "alice-signing-key-v1",
       "alg"   : "Ed25519",
       "value" : "<base64url-encoded Ed25519 signature over canonical JSON>"
     }

     The alg field MUST be Ed25519 for HDP v0.1.  The kid field SHOULD be
     used by verifiers to identify the correct public key when multiple
     keys are in circulation.

  4.  Cryptographic Signing

  4.1.  Root Signature

     The root signature is computed by the issuer at token creation time.
     It covers the token's header, principal, and scope , the fields that
     constitute the human authorization event.

     The signing procedure is:

     1.  Construct the unsigned token object containing the hdp, header,
         principal, scope, and chain (empty array at issuance) fields.

     2.  Serialize the object to canonical JSON using RFC 8785 [RFC8785]
         (JSON Canonicalization Scheme).  This ensures deterministic byte
         representation across implementations and platforms.

     3.  Compute the Ed25519 [RFC8032] signature over the canonical JSON
         bytes using the issuer's private key.

     4.  Encode the signature bytes as base64url [RFC4648] (no padding).

     5.  Attach the signature object (kid, alg, value) to the token.






  Helixar                 Expires 26 September 2026               [Page 9]


  Internet-Draft           HDP Agentic Delegation               March 2026


     The signature field itself MUST NOT be included in the canonical JSON
     payload before signing.  The signed payload is deterministically
     recoverable by stripping the signature field from the complete token
     and re-serializing with RFC 8785.

  4.2.  Hop Signature

     Each hop MUST carry a hop_signature.  This signature binds the new
     hop record to the entire accumulated delegation history and to the
     root signature, making retroactive chain modification detectable.

     The hop signing procedure is:

     1.  Construct the new hop record (all fields except hop_signature).

     2.  Build the signing payload as a JSON array: [hop_1, hop_2, ...,
         hop_(n-1), new_hop_unsigned] where hop_1 through hop_(n-1) are
         the previously signed hops (WITH their hop_signature fields) and
         new_hop_unsigned is the new hop record WITHOUT its hop_signature.

     3.  Prepend the root signature value (base64url string) to the array
         as its first element: [root_sig_value, hop_1, ...,
         new_hop_unsigned].  This chains the hop signature to the root.

     4.  Serialize the array to canonical JSON per RFC 8785.

     5.  Compute the Ed25519 signature over the canonical JSON bytes using
         the extending agent's private key.

     6.  Encode as base64url and attach as the hop_signature field on the
         new hop record.

     7.  Append the signed hop to the token's chain array.

     The asymmetry between previously-signed hops (WITH hop_signature) and
     the new hop (WITHOUT hop_signature) in step 2 is intentional and
     critical.  The verifier MUST reconstruct this exact payload structure
     when verifying each hop.  See Section 5.

  4.3.  Chain Integrity Rules

     The following rules govern chain construction and MUST be enforced by
     both extenders and verifiers:

     1.  Hop seq values MUST start at 1 and increment by exactly 1.  No
         gaps are permitted.

     2.  Existing hop records MUST NOT be modified or removed.



  Helixar                 Expires 26 September 2026              [Page 10]


  Internet-Draft           HDP Agentic Delegation               March 2026


     3.  A hop's parent_hop MUST reference a valid prior hop index (0 for
         the root human authorization, or the seq value of a prior hop).

     4.  If scope.max_hops is set, the chain length MUST NOT exceed it.  A
         token with a full chain MUST NOT be extended.

     5.  Each hop's timestamp SHOULD be monotonically non-decreasing.

     6.  The hop_signature field MUST be present on every hop.  A hop
         without a hop_signature is a protocol violation and MUST cause
         verification to fail.

  5.  Verification Pipeline

     A verifier MUST execute the following seven steps in order.  A
     failure at any step MUST cause immediate rejection with an
     appropriate error.  The verifier MUST NOT proceed to subsequent steps
     after a failure.

     1.  *Version check.* The hdp field MUST contain a recognized protocol
         version string.  For this specification, the only recognized
         value is "0.1".

     2.  *Expiry check.* The token's header.expires_at MUST be strictly
         greater than the current time.  Expired tokens MUST be rejected.

     3.  *Root signature verification.* Reconstruct the canonical JSON
         payload by stripping the signature field and serializing the
         remaining token object per RFC 8785.  Verify the Ed25519
         signature in signature.value against this payload using the
         issuer's public key.  A failure indicates tampering with the
         header, principal, or scope.

     4.  *Hop sequence integrity.* For each hop in chain, verify that
         hop.seq == (index + 1).  Any gap or duplication MUST cause
         rejection.

     5.  *Hop signature verification.* For each hop at index i:

         a.  Verify that hop_signature is present.  Absence MUST cause
             rejection.

         b.  Reconstruct the signing payload as described in Section 4.2,
             using the hops at indices 0...(i-1) with their signatures,
             plus the hop at index i without its hop_signature, prepended
             by the root signature value.





  Helixar                 Expires 26 September 2026              [Page 11]


  Internet-Draft           HDP Agentic Delegation               March 2026


         c.  Serialize the payload per RFC 8785 and verify the
             hop_signature against the issuer's public key (the same key
             used for the root signature in HDP v0.1).

     6.  *max_hops check.* If scope.max_hops is defined, the length of
         chain MUST NOT exceed it.

     7.  *Session binding check.* The token's header.session_id MUST
         exactly match the session_id provided by the verifying
         application.  This prevents token replay across sessions.  See
         Section 10.4.

     An optional eighth step MAY be performed if the application has
     registered a Proof-of-Humanity verifier: if principal.poh_credential
     is present and a verifier callback is configured, the credential MUST
     be validated by that callback.  See Section 9.3.

     Verification is fully offline.  Steps 1 through 7 require only the
     issuer's Ed25519 public key and the current session identifier.  No
     network call, registry lookup, or third-party contact is required at
     any step.

  6.  Re-Authorization

     Long-running or streaming sessions may exhaust the max_hops limit,
     require scope expansion, or encounter situations where a high-risk
     action warrants fresh human confirmation.  In these cases, the issuer
     (acting on behalf of the human principal) issues a new token that
     supersedes the original.

     Re-authorization is indicated by setting header.parent_token_id to
     the token_id of the token being superseded.  This field MUST be set
     before computing the root signature, so the parentage link is
     cryptographically covered by the new token's root signature.

     A re-authorized token:

     *  Has a new token_id, issued_at, and expires_at.

     *  Inherits session_id, principal, and scope from the original unless
        explicitly overridden.

     *  Starts with an empty chain (delegation count resets).

     *  Records parent_token_id pointing to the original, creating an
        auditable lineage of scope evolution.





  Helixar                 Expires 26 September 2026              [Page 12]


  Internet-Draft           HDP Agentic Delegation               March 2026


     Verifiers that require re-authorization chain traversal SHOULD retain
     all tokens in a session and verify the full parent_token_id linkage.

  7.  Multi-Principal Delegation

     HDP v0.1 supports one principal per token.  Joint authorization by
     multiple humans is achieved by sequential chaining: Human A issues
     token T1; Human B issues token T2 with parent_token_id equal to T1's
     token_id.  Each token is independently signed with its issuer's key.

     To verify a multi-principal chain, the verifier MUST:

     1.  Verify each token individually against its issuer's public key
         using the standard 7-step pipeline.

     2.  Verify that T[i].header.parent_token_id == T[i-1].header.token_id
         for all i > 0.

     3.  Verify that all tokens in the chain share the same session_id.

     This pattern provides joint authorization auditably without requiring
     a threshold signature scheme.  Each principal's authorization is a
     distinct signed artifact.  A future version of HDP (v0.2) is planned
     to introduce simultaneous multi- signature primitives using threshold
     signature schemes.

  8.  Transport

  8.1.  HTTP Header: X-HDP-Token

     HDP tokens MAY be transmitted in HTTP requests and responses using
     the X-HDP-Token header.  The header value is the base64url encoding
     (RFC 4648, no padding) of the UTF-8 JSON serialization of the
     complete token object.

     POST /api/task HTTP/1.1
     Host: agent.example.com
     X-HDP-Token: eyJoZHAiOiIwLjEiLCJoZWFkZXIiOnsi...
     Content-Type: application/json

                   Figure 2: X-HDP-Token HTTP Header Example

     Implementations MUST NOT include tokens in URL query parameters, as
     this exposes sensitive data in server logs and browser history.







  Helixar                 Expires 26 September 2026              [Page 13]


  Internet-Draft           HDP Agentic Delegation               March 2026


  8.2.  Token by Reference: X-HDP-Token-Ref

     When token size is a concern (e.g., large chains), the token MAY be
     stored server-side and referenced by its token_id using the X-HDP-
     Token-Ref header.

     POST /api/task HTTP/1.1
     Host: agent.example.com
     X-HDP-Token-Ref: 550e8400-e29b-41d4-a716-446655440000

                 Figure 3: X-HDP-Token-Ref HTTP Header Example

     Implementations using token-by-reference MUST secure the token store
     and use transport-layer security (TLS) for all reference resolution.

  8.3.  Key Distribution: Well-Known Endpoint

     Issuers that wish to publish their Ed25519 public keys for automated
     discovery SHOULD serve a JSON document at /.well-known/hdp-keys.json
     with the following structure:

     {
       "keys": [
         {
           "kid" : "alice-signing-key-v1",
           "alg" : "Ed25519",
           "pub" : "<base64url-encoded 32-byte Ed25519 public key>"
         }
       ]
     }

     This format is intentionally minimal.  Implementations MAY extend it
     with additional metadata.  The alg field MUST be "Ed25519" for HDP
     v0.1 keys.  Consumers MUST reject entries with unrecognized alg
     values.  Consumers MUST validate that the decoded public key is
     exactly 32 bytes.

  9.  Privacy Considerations

  9.1.  Minimum-Disclosure Principal Fields

     The principal object may contain PII (email address, display name).
     Issuers SHOULD apply the principle of minimum disclosure when
     constructing tokens that will traverse multiple agents.
     Specifically:






  Helixar                 Expires 26 September 2026              [Page 14]


  Internet-Draft           HDP Agentic Delegation               March 2026


     *  Use id_type: "opaque" with an application-internal identifier
        rather than embedding the user's email address in tokens that will
        be sent to third-party agents.

     *  Omit display_name when the receiving agent does not require a
        human-readable identity.

     The token structure separates the identity fields (principal) from
     the audit-relevant fields (header, scope, chain).  Implementations
     MAY strip the principal object when forwarding tokens to agents that
     do not require principal identity, while preserving the integrity of
     the signature chain.  Note that stripping principal invalidates the
     root signature; stripped tokens MUST be clearly marked as audit-only
     records and MUST NOT be presented for signature verification.

  9.2.  Data Retention and the Right to Erasure

     HDP tokens may constitute personal data under applicable privacy
     regulations (e.g., GDPR Article 4(1)) when the principal.id or
     principal.display_name fields contain directly or indirectly
     identifying information.

     Implementations SHOULD:

     *  Store tokens with explicit retention periods derived from
        header.expires_at.

     *  Provide deletion mechanisms that remove stored tokens upon erasure
        requests.

     *  Use opaque identifiers in principal.id where possible, maintaining
        a separate mapping that can be destroyed independently of the
        token audit log.

  9.3.  Proof of Humanity

     The optional principal.poh_credential field MAY carry a credential
     attesting that the principal is a human (e.g., a Worldcoin World ID
     proof, a CAPTCHA session token, or a biometric attestation
     identifier).  The HDP protocol does not define the semantics of this
     field; verification is entirely application-defined.

     When a PoH verifier is configured, the verification pipeline MUST
     validate the credential as the final step (after session binding) and
     MUST reject the token if validation fails.  The verifier callback
     SHOULD be idempotent and SHOULD NOT have side effects.





  Helixar                 Expires 26 September 2026              [Page 15]


  Internet-Draft           HDP Agentic Delegation               March 2026


  10.  Security Considerations

  10.1.  Threat Model

     HDP is designed to provide provenance and tamper evidence, not
     runtime enforcement.  An agent that exceeds its declared scope is
     still a bad actor , HDP creates an evidence trail, not a capability
     boundary.  Applications requiring runtime enforcement MUST implement
     it at the application layer using the HDP token as audit input.

  10.2.  Token Forgery

     A forged token , one whose header, principal, or scope fields do not
     match the original issuance , will fail Step 3 of the verification
     pipeline (root signature check).  The security of this step relies on
     the unforgeability of Ed25519 signatures and the collision resistance
     of SHA-512 (used internally by Ed25519).  An attacker who does not
     possess the issuer's private key cannot produce a valid root
     signature for a modified token.

  10.3.  Chain Tampering

     Modification of any hop in chain , including removal, reordering, or
     field modification , will cause hop signature verification (Step 5)
     to fail for the tampered hop and all subsequent hops, because each
     hop signature covers all previous hops.  Insertion of a fabricated
     hop will similarly fail unless the attacker possesses the issuer's
     private key.

  10.4.  Replay Attack Defense

     HDP provides two orthogonal replay defenses:

     1.  *Expiry.* Tokens are short-lived (expires_at, 24h default).  An
         expired token is rejected at Step 2 regardless of network
         conditions.

     2.  *Session binding.* The token carries the session_id established
         out-of-band between issuer and verifier.  A token is valid only
         within the session for which it was issued.  Even a non-expired
         token cannot be replayed across sessions.

     Together, these defenses ensure that a stolen token is useful to an
     attacker only within the original session and only before it expires.
     Applications with high security requirements SHOULD use short token
     lifetimes (minutes, not hours).





  Helixar                 Expires 26 September 2026              [Page 16]


  Internet-Draft           HDP Agentic Delegation               March 2026


  10.5.  Prompt Injection

     Prompt injection attacks attempt to cause an agent to act as if it
     received instructions from a legitimate principal, when in fact the
     instructions originate from adversarial content in the agent's
     environment (e.g., a malicious web page or document).  HDP mitigates
     but does not fully prevent this attack.

     An HDP-aware agent SHOULD refuse to extend a token's chain with an
     action_summary that contradicts the token's scope.intent.  However,
     the protocol cannot enforce this semantically , the comparison
     between action intent and token scope is application-defined.

     The primary mitigation HDP provides is that injected actions MUST be
     recorded in the chain to be valid, creating an auditable record that
     the action occurred.  Post-hoc detection of prompt injection attacks
     is thereby supported.

  10.6.  Key Management

     The security of all HDP guarantees depends on the confidentiality of
     the issuer's Ed25519 private key.  Implementations MUST:

     *  Store private keys in a secrets manager, HSM, or equivalent secure
        enclave.  Private keys MUST NOT be stored in source code,
        configuration files, or environment variables in production.

     *  Use distinct key pairs per environment (development, staging,
        production).

     *  Support key rotation by issuing new tokens with a new kid while
        maintaining the old key in the verifier's registry until all
        tokens signed with it have expired.

  10.7.  Offline Verification Guarantee

     HDP makes a strong architectural guarantee: a correct implementation
     of the 7-step verification pipeline requires no network calls, no
     registry lookups, and no third-party contact.  The complete trust
     state required for verification is:

     *  The issuer's Ed25519 public key (32 bytes).

     *  The current session identifier (string).

     *  The current time (for expiry checking).





  Helixar                 Expires 26 September 2026              [Page 17]


  Internet-Draft           HDP Agentic Delegation               March 2026


     This guarantee enables HDP verification in air-gapped environments,
     edge deployments with intermittent connectivity, and latency-
     sensitive contexts where a network round-trip before every action is
     unacceptable.

  11.  IANA Considerations

  11.1.  HTTP Header Field Registration

     This document requests registration of the following HTTP header
     fields in the "Hypertext Transfer Protocol (HTTP) Field Name
     Registry" maintained at <https://www.iana.org/assignments/http-
     fields/>.

     Header Field Name:  X-HDP-Token

     Status:  provisional

     Reference:  This document, Section 8.1

     Comments:  Carries a base64url-encoded HDP token for agentic
        delegation provenance.

     Header Field Name:  X-HDP-Token-Ref

     Status:  provisional

     Reference:  This document, Section 8.2

     Comments:  Carries the UUID token_id of an HDP token stored by
        reference.

  11.2.  Media Type Registration

     This document requests registration of the media type application/
     hdp-token+json in the "Media Types" registry for use in contexts
     where the Content-Type of an HDP token must be explicitly identified.

  12.  Comparison with Related Work

  12.1.  IPP (draft-haberkamp-ipp-00)

     The Intent Provenance Protocol [I-D.haberkamp-ipp] and HDP address
     the same root problem with different architectural trade-offs.  The
     key differences are:






  Helixar                 Expires 26 September 2026              [Page 18]


  Internet-Draft           HDP Agentic Delegation               March 2026


     1.  *Revocation model.* IPP requires agents to poll a central
         revocation registry at a configurable endpoint before every
         action, with a recommended interval of 5,000 milliseconds.  If
         the registry is unreachable, agents cannot safely act.  HDP uses
         short-lived tokens with session_id binding as the revocation
         mechanism; no registry polling is required at any point.

     2.  *Trust anchor.* IPP tokens contain a genesis_seal , a
         cryptographic artifact linking every token to the specification
         author's public key at https://ipp.khsovereign.com/keys/
         founding_public.pem.  Self-hosted IPP deployments are
         cryptographically bound to this third-party key.  HDP tokens
         carry no genesis seal and no spec-level attribution; any
         organization can issue and verify HDP tokens without anchoring to
         a third party.

     3.  *Identity model.* IPP mandates W3C DID Core-conformant principal
         identifiers.  HDP supports id_type: "opaque" as a first-class
         option, making DID infrastructure optional rather than required.

     These are design choices, not defects.  Deployments with reliable
     connectivity to a central registry, existing DID infrastructure, and
     a requirement for mid-chain revocation may prefer IPP.  Deployments
     that prioritize offline operability, self-sovereignty, and minimal
     infrastructure may prefer HDP.

  12.2.  OAuth 2.0 Token Exchange (RFC 8693)

     OAuth 2.0 Token Exchange [RFC8693] defines a mechanism for exchanging
     one security token for another, including delegation and
     impersonation use cases.  HDP and RFC 8693 are complementary rather
     than competing: RFC 8693 governs access token issuance and delegation
     in an OAuth 2.0 authorization server context, while HDP governs the
     provenance record that travels with an agentic task regardless of the
     authentication mechanism used.

     HDP tokens do not replace OAuth access tokens.  An agent framework
     MAY use OAuth 2.0 for resource authorization and HDP for delegation
     provenance simultaneously.

  12.3.  JSON Web Token (RFC 7519)

     JSON Web Token [RFC7519] provides a general-purpose signed claims
     format.  HDP differs from JWT in three respects:

     *  HDP tokens carry an append-only, multi-party-signed delegation
        chain (chain) that has no equivalent in the JWT standard claims
        set.



  Helixar                 Expires 26 September 2026              [Page 19]


  Internet-Draft           HDP Agentic Delegation               March 2026


     *  HDP uses RFC 8785 canonical JSON for signing payloads, rather than
        the base64url-encoded header.payload convention used by JWS (RFC
        7515).  This allows direct JSON manipulation without base64
        decoding.

     *  HDP's verification pipeline is domain-specific to agentic
        delegation (session binding, hop verification, max_hops) rather
        than general-purpose.

  12.4.  UCAN (User Controlled Authorization Networks)

     UCAN defines a capability-based authorization token system using JWT
     with chained delegation.  HDP and UCAN share the concept of
     delegation chains but differ significantly in scope: UCAN is a
     general capability authorization system, while HDP is specifically a
     provenance record for human-authorized agentic tasks.  HDP makes no
     claims about capability enforcement; UCAN tokens carry executable
     capabilities that are enforced by receiving systems.

  13.  Normative References

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

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

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

  14.  Informative References






  Helixar                 Expires 26 September 2026              [Page 20]


  Internet-Draft           HDP Agentic Delegation               March 2026


     [I-D.haberkamp-ipp]
                Haberkamp, M., "Intent Provenance Protocol (IPP)", Work in
                Progress, Internet-Draft, draft-haberkamp-ipp-00, 2024,
                <https://datatracker.ietf.org/doc/html/draft-haberkamp-
                ipp-00>.

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

     [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/rfc/rfc7519>.

     [W3C.DID]  Sporny, M., Longley, D., Sabadello, M., Reed, D., Steele,
                O., and C. Allen, "Decentralized Identifiers (DIDs) v1.0",
                W3C Recommendation did-core, July 2022,
                <https://www.w3.org/TR/did-core/>.

     [HDP-SPEC] Helixar Limited, "Human Delegation Provenance Protocol
                v0.1 Specification", 2026, <https://helixar.ai/labs/hdp>.

     [HDP-IMPL] Helixar Limited, "HDP TypeScript Reference
                Implementation", 2026,
                <https://github.com/Helixar-AI/HDP>.

  Appendix A.  Complete Token Example

     The following is a complete HDP token with a two-hop delegation
     chain, for illustrative purposes.  Signature values are truncated.

     {
       "hdp": "0.1",
       "header": {
         "token_id"   : "550e8400-e29b-41d4-a716-446655440000",
         "issued_at"  : 1711483200000,
         "expires_at" : 1711569600000,
         "session_id" : "sess-20260326-abc123",
         "version"    : "0.1"
       },
       "principal": {
         "id"           : "usr_alice_opaque",
         "id_type"      : "opaque",
         "display_name" : "Alice Chen"
       },
       "scope": {
         "intent"              : "Analyze Q1 sales data and produce a report.",



  Helixar                 Expires 26 September 2026              [Page 21]


  Internet-Draft           HDP Agentic Delegation               March 2026


         "authorized_tools"    : ["database_read", "file_write"],
         "data_classification" : "confidential",
         "network_egress"      : false,
         "persistence"         : true,
         "max_hops"            : 3
       },
       "chain": [
         {
           "seq"            : 1,
           "agent_id"       : "orchestrator-v2",
           "agent_type"     : "orchestrator",
           "timestamp"      : 1711483260000,
           "action_summary" : "Decompose analysis task; delegate to sub-agents.",
           "parent_hop"     : 0,
           "hop_signature"  : "base64url-sig-1..."
         },
         {
           "seq"            : 2,
           "agent_id"       : "sql-agent-v1",
           "agent_type"     : "sub-agent",
           "timestamp"      : 1711483320000,
           "action_summary" : "Execute read query against sales database.",
           "parent_hop"     : 1,
           "hop_signature"  : "base64url-sig-2..."
         }
       ],
       "signature": {
         "kid"   : "alice-signing-key-v1",
         "alg"   : "Ed25519",
         "value" : "base64url-root-sig..."
       }
     }

  Change Log

     This section will be removed before publication as an RFC.

     draft-helixar-hdp-agentic-delegation-00:  Initial submission.
        Specifies HDP v0.1 token structure, signing, verification
        pipeline, re-authorization, multi-principal delegation, transport,
        privacy considerations, and security analysis.

  Author's Address

     Helixar Limited
     Helixar Limited
     Email: protocol@helixar.ai
     URI:   https://helixar.ai



  Helixar                 Expires 26 September 2026              [Page 22]


name: draft-yakung-oauth-agent-attestation
rev: 00
title: Agent Credential Attestation Protocol (ACAP)
time: 2026-03-26T07:45:56Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-27T07:45:56Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Policy/governance"]
tags: []
fetched_at: 2026-05-22T09:24:41.698259+00:00
source: ietf
abstract:
  This document defines the Agent Credential Attestation Protocol
     (ACAP), a cryptographic credentialing protocol for autonomous AI
     agent pipelines.  An ACAP credential is a short-lived JSON Web Token
     (JWT) signed with RS256 that carries scope-limited permissions
     together with a SHA-256 hash of the original human instruction that
     initiated the task.  Credentials may be delegated to child agents;
     each delegation narrows scope, cannot outlive its parent, increments
     a delegation depth counter, and extends a tamper-evident chain of
     token identifiers.  Every lifecycle event is recorded in an append-
     only, hash-chained audit log.

     This document specifies the credential format, issuance rules,
     delegation rules, verification algorithm, revocation semantics,
     human-in-the-loop approval protocol, and audit log structure.

full_text:
  Network Working Group                                          C. Yakung
  Internet-Draft                                                    Attest
  Intended status: Informational                             26 March 2026
  Expires: 27 September 2026


                Agent Credential Attestation Protocol (ACAP)
                  draft-yakung-oauth-agent-attestation-00

  Abstract

     This document defines the Agent Credential Attestation Protocol
     (ACAP), a cryptographic credentialing protocol for autonomous AI
     agent pipelines.  An ACAP credential is a short-lived JSON Web Token
     (JWT) signed with RS256 that carries scope-limited permissions
     together with a SHA-256 hash of the original human instruction that
     initiated the task.  Credentials may be delegated to child agents;
     each delegation narrows scope, cannot outlive its parent, increments
     a delegation depth counter, and extends a tamper-evident chain of
     token identifiers.  Every lifecycle event is recorded in an append-
     only, hash-chained audit log.

     This document specifies the credential format, issuance rules,
     delegation rules, verification algorithm, revocation semantics,
     human-in-the-loop approval protocol, and audit log structure.

  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 27 September 2026.

  Copyright Notice

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




  Yakung                  Expires 27 September 2026               [Page 1]


  Internet-Draft                    ACAP                        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.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   3
       1.2.  What ACAP Adds  . . . . . . . . . . . . . . . . . . . . .   4
       1.3.  Relationship to Prior Art . . . . . . . . . . . . . . . .   5
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.  Credential Format . . . . . . . . . . . . . . . . . . . . . .   6
       4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   6
       4.2.  Standard JWT Claims . . . . . . . . . . . . . . . . . . .   7
       4.3.  ACAP Extension Claims . . . . . . . . . . . . . . . . . .   7
       4.4.  Concrete Examples . . . . . . . . . . . . . . . . . . . .   9
         4.4.1.  Root Credential Payload . . . . . . . . . . . . . . .   9
         4.4.2.  Delegated Credential Payload  . . . . . . . . . . . .   9
     5.  Scope Model . . . . . . . . . . . . . . . . . . . . . . . . .  10
       5.1.  Scope Entry Format  . . . . . . . . . . . . . . . . . . .  10
       5.2.  Wildcard Rules  . . . . . . . . . . . . . . . . . . . . .  10
       5.3.  NormaliseScope  . . . . . . . . . . . . . . . . . . . . .  10
       5.4.  IsSubset Algorithm  . . . . . . . . . . . . . . . . . . .  10
     6.  Issuance  . . . . . . . . . . . . . . . . . . . . . . . . . .  11
       6.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  11
       6.2.  Input Validation  . . . . . . . . . . . . . . . . . . . .  11
       6.3.  Intent Hash Computation . . . . . . . . . . . . . . . . .  12
       6.4.  Identifier Generation . . . . . . . . . . . . . . . . . .  12
       6.5.  TTL and Expiry  . . . . . . . . . . . . . . . . . . . . .  12
       6.6.  Root Credential Construction  . . . . . . . . . . . . . .  12
     7.  Delegation  . . . . . . . . . . . . . . . . . . . . . . . . .  13
       7.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  13
       7.2.  Input Validation  . . . . . . . . . . . . . . . . . . . .  13
       7.3.  Parent Token Verification . . . . . . . . . . . . . . . .  13
       7.4.  Scope Subset Enforcement  . . . . . . . . . . . . . . . .  14
       7.5.  Depth Limit . . . . . . . . . . . . . . . . . . . . . . .  14
       7.6.  Expiry Computation  . . . . . . . . . . . . . . . . . . .  14
       7.7.  Delegated Credential Construction . . . . . . . . . . . .  14
     8.  Verification  . . . . . . . . . . . . . . . . . . . . . . . .  15
       8.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  15
       8.2.  Verification Algorithm  . . . . . . . . . . . . . . . . .  15
       8.3.  Warnings vs. Hard Failures  . . . . . . . . . . . . . . .  16
     9.  Revocation  . . . . . . . . . . . . . . . . . . . . . . . . .  16
       9.1.  Semantics . . . . . . . . . . . . . . . . . . . . . . . .  16
       9.2.  Cascade Semantics . . . . . . . . . . . . . . . . . . . .  16



  Yakung                  Expires 27 September 2026               [Page 2]


  Internet-Draft                    ACAP                        March 2026


       9.3.  Revocation Store  . . . . . . . . . . . . . . . . . . . .  17
       9.4.  Lifetime Interaction  . . . . . . . . . . . . . . . . . .  17
     10. Human-in-the-Loop Approval  . . . . . . . . . . . . . . . . .  17
       10.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . .  17
       10.2.  Approval Lifecycle . . . . . . . . . . . . . . . . . . .  17
       10.3.  Approval Expiry  . . . . . . . . . . . . . . . . . . . .  18
       10.4.  Parent Token Re-verification . . . . . . . . . . . . . .  18
       10.5.  HITL Claims Propagation  . . . . . . . . . . . . . . . .  18
       10.6.  Multi-Tenant Isolation . . . . . . . . . . . . . . . . .  18
     11. Audit Log . . . . . . . . . . . . . . . . . . . . . . . . . .  18
       11.1.  Structure  . . . . . . . . . . . . . . . . . . . . . . .  18
       11.2.  Entry Hash Computation . . . . . . . . . . . . . . . . .  19
       11.3.  Event Types  . . . . . . . . . . . . . . . . . . . . . .  19
       11.4.  Audit Entry Fields . . . . . . . . . . . . . . . . . . .  20
       11.5.  Append-Only Enforcement  . . . . . . . . . . . . . . . .  20
       11.6.  Log Verification . . . . . . . . . . . . . . . . . . . .  20
     12. Security Considerations . . . . . . . . . . . . . . . . . . .  21
       12.1.  Prompt Injection . . . . . . . . . . . . . . . . . . . .  21
       12.2.  Replay Attacks . . . . . . . . . . . . . . . . . . . . .  21
       12.3.  Scope Creep  . . . . . . . . . . . . . . . . . . . . . .  21
       12.4.  Clock Skew . . . . . . . . . . . . . . . . . . . . . . .  21
       12.5.  Key Management . . . . . . . . . . . . . . . . . . . . .  21
       12.6.  Credential Store Integrity . . . . . . . . . . . . . . .  21
       12.7.  Audit Log Integrity  . . . . . . . . . . . . . . . . . .  22
     13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
     14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
       14.1.  Normative References . . . . . . . . . . . . . . . . . .  24
       14.2.  Informative References . . . . . . . . . . . . . . . . .  24
     Appendix A.  Summary of Constants . . . . . . . . . . . . . . . .  25
     Appendix B.  Implementation Status  . . . . . . . . . . . . . . .  25
     Appendix C.  Data Model . . . . . . . . . . . . . . . . . . . . .  25
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  27
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  27

  1.  Introduction

  1.1.  Problem Statement

     Contemporary authorization frameworks such as OAuth 2.0 [RFC6749] and
     OpenID Connect [OIDC] were designed for human-initiated, single-hop
     delegations: a resource owner grants a client access on behalf of
     themselves.  AI agent pipelines violate this assumption in several
     important ways.








  Yakung                  Expires 27 September 2026               [Page 3]


  Internet-Draft                    ACAP                        March 2026


     First, an agent pipeline may involve an arbitrary number of hops.  A
     root agent receives a task from a human, decomposes it, and delegates
     sub-tasks to child agents, which may themselves delegate further.
     OAuth's two-party model has no native representation for this; each
     hop requires a fresh grant cycle or an out-of-band trust agreement.

     Second, the originating human instruction -- the intent -- is not
     cryptographically bound to any OAuth token.  An agent can receive a
     token whose original purpose has been transformed or corrupted by
     prompt injection at an intermediate step, and the verifying party has
     no way to detect this.

     Third, scope in OAuth is flat and is not guaranteed to narrow
     monotonically through a delegation chain.  A child agent can, in
     principle, present its parent token to a different authorization
     server and request broader access.  Nothing in the wire format
     prevents scope creep.

     Fourth, the delegation graph is not natively recorded.  OAuth
     introspection surfaces information about a single token; it provides
     no view of the full task ancestry.

     Recent IETF work -- notably the WIMSE working group [WIMSE] and the
     draft on AI agents acting on behalf of users [OBO01] -- acknowledges
     these gaps but stops short of specifying a compact, self-contained
     credential format with cryptographically enforced monotone scope
     reduction and intent binding.

  1.2.  What ACAP Adds

     ACAP addresses the gaps above as follows.

     Intent binding:  Every ACAP credential carries att_intent, a hex-
        encoded SHA-256 hash of the original UTF-8 instruction text.  This
        value is set at issuance and propagated unchanged through every
        delegation.  A verifier can confirm that a presented credential
        descends from a specific human instruction by independently
        computing the hash.

     Monotone scope reduction:  At delegation time the issuer MUST verify
        that the child's requested scope is a subset of the parent's scope
        using the IsSubset algorithm defined in Section 5.  Any request
        that fails this check MUST be rejected.  Scope therefore only ever
        narrows; it can never widen through delegation.

     Depth-limited delegation:  Each credential carries att_depth, an





  Yakung                  Expires 27 September 2026               [Page 4]


  Internet-Draft                    ACAP                        March 2026


        integer that starts at 0 for a root credential and increments by 1
        at each delegation.  Depth is bounded above by MaxDelegationDepth
        (10).  A credential whose depth equals this limit MUST NOT be used
        as a parent for further delegation.

     Tamper-evident chain:  Each credential carries att_chain, an ordered
        list of JWT IDs from the root of the delegation tree to the
        current token.  The verifier checks that the chain length equals
        att_depth + 1 and that the final element equals the token's own
        jti.  Together these checks detect any tampering with the ancestry
        record.

     Lifetime containment:  A child credential's expiry is capped at the
        parent's expiry.  Concretely, exp = min(requested_exp,
        parent_exp).  This ensures that revoking a parent token
        effectively expires all descendants, even without an active
        revocation lookup.

     Cascade revocation:  The revocation store records revoked JTIs and
        cascades revocation to all descendants by inspecting the att_chain
        column in the credential store.  Revocation is permanent and takes
        precedence over token expiry.

     Append-only audit log:  Every issuance, delegation, verification,
        revocation, and expiry event is recorded in a hash-chained log.
        Each entry commits to the previous entry's hash, the event type,
        the JTI, and the timestamp, forming a tamper-evident record of all
        credential lifecycle events within a task tree.

  1.3.  Relationship to Prior Art

     ACAP is informed by but is not a profile of any existing
     specification.  The Agentic JWT (A-JWT) paper proposes delegation
     chains for AI agents but does not specify exact claim semantics,
     scope subset enforcement, or audit log structure.  The IETF draft
     [AGENTJWT] covers similar ground in the JWT format domain.  The draft
     [OBO01] addresses delegation in the OAuth authorization code flow
     context.  ACAP occupies a different point in the design space: it is
     a self-contained signed-token format with no external authorization
     server required at verification time.

  2.  Conventions and Definitions

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



  Yakung                  Expires 27 September 2026               [Page 5]


  Internet-Draft                    ACAP                        March 2026


  3.  Terminology

     Issuer:  The service that creates and signs ACAP credentials.  The
        Issuer holds an RSA private key and is identified by a URI
        recorded in the iss JWT claim.  A single Issuer MAY serve multiple
        task trees.

     Root Credential:  An ACAP credential whose att_depth is 0 and whose
        att_pid is absent.  A root credential is issued directly by the
        Issuer in response to a human principal's instruction.  Its
        att_chain contains exactly one element: its own jti.

     Delegated Credential:  An ACAP credential whose att_depth is greater
        than 0.  A delegated credential is derived from a parent
        credential and MUST have att_pid set to the parent's jti.  Its
        scope MUST be a subset of the parent's scope and its expiry MUST
        NOT exceed the parent's expiry.

     Task Tree:  The complete graph of credentials that share the same
        att_tid.  A task tree has exactly one root credential; all other
        credentials in the tree are delegated credentials descended from
        it.

     Intent Hash:  The value of the att_intent claim: a lowercase hex-
        encoded SHA-256 digest of the UTF-8 encoding of the original human
        instruction string.  The intent hash is set at root issuance and
        propagated unchanged to all descendants.

     Depth:  The integer value of att_depth.  Depth 0 identifies a root
        credential.  Each delegation increments depth by exactly 1.  The
        maximum permitted depth is MaxDelegationDepth (10).

     Chain:  The ordered list of JWT IDs in att_chain.  For a credential
        at depth D, the chain contains exactly D+1 elements: the root
        credential's jti at index 0, followed by each intermediate
        credential's jti in delegation order, with the current
        credential's jti at the final position (index D).

     Scope Entry:  A string of the form resource:action where resource and
        action are non-empty strings.  The wildcard character * MAY appear
        in either position.

  4.  Credential Format

  4.1.  Overview

     An ACAP credential is a JSON Web Token [RFC7519] with:




  Yakung                  Expires 27 September 2026               [Page 6]


  Internet-Draft                    ACAP                        March 2026


     *  Header: { "alg": "RS256", "typ": "JWT" }

     *  Payload: the claims defined in Section 4.2 and Section 4.3

     *  Signature: RS256 over the ASCII representation of the header and
        payload

     All implementations MUST use RS256 (RSASSA-PKCS1-v1_5 using SHA-256
     [RFC7518]) as the signing algorithm.  No other signing algorithm is
     permitted.

  4.2.  Standard JWT Claims

     The following standard JWT claims are used.  All are REQUIRED unless
     noted.

        +=======+=============+==========+============================+
        | Claim | Type        | Required | Description                |
        +=======+=============+==========+============================+
        | iss   | string      | REQUIRED | Issuer URI                 |
        +-------+-------------+----------+----------------------------+
        | sub   | string      | REQUIRED | Subject.  MUST be of the   |
        |       |             |          | form agent:{agent_id}      |
        +-------+-------------+----------+----------------------------+
        | iat   | NumericDate | REQUIRED | Issued-at time (Unix epoch |
        |       |             |          | seconds, UTC)              |
        +-------+-------------+----------+----------------------------+
        | exp   | NumericDate | REQUIRED | Expiry time (Unix epoch    |
        |       |             |          | seconds, UTC)              |
        +-------+-------------+----------+----------------------------+
        | jti   | string      | REQUIRED | JWT ID.  A UUID v4         |
        |       |             |          | [RFC9562] that uniquely    |
        |       |             |          | identifies this credential |
        +-------+-------------+----------+----------------------------+

                                    Table 1

     The sub claim MUST match the pattern ^agent:[A-Za-z0-9_\-]+$.
     Implementations MUST reject credentials whose sub does not begin with
     the literal prefix agent:.

  4.3.  ACAP Extension Claims

     All ACAP-specific claims are prefixed with att_.  Implementations
     MUST ignore unknown att_* claims to allow forward compatibility.






  Yakung                  Expires 27 September 2026               [Page 7]


  Internet-Draft                    ACAP                        March 2026


       +==============+===========+=============+=====================+
       | Claim        | Type      | Required    | Description         |
       +==============+===========+=============+=====================+
       | att_tid      | string    | REQUIRED    | Task tree           |
       |              | (UUID v4) |             | identifier          |
       +--------------+-----------+-------------+---------------------+
       | att_pid      | string    | CONDITIONAL | Parent credential   |
       |              | (UUID v4) |             | identifier          |
       +--------------+-----------+-------------+---------------------+
       | att_depth    | integer   | REQUIRED    | Delegation depth (0 |
       |              |           |             | for root)           |
       +--------------+-----------+-------------+---------------------+
       | att_scope    | array of  | REQUIRED    | Permission set      |
       |              | strings   |             |                     |
       +--------------+-----------+-------------+---------------------+
       | att_intent   | string    | REQUIRED    | SHA-256 of original |
       |              | (hex)     |             | instruction (64 hex |
       |              |           |             | chars)              |
       +--------------+-----------+-------------+---------------------+
       | att_chain    | array of  | REQUIRED    | Ordered list of     |
       |              | strings   |             | JTIs from root to   |
       |              |           |             | current             |
       +--------------+-----------+-------------+---------------------+
       | att_uid      | string    | REQUIRED    | Originating human   |
       |              |           |             | user identifier     |
       +--------------+-----------+-------------+---------------------+
       | att_hitl_req | string    | OPTIONAL    | HITL approval       |
       |              | (UUID v4) |             | request ID          |
       +--------------+-----------+-------------+---------------------+
       | att_hitl_uid | string    | OPTIONAL    | Identity of the     |
       |              |           |             | human who approved  |
       +--------------+-----------+-------------+---------------------+
       | att_hitl_iss | string    | OPTIONAL    | IdP issuer of the   |
       |              |           |             | approving human     |
       +--------------+-----------+-------------+---------------------+
       | att_idp_iss  | string    | OPTIONAL    | IdP issuer from     |
       |              |           |             | root OIDC session   |
       +--------------+-----------+-------------+---------------------+
       | att_idp_sub  | string    | OPTIONAL    | IdP subject from    |
       |              |           |             | root OIDC session   |
       +--------------+-----------+-------------+---------------------+
       | att_ack      | string    | OPTIONAL    | Agent binary        |
       |              |           |             | checksum digest     |
       +--------------+-----------+-------------+---------------------+

                                   Table 2





  Yakung                  Expires 27 September 2026               [Page 8]


  Internet-Draft                    ACAP                        March 2026


     att_pid MUST be present when att_depth > 0 and MUST be absent when
     att_depth == 0.

     att_tid, att_intent, and att_uid MUST be propagated unchanged through
     all delegations.

  4.4.  Concrete Examples

  4.4.1.  Root Credential Payload

     {
       "iss": "https://attest.example.com",
       "sub": "agent:inbox-agent-v2",
       "iat": 1742386800,
       "exp": 1742473200,
       "jti": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
       "att_tid": "f9e8d7c6-b5a4-3210-fedc-ba9876543210",
       "att_depth": 0,
       "att_scope": ["email:read", "email:draft"],
       "att_intent": "3b4c2a1f8e7d6c5b4a3f2e1d0c9b8a7f...",
       "att_chain": ["a1b2c3d4-e5f6-7890-abcd-ef1234567890"],
       "att_uid": "user:alice"
     }

     Note that att_pid is absent because this is a root credential.  The
     att_chain contains exactly one element -- the credential's own jti.

  4.4.2.  Delegated Credential Payload

     {
       "iss": "https://attest.example.com",
       "sub": "agent:summariser-agent-v1",
       "iat": 1742387100,
       "exp": 1742473200,
       "jti": "c3d4e5f6-a7b8-9012-cdef-012345678901",
       "att_tid": "f9e8d7c6-b5a4-3210-fedc-ba9876543210",
       "att_pid": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
       "att_depth": 1,
       "att_scope": ["email:read"],
       "att_intent": "3b4c2a1f8e7d6c5b4a3f2e1d0c9b8a7f...",
       "att_chain": [
         "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
         "c3d4e5f6-a7b8-9012-cdef-012345678901"
       ],
       "att_uid": "user:alice"
     }





  Yakung                  Expires 27 September 2026               [Page 9]


  Internet-Draft                    ACAP                        March 2026


  5.  Scope Model

  5.1.  Scope Entry Format

     A scope entry is a string conforming to the grammar:

     scope-entry = resource ":" action
     resource    = 1*( ALPHA / DIGIT / "_" / "-" / "*" )
     action      = 1*( ALPHA / DIGIT / "_" / "-" / "*" )

     Both resource and action MUST be non-empty.  Implementations MUST
     reject invalid scope entries at all stages: issuance, delegation, and
     verification.

  5.2.  Wildcard Rules

     The wildcard character * MAY appear as the entirety of either the
     resource or action component (or both).  Coverage rules:

     *  P covers C if P.resource equals * OR P.resource equals C.resource

     *  AND P.action equals * OR P.action equals C.action

     Consequently *:* covers every valid scope entry, email:* covers
     email:read, email:draft, etc.

  5.3.  NormaliseScope

     Before storing scope in any credential or comparing scopes,
     implementations MUST apply the NormaliseScope procedure:

     1.  Trim leading and trailing whitespace from each entry.

     2.  Remove any empty entries that result from trimming.

     3.  Remove duplicate entries, preserving the first occurrence.

     4.  Return the resulting list in insertion order.

  5.4.  IsSubset Algorithm











  Yakung                  Expires 27 September 2026              [Page 10]


  Internet-Draft                    ACAP                        March 2026


     function IsSubset(parentScope, childScope):
         for each entry CE in childScope:
             childEntry = ParseScope(CE)
             if childEntry is invalid:
                 return false
             covered = false
             for each entry PE in parentScope:
                 parentEntry = ParseScope(PE)
                 if parentEntry is invalid:
                     continue
                 if EntryCovers(parentEntry, childEntry):
                     covered = true
                     break
             if not covered:
                 return false
         return true

     function EntryCovers(parent, child):
         resourceOK = (parent.Resource == "*") OR
                      (parent.Resource == child.Resource)
         actionOK   = (parent.Action  == "*") OR
                      (parent.Action  == child.Action)
         return resourceOK AND actionOK

  6.  Issuance

  6.1.  Overview

     Issuance creates a root credential (depth 0) that anchors a new task
     tree.  The Issuer MUST perform all validation checks before
     constructing the credential.  The Issuer MUST sign the credential
     with its RSA private key using RS256.

  6.2.  Input Validation

     The Issuer MUST reject the issuance request if any of the following
     conditions hold:

     1.  agent_id is absent or empty.

     2.  user_id is absent or empty.

     3.  scope is absent or contains no entries.

     4.  Any entry in scope is not parseable as a valid scope entry.

     5.  instruction is absent or empty.




  Yakung                  Expires 27 September 2026              [Page 11]


  Internet-Draft                    ACAP                        March 2026


  6.3.  Intent Hash Computation

     The intent hash is computed as:

     att_intent = lowercase-hex( SHA-256( UTF-8-encode( instruction ) ) )

     The instruction string MUST be encoded as UTF-8 before hashing.  The
     resulting 32-byte SHA-256 digest MUST be encoded as 64 lowercase
     hexadecimal characters.  No canonicalization is applied to the
     instruction before hashing; the raw UTF-8 bytes are hashed as-is.

  6.4.  Identifier Generation

     The Issuer MUST generate two UUID v4 [RFC9562] values at issuance:

     *  jti: the unique identifier for this credential.

     *  att_tid: the task tree identifier.

     Both values MUST be generated using a cryptographically secure random
     source.

  6.5.  TTL and Expiry

     1.  If ttl_seconds is zero, the TTL defaults to DefaultTTLSeconds
         (3600 seconds).

     2.  If ttl_seconds is negative, the issuance MUST be rejected.

     3.  If ttl_seconds exceeds MaxTTLSeconds (86400 seconds), the TTL is
         capped at MaxTTLSeconds.

     4.  exp = iat + ttl_seconds (after applying the rules above).

  6.6.  Root Credential Construction

               +============+==================================+
               | Field      | Value                            |
               +============+==================================+
               | iss        | Issuer URI                       |
               +------------+----------------------------------+
               | sub        | "agent:" + agent_id              |
               +------------+----------------------------------+
               | iat        | Current UTC time                 |
               +------------+----------------------------------+
               | exp        | iat + ttl                        |
               +------------+----------------------------------+
               | jti        | Freshly generated UUID v4        |



  Yakung                  Expires 27 September 2026              [Page 12]


  Internet-Draft                    ACAP                        March 2026


               +------------+----------------------------------+
               | att_tid    | Freshly generated UUID v4        |
               +------------+----------------------------------+
               | att_pid    | Absent                           |
               +------------+----------------------------------+
               | att_depth  | 0                                |
               +------------+----------------------------------+
               | att_scope  | NormaliseScope(scope)            |
               +------------+----------------------------------+
               | att_intent | hex(SHA-256(UTF-8(instruction))) |
               +------------+----------------------------------+
               | att_chain  | [ jti ]                          |
               +------------+----------------------------------+
               | att_uid    | user_id                          |
               +------------+----------------------------------+

                                    Table 3

  7.  Delegation

  7.1.  Overview

     Delegation creates a child credential derived from an existing parent
     credential.  The result is a credential at att_depth + 1 with a scope
     that is a subset of the parent's scope and an expiry no later than
     the parent's expiry.

  7.2.  Input Validation

     The Issuer MUST reject a delegation request if:

     1.  parent_token is absent or empty.

     2.  child_agent is absent or empty.

     3.  child_scope is absent or contains no entries.

  7.3.  Parent Token Verification

     The Issuer MUST:

     1.  Verify the RS256 signature against the Issuer's public key.

     2.  Verify that the parent token has not expired (exp > now).

     3.  Verify that the signing algorithm is RS256.





  Yakung                  Expires 27 September 2026              [Page 13]


  Internet-Draft                    ACAP                        March 2026


  7.4.  Scope Subset Enforcement

     The Issuer MUST apply NormaliseScope to the requested child_scope.
     The Issuer MUST then apply IsSubset(parentScope, childScope).  If
     IsSubset returns false, the delegation MUST be rejected.

  7.5.  Depth Limit

     The Issuer MUST check that parent.att_depth < MaxDelegationDepth
     (10).  If the parent's depth equals or exceeds the limit, the
     delegation MUST be rejected.

  7.6.  Expiry Computation

     parent_exp = parent.exp

     if ttl_seconds > 0:
         requested_exp = now + ttl_seconds
         child_exp = min(requested_exp, parent_exp)
     else:
         default_exp = now + DefaultTTLSeconds
         child_exp = min(default_exp, parent_exp)

     The child's expiry MUST NOT exceed the parent's expiry.

  7.7.  Delegated Credential Construction

              +============+====================================+
              | Field      | Value                              |
              +============+====================================+
              | iss        | Issuer URI                         |
              +------------+------------------------------------+
              | sub        | "agent:" + child_agent             |
              +------------+------------------------------------+
              | iat        | Current UTC time                   |
              +------------+------------------------------------+
              | exp        | min(now + ttl_seconds, parent.exp) |
              +------------+------------------------------------+
              | jti        | Freshly generated UUID v4          |
              +------------+------------------------------------+
              | att_tid    | parent.att_tid (propagated)        |
              +------------+------------------------------------+
              | att_pid    | parent.jti                         |
              +------------+------------------------------------+
              | att_depth  | parent.att_depth + 1               |
              +------------+------------------------------------+
              | att_scope  | NormaliseScope(child_scope)        |
              +------------+------------------------------------+



  Yakung                  Expires 27 September 2026              [Page 14]


  Internet-Draft                    ACAP                        March 2026


              | att_intent | parent.att_intent (propagated)     |
              +------------+------------------------------------+
              | att_chain  | parent.att_chain + [ jti ]         |
              +------------+------------------------------------+
              | att_uid    | parent.att_uid (propagated)        |
              +------------+------------------------------------+

                                    Table 4

  8.  Verification

  8.1.  Overview

     A credential is valid if and only if all of the following conditions
     are satisfied:

     1.  The RS256 signature verifies against the Issuer's public key.

     2.  The current time is before exp (subject to clock-skew allowance).

     3.  The length of att_chain equals att_depth + 1.

     4.  The final element of att_chain equals jti.

     5.  The jti is not present in the revocation store.

  8.2.  Verification Algorithm
























  Yakung                  Expires 27 September 2026              [Page 15]


  Internet-Draft                    ACAP                        March 2026


     function Verify(tokenString, issuerPublicKey, revocationStore):

         // Step 1: Signature and expiry
         claims, err = RS256Parse(tokenString, issuerPublicKey)
         if err is not nil:
             return invalid("signature verification failed")

         // Step 2: Chain length invariant
         expectedLen = claims.att_depth + 1
         if len(claims.att_chain) != expectedLen:
             return invalid("chain length mismatch")

         // Step 3: Chain tail invariant
         if claims.att_chain[len(claims.att_chain) - 1] != claims.jti:
             return invalid("chain tail does not match jti")

         // Step 4: Revocation check
         if revocationStore.IsRevoked(claims.jti):
             return invalid("credential has been revoked")

         return valid(claims)

  8.3.  Warnings vs. Hard Failures

     Chain length and chain tail inconsistencies are surfaced as warnings
     that cause the credential to be reported as invalid.  The warning
     mechanism exists to distinguish between cryptographic failures (which
     may indicate active attack) and structural inconsistencies (which may
     indicate implementation bugs).

  9.  Revocation

  9.1.  Semantics

     Revocation permanently invalidates a credential identified by its
     jti.  Once revoked, a credential MUST be treated as invalid
     regardless of its exp claim.  Revocation is irreversible.

  9.2.  Cascade Semantics

     Revoking a credential with jti X automatically revokes every
     credential whose att_chain contains X:

     Revoke(X):
         targets = { jti | jti == X OR X in credentials[jti].att_chain }
         for each T in targets:
             revocations.insert(T, now, revokedBy)




  Yakung                  Expires 27 September 2026              [Page 16]


  Internet-Draft                    ACAP                        March 2026


     Cascade revocation SHOULD be performed atomically within a single
     database transaction.

  9.3.  Revocation Store

     The revocation store records:

       +============+=============+===================================+
       | Field      | Type        | Description                       |
       +============+=============+===================================+
       | jti        | text (PK)   | The revoked credential identifier |
       +------------+-------------+-----------------------------------+
       | revoked_at | timestamptz | UTC timestamp of revocation       |
       +------------+-------------+-----------------------------------+
       | revoked_by | text        | Agent or user ID that triggered   |
       |            |             | revocation                        |
       +------------+-------------+-----------------------------------+

                                   Table 5

     Duplicate revocation attempts MUST be treated as a no-op
     (idempotent).

  9.4.  Lifetime Interaction

     A credential that has expired is invalid regardless of the revocation
     store.  A credential that has been revoked is invalid regardless of
     whether it has expired.  These are independent failure conditions.

  10.  Human-in-the-Loop Approval

  10.1.  Overview

     Certain delegations require explicit human approval before being
     granted.  ACAP defines an approval protocol that makes the human
     decision a cryptographic event embedded in the resulting credential.

  10.2.  Approval Lifecycle

     The HITL approval flow consists of four phases:

     1.  *Request.* The agent sends an approval request containing the
         parent_token, requested child_scope, an intent description, and
         the agent_id.  The Issuer creates a pending approval record and
         returns a challenge_id.






  Yakung                  Expires 27 September 2026              [Page 17]


  Internet-Draft                    ACAP                        March 2026


     2.  *Poll.* The agent polls for approval status using the
         challenge_id.  Status is one of: pending, approved, rejected, or
         expired.

     3.  *Grant or Deny.* A human reviews the request via a dashboard or
         integration.  To grant, the human authenticates via an OIDC
         Identity Provider and the Issuer verifies the id_token.  The
         Issuer records the human's identity and marks the approval as
         granted.

     4.  *Credential Issuance.* Upon grant, the Issuer delegates a new
         credential from the parent token with the approved scope.  The
         credential carries att_hitl_req, att_hitl_uid, and att_hitl_iss.

  10.3.  Approval Expiry

     Pending approvals MUST expire after a bounded time window.
     Implementations MUST NOT allow approvals to remain pending
     indefinitely.  An expired approval MUST be treated identically to a
     rejection.

  10.4.  Parent Token Re-verification

     When an approval is granted, the Issuer MUST re-verify the parent
     token before issuing the delegated credential.  If the parent token
     has expired or been revoked while the approval was pending, the
     Issuer MUST reject the grant.

  10.5.  HITL Claims Propagation

     The HITL claims (att_hitl_req, att_hitl_uid, att_hitl_iss) from the
     most recent human approval propagate to all subsequent delegations.
     If a new HITL approval occurs at a deeper delegation, the new claims
     replace the inherited ones.

  10.6.  Multi-Tenant Isolation

     Approval requests are scoped to the authenticated organization.  An
     approval created by org A MUST NOT be resolvable by org B.

  11.  Audit Log

  11.1.  Structure

     The audit log is an append-only, hash-chained record of credential
     lifecycle events.  Each entry commits to the previous entry's hash,
     making the log tamper-evident.




  Yakung                  Expires 27 September 2026              [Page 18]


  Internet-Draft                    ACAP                        March 2026


     The audit log is partitioned by att_tid.  Each task tree has its own
     independent hash chain.  The first event uses a genesis hash of 64
     ASCII zero characters as the previous hash value.

  11.2.  Entry Hash Computation

     entry_hash = lowercase-hex( SHA-256(
         prev_hash
         || event_type
         || jti
         || created_at_rfc3339nano
     ) )

     where || denotes string concatenation.  The genesis hash is:

     "00000000000000000000000000000000\
      00000000000000000000000000000000"

     (64 ASCII zero characters.)

  11.3.  Event Types

     +==============+===================================================+
     | Event Type   | Trigger                                           |
     +==============+===================================================+
     | issued       | Root credential issued                            |
     +--------------+---------------------------------------------------+
     | delegated    | Delegated credential issued                       |
     +--------------+---------------------------------------------------+
     | verified     | Credential verified                               |
     +--------------+---------------------------------------------------+
     | revoked      | Credential revoked (one event per cascade target) |
     +--------------+---------------------------------------------------+
     | expired      | Credential reached exp time                       |
     +--------------+---------------------------------------------------+
     | hitl_granted | Human approved a HITL request                     |
     +--------------+---------------------------------------------------+
     | action       | Agent executed a registered action                |
     +--------------+---------------------------------------------------+
     | lifecycle    | Agent lifecycle transition (started/completed/    |
     |              | failed)                                           |
     +--------------+---------------------------------------------------+

                                   Table 6







  Yakung                  Expires 27 September 2026              [Page 19]


  Internet-Draft                    ACAP                        March 2026


  11.4.  Audit Entry Fields

        +============+=============+=================================+
        | Field      | Type        | Description                     |
        +============+=============+=================================+
        | id         | bigserial   | Monotonically increasing row ID |
        +------------+-------------+---------------------------------+
        | prev_hash  | text        | Hash of the prior entry for     |
        |            |             | same att_tid                    |
        +------------+-------------+---------------------------------+
        | entry_hash | text        | SHA-256 of concatenated fields  |
        +------------+-------------+---------------------------------+
        | event_type | text        | One of the defined event types  |
        +------------+-------------+---------------------------------+
        | jti        | text        | JWT ID of the credential        |
        |            |             | involved                        |
        +------------+-------------+---------------------------------+
        | org_id     | text        | Tenant identifier               |
        +------------+-------------+---------------------------------+
        | att_tid    | text        | Task tree identifier            |
        +------------+-------------+---------------------------------+
        | att_uid    | text        | Human principal identifier      |
        +------------+-------------+---------------------------------+
        | agent_id   | text        | Agent identifier                |
        +------------+-------------+---------------------------------+
        | scope      | jsonb       | Scope array at time of event    |
        +------------+-------------+---------------------------------+
        | meta       | jsonb       | Optional implementation-defined |
        |            |             | metadata                        |
        +------------+-------------+---------------------------------+
        | created_at | timestamptz | UTC timestamp                   |
        +------------+-------------+---------------------------------+

                                   Table 7

  11.5.  Append-Only Enforcement

     Implementations MUST enforce append-only semantics on the audit log.

  11.6.  Log Verification

     To verify the integrity of the audit log for a given att_tid:

     1.  Retrieve all entries in ascending id order.

     2.  For each entry starting at the second, verify that
         entry.prev_hash equals the entry_hash of the preceding entry.




  Yakung                  Expires 27 September 2026              [Page 20]


  Internet-Draft                    ACAP                        March 2026


     3.  Recompute entry_hash from the raw fields and verify it matches.

     Any discrepancy indicates tampering or corruption.

  12.  Security Considerations

  12.1.  Prompt Injection

     ACAP credentials bind to the intent hash of the original instruction,
     but they do not prevent a legitimate credential from being used by a
     compromised agent.  The narrow, monotone-reducing scope model limits
     the blast radius of a compromised agent.  The intent hash enables
     post-hoc detection of misuse.  The att_ack claim carries a checksum
     of the agent binary for agent substitution detection.

  12.2.  Replay Attacks

     Credentials carry a unique jti.  Verifiers MUST check the revocation
     store on every verification call.  The exp claim bounds the replay
     window for non-revoked credentials.  Verifiers SHOULD maintain a
     short-term cache of recently seen jti values.

  12.3.  Scope Creep

     Scope creep is prevented by IsSubset enforcement at delegation time.
     Resource servers MUST verify that the presented credential's
     att_scope covers the requested operation.

  12.4.  Clock Skew

     Implementations SHOULD allow a clock-skew leeway of up to 60 seconds.
     Implementations MUST NOT allow a leeway of more than 300 seconds.

  12.5.  Key Management

     The Issuer's RSA private key is the root of trust.  Compromise allows
     forging credentials.  Implementations SHOULD use hardware security
     modules and short key rotation periods.  The public key MUST be
     distributed via an out-of-band mechanism (e.g., a JWKS endpoint).

  12.6.  Credential Store Integrity

     The revocation store and credential store are security-critical.
     Implementations MUST apply access controls preventing unauthorized
     modification.






  Yakung                  Expires 27 September 2026              [Page 21]


  Internet-Draft                    ACAP                        March 2026


  12.7.  Audit Log Integrity

     Hash-chaining provides tamper-evidence but not tamper-prevention.
     The audit log SHOULD be replicated to a write-once store or
     transparency log for stronger guarantees.

  13.  IANA Considerations

     This specification defines the following JWT claim names for
     registration in the IANA "JSON Web Token Claims" registry established
     by [RFC7519].








































  Yakung                  Expires 27 September 2026              [Page 22]


  Internet-Draft                    ACAP                        March 2026


       +==============+=======================+============+===========+
       | Claim Name   | Description           | Change     | Reference |
       |              |                       | Controller |           |
       +==============+=======================+============+===========+
       | att_tid      | ACAP task tree        | IESG       | This      |
       |              | identifier            |            | document  |
       +--------------+-----------------------+------------+-----------+
       | att_pid      | ACAP parent           | IESG       | This      |
       |              | credential identifier |            | document  |
       +--------------+-----------------------+------------+-----------+
       | att_depth    | ACAP delegation depth | IESG       | This      |
       |              |                       |            | document  |
       +--------------+-----------------------+------------+-----------+
       | att_scope    | ACAP permission scope | IESG       | This      |
       |              |                       |            | document  |
       +--------------+-----------------------+------------+-----------+
       | att_intent   | ACAP intent hash      | IESG       | This      |
       |              |                       |            | document  |
       +--------------+-----------------------+------------+-----------+
       | att_chain    | ACAP delegation chain | IESG       | This      |
       |              |                       |            | document  |
       +--------------+-----------------------+------------+-----------+
       | att_uid      | ACAP originating user | IESG       | This      |
       |              | identifier            |            | document  |
       +--------------+-----------------------+------------+-----------+
       | att_hitl_req | ACAP HITL request ID  | IESG       | This      |
       |              |                       |            | document  |
       +--------------+-----------------------+------------+-----------+
       | att_hitl_uid | ACAP HITL approving   | IESG       | This      |
       |              | user                  |            | document  |
       +--------------+-----------------------+------------+-----------+
       | att_hitl_iss | ACAP HITL issuer      | IESG       | This      |
       |              | authority             |            | document  |
       +--------------+-----------------------+------------+-----------+
       | att_idp_iss  | ACAP IdP issuer       | IESG       | This      |
       |              |                       |            | document  |
       +--------------+-----------------------+------------+-----------+
       | att_idp_sub  | ACAP IdP subject      | IESG       | This      |
       |              |                       |            | document  |
       +--------------+-----------------------+------------+-----------+
       | att_ack      | ACAP agent checksum   | IESG       | This      |
       |              | digest                |            | document  |
       +--------------+-----------------------+------------+-----------+

                                    Table 8

  14.  References




  Yakung                  Expires 27 September 2026              [Page 23]


  Internet-Draft                    ACAP                        March 2026


  14.1.  Normative References

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

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

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

     [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/rfc/rfc7519>.

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

     [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/rfc/rfc9562>.

  14.2.  Informative References

     [AGENTJWT] Goswami, D., "Agentic JWT: Secure Delegation Protocol for
                AI Agent Pipelines", 2025,
                <https://datatracker.ietf.org/doc/draft-goswami-agentic-
                jwt/>.

     [OBO01]    "OAuth 2.0 for AI Agents Acting on Behalf of Users", 2025,
                <https://datatracker.ietf.org/doc/draft-oauth-ai-agents-
                on-behalf-of-user/>.

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

     [WIMSE]    "IETF Workload Identity in Multi System Environments
                (WIMSE) Working Group", n.d.,
                <https://datatracker.ietf.org/wg/wimse/about/>.





  Yakung                  Expires 27 September 2026              [Page 24]


  Internet-Draft                    ACAP                        March 2026


  Appendix A.  Summary of Constants

     +====================+=======+======================================+
     | Constant           | Value | Description                          |
     +====================+=======+======================================+
     | MaxDelegationDepth | 10    | Maximum permitted att_depth          |
     +--------------------+-------+--------------------------------------+
     | DefaultTTLSeconds  | 3600  | Default credential lifetime          |
     |                    |       | (1 hour)                             |
     +--------------------+-------+--------------------------------------+
     | MaxTTLSeconds      | 86400 | Maximum credential lifetime          |
     |                    |       | (24 hours)                           |
     +--------------------+-------+--------------------------------------+
     | Genesis hash       | 64 x  | Previous hash for first              |
     |                    | "0"   | audit entry                          |
     +--------------------+-------+--------------------------------------+
     | Clock skew         | 60s   | Recommended leeway                   |
     | (SHOULD)           |       |                                      |
     +--------------------+-------+--------------------------------------+
     | Clock skew (MUST   | 300s  | Maximum leeway                       |
     | NOT exceed)        |       |                                      |
     +--------------------+-------+--------------------------------------+

                                    Table 9

  Appendix B.  Implementation Status

     A reference implementation is available as open source software:

     *  Server: Go, available at https://github.com/chudah1/attest-dev

     *  TypeScript SDK: @attest-dev/sdk on npm (0.1.0-beta.4)

     *  Python SDK: attest-sdk on PyPI (0.1.0b3)

     *  Framework integrations: Anthropic Claude, LangGraph, OpenAI Agents
        SDK, Model Context Protocol (MCP)

     *  Deployment: Docker Compose, Railway

     All SDKs implement credential issuance, delegation, offline
     verification via JWKS, revocation, and audit trail retrieval.

  Appendix C.  Data Model

     The following SQL schema is informative for implementations using
     relational storage:




  Yakung                  Expires 27 September 2026              [Page 25]


  Internet-Draft                    ACAP                        March 2026


     CREATE TABLE IF NOT EXISTS credentials (
         jti         TEXT        PRIMARY KEY,
         org_id      TEXT        NOT NULL,
         att_tid     TEXT        NOT NULL,
         att_pid     TEXT,
         att_uid     TEXT        NOT NULL,
         agent_id    TEXT        NOT NULL,
         depth       INTEGER     NOT NULL DEFAULT 0,
         scope       TEXT[]      NOT NULL,
         chain       TEXT[]      NOT NULL,
         issued_at   TIMESTAMPTZ NOT NULL,
         expires_at  TIMESTAMPTZ NOT NULL
     );

     CREATE INDEX IF NOT EXISTS idx_credentials_chain
         ON credentials USING GIN (chain);

     CREATE TABLE IF NOT EXISTS revocations (
         jti         TEXT        PRIMARY KEY,
         revoked_at  TIMESTAMPTZ NOT NULL,
         revoked_by  TEXT        NOT NULL
     );

     CREATE TABLE IF NOT EXISTS approvals (
         id              TEXT        PRIMARY KEY,
         org_id          TEXT        NOT NULL,
         agent_id        TEXT        NOT NULL,
         att_tid         TEXT        NOT NULL,
         parent_token    TEXT        NOT NULL,
         intent          TEXT        NOT NULL,
         requested_scope TEXT[]      NOT NULL,
         status          TEXT        NOT NULL DEFAULT 'pending',
         approved_by     TEXT,
         created_at      TIMESTAMPTZ NOT NULL DEFAULT NOW(),
         resolved_at     TIMESTAMPTZ
     );

     CREATE TABLE IF NOT EXISTS audit_log (
         id           BIGSERIAL   PRIMARY KEY,
         org_id       TEXT        NOT NULL,
         prev_hash    TEXT        NOT NULL,
         entry_hash   TEXT        NOT NULL,
         event_type   TEXT        NOT NULL,
         jti          TEXT        NOT NULL,
         att_tid      TEXT        NOT NULL,
         att_uid      TEXT        NOT NULL,
         agent_id     TEXT        NOT NULL,
         scope        JSONB       NOT NULL DEFAULT '[]',



  Yakung                  Expires 27 September 2026              [Page 26]


  Internet-Draft                    ACAP                        March 2026


         meta         JSONB,
         idp_issuer   TEXT,
         idp_subject  TEXT,
         hitl_req     TEXT,
         hitl_issuer  TEXT,
         hitl_subject TEXT,
         created_at   TIMESTAMPTZ NOT NULL DEFAULT NOW()
     );

     CREATE OR REPLACE RULE audit_log_no_update AS
         ON UPDATE TO audit_log DO INSTEAD NOTHING;
     CREATE OR REPLACE RULE audit_log_no_delete AS
         ON DELETE TO audit_log DO INSTEAD NOTHING;

  Acknowledgements

     The authors acknowledge the contributions of the broader AI safety
     and identity communities, including the IETF WIMSE working group, the
     NIST AI Agent Standards Initiative, and the authors of the Agentic
     JWT proposal.

  Author's Address

     Chudah Yakung
     Attest
     Email: ychudah@gmail.com

























  Yakung                  Expires 27 September 2026              [Page 27]


name: draft-sharif-openid-agent-identity
rev: 00
title: OpenID Connect Agent Identity Claims for Autonomous AI Agents
time: 2026-03-26T22:19:39Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-27T22:19:39Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth"]
tags: []
fetched_at: 2026-05-22T09:24:41.698264+00:00
source: ietf
abstract:
  This specification defines a profile of OpenID Connect Core 1.0
     that enables Identity Providers (IdPs) to issue identity tokens
     for autonomous software agents.  It introduces a set of standard
     claims for representing agent identity, ownership, trust posture,
     authorised capabilities, and compliance screening status within
     OpenID Connect ID Tokens.

     The profile is designed to operate within existing OpenID Connect
     infrastructure without requiring modifications to the core
     protocol.  It defines how Relying Parties (RPs) validate agent
     tokens and enforce graduated access controls based on agent trust
     levels and sanctions screening results.

full_text:
  Internet Engineering Task Force                               R. Sharif
  Internet-Draft                                            CyberSecAI Ltd
  Intended status: Standards Track                          March 26, 2026
  Expires: September 27, 2026


            OpenID Connect Agent Identity Claims for Autonomous
                                AI Agents
                 draft-sharif-openid-agent-identity-00

  Abstract

     This specification defines a profile of OpenID Connect Core 1.0
     that enables Identity Providers (IdPs) to issue identity tokens
     for autonomous software agents.  It introduces a set of standard
     claims for representing agent identity, ownership, trust posture,
     authorised capabilities, and compliance screening status within
     OpenID Connect ID Tokens.

     The profile is designed to operate within existing OpenID Connect
     infrastructure without requiring modifications to the core
     protocol.  It defines how Relying Parties (RPs) validate agent
     tokens and enforce graduated access controls based on agent trust
     levels and sanctions screening results.

  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 September 27, 2026.

  Copyright Notice

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

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Requirements Notation and Conventions . . . . . . . . . .   5
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
     4.  Agent Identity Claims . . . . . . . . . . . . . . . . . .   7
       4.1.   agent_id . . . . . . . . . . . . . . . . . . . . . .   7
       4.2.   agent_name . . . . . . . . . . . . . . . . . . . . .   8
       4.3.   agent_owner  . . . . . . . . . . . . . . . . . . . .   9
       4.4.   agent_trust_score  . . . . . . . . . . . . . . . . .   9
       4.5.   agent_trust_level  . . . . . . . . . . . . . . . . .  10
       4.6.   agent_capabilities . . . . . . . . . . . . . . . . .  12
       4.7.   agent_sanctions_status . . . . . . . . . . . . . . .  13
       4.8.   agent_spend_limit  . . . . . . . . . . . . . . . . .  14
       4.9.   agent_attestation_method . . . . . . . . . . . . . .  14
       4.10.  agent_created_at . . . . . . . . . . . . . . . . . .  15
     5.  Agent ID Token  . . . . . . . . . . . . . . . . . . . . .  16
     6.  Agent Authentication Flow . . . . . . . . . . . . . . . .  18
       6.1.   Token Issuance via Client Credentials  . . . . . . .  18
       6.2.   Challenge-Response Extension . . . . . . . . . . . .  20
       6.3.   Trust Level Requirements per Scope . . . . . . . . .  23
     7.  Agent Token Validation  . . . . . . . . . . . . . . . . .  24
       7.1.   Standard Validation  . . . . . . . . . . . . . . . .  24
       7.2.   Trust Score Thresholds . . . . . . . . . . . . . . .  26
       7.3.   Sanctions Status Enforcement . . . . . . . . . . . .  27
     8.  Security Considerations . . . . . . . . . . . . . . . . .  28
       8.1.   Agent Impersonation  . . . . . . . . . . . . . . . .  28
       8.2.   Trust Score Manipulation . . . . . . . . . . . . . .  29
       8.3.   Token Replay . . . . . . . . . . . . . . . . . . . .  29
       8.4.   Sanctions Screening Freshness  . . . . . . . . . . .  30
     9.  Privacy Considerations  . . . . . . . . . . . . . . . . .  31
       9.1.   Agent Identity as PII  . . . . . . . . . . . . . . .  31
       9.2.   Minimal Disclosure . . . . . . . . . . . . . . . . .  32
     10. IANA Considerations . . . . . . . . . . . . . . . . . . .  33
       10.1.  Claims Registration  . . . . . . . . . . . . . . . .  33
       10.2.  OAuth Dynamic Client Registration Metadata
              Registration . . . . . . . . . . . . . . . . . . . .  35
     11. References  . . . . . . . . . . . . . . . . . . . . . . .  36
       11.1.  Normative References . . . . . . . . . . . . . . . .  36
       11.2.  Informative References . . . . . . . . . . . . . . .  37
     Appendix A.  Acknowledgements . . . . . . . . . . . . . . . .  38
     Appendix B.  Document History . . . . . . . . . . . . . . . .  38
     Author's Address  . . . . . . . . . . . . . . . . . . . . . .  38

  1.  Introduction

     OpenID Connect Core 1.0 [OpenID.Core] defines an identity layer
     on top of OAuth 2.0 [RFC6749] that enables Clients to verify the
     identity of End-Users.  The core specification models identity
     around human subjects: natural persons who authenticate via user
     agents (typically web browsers) and consent to the release of
     identity claims to Relying Parties.

     The emergence of autonomous software agents -- programs that act
     on behalf of users or organisations to perform tasks, execute
     transactions, and interact with services without continuous human
     supervision -- creates a requirement for machine-readable identity
     that existing OpenID Connect claims do not address.

     Specifically, current limitations include:

     o  The "sub" claim identifies an End-User, not the autonomous
        agent acting on their behalf.  When multiple agents operate
        under the same user account, there is no standard mechanism
        to distinguish between them.

     o  There is no standard claim to express the trust posture of
        an agent.  Relying Parties cannot make graduated access
        control decisions based on an agent's behavioural history
        or verification level.

     o  There is no standard claim to express what actions an agent
        is authorised to perform, distinct from OAuth scopes which
        express what resources the client application may access.

     o  There is no mechanism for Relying Parties to determine
        whether an agent or its controlling entity has been screened
        against sanctions lists, a requirement in regulated financial
        services.

     This specification addresses these gaps by defining a profile of
     OpenID Connect that introduces agent-specific claims carried
     within standard ID Tokens.  The profile is designed with the
     following principles:

     1.  Backward compatibility: All defined claims are additional.
         Existing OpenID Connect deployments that do not recognise
         agent claims will ignore them per Section 5.1 of
         [OpenID.Core], which states that Claims not understood MUST
         be ignored.

     2.  Separation of concerns: The "sub" claim continues to
         identify the End-User or organisational entity.  The
         "agent_id" claim identifies the specific agent instance.
         The "agent_owner" claim links the agent to its controlling
         subject.

     3.  Graduated trust: The trust model supports five levels (L0
         through L4) that map to progressively wider sets of
         permitted actions, enabling Relying Parties to implement
         proportionate access controls.

     4.  Regulatory alignment: Claims for sanctions screening status
         and spend limits enable compliance with Anti-Money
         Laundering (AML) regulations in jurisdictions that require
         entity screening before financial transactions.

     This specification is informed by work on agent payment trust
     frameworks [I-D.sharif-agent-payment-trust], security guidance
     for Model Context Protocol deployments
     [I-D.sharif-mcps-secure-mcp], and emerging requirements for
     autonomous agent identity in financial services.

  2.  Requirements Notation and Conventions

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

     In the following text, all references to "Section" without a
     document identifier refer to sections within this specification.

  3.  Terminology

     This specification uses the terms "Access Token", "Authorization
     Code", "Authorization Endpoint", "Authorization Server",
     "Client", "Client Authentication", "Client Identifier", "Grant
     Type", "ID Token", "Refresh Token", "Resource Server", "Response
     Type", and "Token Endpoint" defined by OAuth 2.0 [RFC6749], the
     terms "Claim", "Claim Type", "Claims Provider", "ID Token",
     "Issuer", and "Relying Party (RP)" defined by OpenID Connect
     Core 1.0 [OpenID.Core], and the terms "JSON Web Token (JWT)",
     "Claim Name", "Claim Value", "Header", "Payload", and
     "Signature" defined by JSON Web Token (JWT) [RFC7519].

     This specification also defines the following terms:

     Agent
        An autonomous software program that acts on behalf of a user
        or organisation to perform tasks, execute transactions, or
        interact with services.  An Agent operates with a degree of
        autonomy and MAY make decisions within the boundaries of its
        authorised capabilities.

     Agent Identity Provider (Agent IdP)
        An OpenID Provider (OP) that issues ID Tokens containing the
        agent claims defined in this specification.  An Agent IdP MAY
        be the same entity as the user's OpenID Provider or MAY be a
        separate service specialising in agent identity.

     Agent Owner
        The End-User or organisation that deployed and controls the
        Agent.  The Agent Owner is identified by the "agent_owner"
        claim and is responsible for the Agent's actions.

     Trust Score
        A numerical representation of an Agent's behavioural
        trustworthiness, expressed as an integer in the range
        [0, 100].  Trust Scores are computed by the Agent IdP based
        on criteria including transaction history, attestation
        strength, and compliance screening results.

     Trust Level
        A graduated classification of an Agent's trust posture,
        expressed as one of five levels (L0 through L4).  Trust
        Levels determine the maximum scope of actions an Agent is
        permitted to perform at a given Relying Party.

  4.  Agent Identity Claims

     This section defines the claims that represent agent identity
     within an OpenID Connect ID Token.  These claims are carried in
     the ID Token payload alongside standard OpenID Connect claims.

     All claims defined in this section use the "agent_" prefix to
     avoid collision with existing OpenID Connect claims and to
     enable Relying Parties to identify agent-specific assertions
     unambiguously.

     The following table summarises the agent claims:

     +-----------------------------+----------+----------+
     | Claim                       | Type     | Required |
     +-----------------------------+----------+----------+
     | agent_id                    | string   | REQUIRED |
     | agent_name                  | string   | OPTIONAL |
     | agent_owner                 | string   | REQUIRED |
     | agent_trust_score           | integer  | OPTIONAL |
     | agent_trust_level           | string   | OPTIONAL |
     | agent_capabilities          | array    | OPTIONAL |
     | agent_sanctions_status      | string   | OPTIONAL |
     | agent_spend_limit           | integer  | OPTIONAL |
     | agent_attestation_method    | string   | OPTIONAL |
     | agent_created_at            | integer  | OPTIONAL |
     +-----------------------------+----------+----------+

                    Table 1: Agent Identity Claims

  4.1.  agent_id

     Claim Name:  agent_id

     Claim Description:  A globally unique identifier for the Agent.

     Claim Type:  String

     Requirement Level:  REQUIRED

     The value MUST be a non-empty string of no more than 255
     characters.  The value MUST be unique within the namespace of
     the issuing Agent IdP.  To achieve global uniqueness across
     IdPs, implementations SHOULD use one of the following formats:

     o  A UUID v4 as defined in [RFC4122], e.g.,
        "550e8400-e29b-41d4-a716-446655440000"

     o  A URN using a domain-scoped identifier, e.g.,
        "urn:example.com:agent:payment-bot-001"

     o  A domain-qualified identifier using the dot-separated
        convention, e.g., "payment-bot.example.com"

     The Agent IdP MUST NOT reuse an "agent_id" value for a different
     agent instance.  Once assigned, an "agent_id" MUST remain stable
     for the lifetime of the agent.

     Example:

       "agent_id": "payment-bot.cybersecai.co.uk"

  4.2.  agent_name

     Claim Name:  agent_name

     Claim Description:  A human-readable display name for the Agent.

     Claim Type:  String

     Requirement Level:  OPTIONAL

     The value MUST be a non-empty string of no more than 128
     characters when present.  The value is intended for display
     purposes in administrative interfaces and audit logs.  Relying
     Parties MUST NOT use the "agent_name" for identification or
     access control decisions; the "agent_id" claim MUST be used for
     that purpose.

     Example:

       "agent_name": "Payment Processing Agent"

  4.3.  agent_owner

     Claim Name:  agent_owner

     Claim Description:  The subject identifier of the entity that
        deployed and controls the Agent.

     Claim Type:  String

     Requirement Level:  REQUIRED

     The value MUST be the "sub" claim value of the Agent Owner as
     issued by the same Agent IdP, or a URI that resolves to the
     owner's identity record at the Agent IdP.  This establishes a
     verifiable chain of accountability from the Agent to its
     controlling entity.

     When the Agent IdP is the same OpenID Provider that issued the
     owner's identity, the value MUST be identical to the "sub"
     claim in the owner's own ID Token.

     When the Agent IdP is a separate service, the value SHOULD be
     a URI of the form:

       https://{owner-idp}/.well-known/openid-configuration
         #sub={value}

     Relying Parties MUST verify that the "agent_owner" value
     corresponds to a valid, active subject at the referenced
     identity provider before granting access to protected resources.

     Example:

       "agent_owner": "user_2fK9xLm3nP7qR8s"

  4.4.  agent_trust_score

     Claim Name:  agent_trust_score

     Claim Description:  A numerical trust score representing the
        Agent's behavioural trustworthiness.

     Claim Type:  Integer

     Requirement Level:  OPTIONAL

     The value MUST be an integer in the range [0, 100] inclusive.
     A value of 0 indicates no established trust.  A value of 100
     indicates the highest level of trust.

     The methodology for computing trust scores is not defined by
     this specification and is at the discretion of the Agent IdP.
     However, the Agent IdP SHOULD document its trust score
     computation methodology in its OpenID Provider metadata or in
     a referenced policy document.

     Factors that MAY influence the trust score include:

     o  Duration and consistency of agent operation
     o  Transaction completion rate and dispute history
     o  Strength of the attestation method used
     o  Sanctions screening result
     o  Compliance with rate limits and usage policies

     Example:

       "agent_trust_score": 72

  4.5.  agent_trust_level

     Claim Name:  agent_trust_level

     Claim Description:  A graduated trust classification for the
        Agent.

     Claim Type:  String

     Requirement Level:  OPTIONAL

     The value MUST be one of the following enumerated strings:

     +-------+------------------+------------------------------------+
     | Level | Label            | Description                        |
     +-------+------------------+------------------------------------+
     | "L0"  | Unverified       | No identity verification           |
     |       |                  | performed.  Agent MAY only access  |
     |       |                  | public resources.                  |
     +-------+------------------+------------------------------------+
     | "L1"  | Basic            | API key or shared secret           |
     |       |                  | attestation.  Agent MAY perform    |
     |       |                  | read operations.                   |
     +-------+------------------+------------------------------------+
     | "L2"  | Verified         | Certificate or JWT-based           |
     |       |                  | attestation.  Agent MAY perform    |
     |       |                  | write operations within defined    |
     |       |                  | limits.                            |
     +-------+------------------+------------------------------------+
     | "L3"  | Trusted          | Challenge-response attestation     |
     |       |                  | with cryptographic proof.  Agent   |
     |       |                  | MAY perform financial transactions |
     |       |                  | within spend limits.               |
     +-------+------------------+------------------------------------+
     | "L4"  | High Assurance   | Multi-factor attestation including |
     |       |                  | hardware-bound keys.  Agent MAY    |
     |       |                  | perform high-value transactions.   |
     +-------+------------------+------------------------------------+

                    Table 2: Agent Trust Levels

     When both "agent_trust_score" and "agent_trust_level" are
     present, the "agent_trust_level" MUST be consistent with the
     "agent_trust_score".  The following mapping defines the minimum
     trust score for each level:

        L0: score < 20
        L1: 20 <= score < 40
        L2: 40 <= score < 60
        L3: 60 <= score < 80
        L4: score >= 80

     If the values are inconsistent, the Relying Party MUST reject
     the token.

     Example:

       "agent_trust_level": "L3"

  4.6.  agent_capabilities

     Claim Name:  agent_capabilities

     Claim Description:  The set of actions the Agent is authorised
        to perform.

     Claim Type:  JSON array of strings

     Requirement Level:  OPTIONAL

     Each element of the array MUST be a non-empty string that
     identifies a specific capability.  Capability identifiers
     SHOULD use the dot-separated hierarchical naming convention:

       {domain}.{resource}.{action}

     Relying Parties MUST treat the "agent_capabilities" claim as
     the maximum set of actions the Agent is authorised to perform.
     A Relying Party MAY further restrict the effective capabilities
     based on its own policies, the Agent's trust level, or other
     contextual factors.

     The "agent_capabilities" claim is distinct from OAuth 2.0
     scopes.  Scopes define what resources the client application
     may access at the authorisation server level.  Agent
     capabilities define what actions the specific Agent instance
     is permitted to perform at the application level.

     Example:

       "agent_capabilities": [
         "payments.transfer.initiate",
         "payments.balance.read",
         "reporting.transactions.export"
       ]

  4.7.  agent_sanctions_status

     Claim Name:  agent_sanctions_status

     Claim Description:  The result of sanctions screening performed
        on the Agent and/or its owner.

     Claim Type:  String

     Requirement Level:  OPTIONAL

     The value MUST be one of the following enumerated strings:

     +----------------+----------------------------------------------+
     | Value          | Description                                  |
     +----------------+----------------------------------------------+
     | "CLEAR"        | The Agent and its owner have been screened    |
     |                | against applicable sanctions lists and no     |
     |                | matches were found.                           |
     +----------------+----------------------------------------------+
     | "HIT"          | The screening process identified a potential  |
     |                | match against one or more sanctions lists.    |
     |                | The Agent MUST NOT be permitted to perform    |
     |                | financial transactions until the match is     |
     |                | resolved.                                     |
     +----------------+----------------------------------------------+
     | "NOT_SCREENED" | No sanctions screening has been performed.    |
     +----------------+----------------------------------------------+

                    Table 3: Sanctions Status Values

     When the value is "HIT", the Agent IdP SHOULD include
     additional context in a separate claims source or via a
     UserInfo endpoint response.  This specification does not define
     the format of additional sanctions screening details.

     The Agent IdP MUST record the date and time of the most recent
     screening.  Relying Parties operating in regulated environments
     SHOULD verify that the screening was performed within a
     timeframe acceptable to their compliance policies (see
     Section 8.4).

     Example:

       "agent_sanctions_status": "CLEAR"

  4.8.  agent_spend_limit

     Claim Name:  agent_spend_limit

     Claim Description:  The maximum transaction amount the Agent is
        authorised to initiate in a single transaction.

     Claim Type:  Integer

     Requirement Level:  OPTIONAL

     The value MUST be a non-negative integer representing the amount
     in minor currency units (e.g., pence for GBP, cents for USD).
     A value of 0 indicates that the Agent is not authorised to
     initiate financial transactions.

     The currency is not encoded in this claim.  The applicable
     currency MUST be determined from context, such as the Relying
     Party's configuration or an associated claim in the ID Token.
     If the currency is ambiguous, the Relying Party MUST reject
     financial transaction requests.

     Example (representing GBP 250.00):

       "agent_spend_limit": 25000

  4.9.  agent_attestation_method

     Claim Name:  agent_attestation_method

     Claim Description:  The method by which the Agent's identity
        was verified by the Agent IdP.

     Claim Type:  String

     Requirement Level:  OPTIONAL

     The value MUST be one of the following enumerated strings:

     +----------------------+----------------------------------------+
     | Value                | Description                            |
     +----------------------+----------------------------------------+
     | "challenge_response" | Identity verified via a cryptographic  |
     |                      | challenge-response protocol (see       |
     |                      | Section 6.2).                          |
     +----------------------+----------------------------------------+
     | "certificate"        | Identity verified via a valid X.509    |
     |                      | certificate presented during TLS       |
     |                      | client authentication or at the        |
     |                      | application layer.                     |
     +----------------------+----------------------------------------+
     | "jwt"                | Identity verified via a signed JWT     |
     |                      | presented as a client assertion per    |
     |                      | [RFC7523].                             |
     +----------------------+----------------------------------------+
     | "api_key"            | Identity verified via a pre-shared     |
     |                      | API key.                               |
     +----------------------+----------------------------------------+

                    Table 4: Attestation Method Values

     The attestation method informs Relying Parties of the strength
     of the identity verification.  Relying Parties SHOULD require
     "challenge_response" or "certificate" attestation for agents
     performing high-value or sensitive operations.

     Example:

       "agent_attestation_method": "challenge_response"

  4.10.  agent_created_at

     Claim Name:  agent_created_at

     Claim Description:  The time at which the Agent was created or
        registered with the Agent IdP.

     Claim Type:  Integer

     Requirement Level:  OPTIONAL

     The value MUST be a NumericDate as defined in Section 2 of
     [RFC7519], representing the number of seconds from
     1970-01-01T00:00:00Z UTC to the agent creation time.

     Relying Parties MAY use this claim in conjunction with the
     trust score to assess whether a newly created agent with an
     unexpectedly high trust score warrants additional scrutiny.

     Example (representing 2026-01-15T09:30:00Z):

       "agent_created_at": 1768561800

  5.  Agent ID Token

     The Agent ID Token is a standard OpenID Connect ID Token
     [OpenID.Core] Section 2 that includes the agent claims defined
     in Section 4 of this specification.

     The Agent ID Token MUST conform to all requirements of an ID
     Token as defined in Section 2 of [OpenID.Core].  In particular:

     o  The token MUST be a JWT [RFC7519] signed using JWS [RFC7515].

     o  The "iss" claim MUST contain the Issuer Identifier of the
        Agent IdP.

     o  The "sub" claim MUST contain a subject identifier.  When the
        Agent acts on behalf of a user, the "sub" claim SHOULD
        contain the user's subject identifier.  When the Agent acts
        on behalf of an organisation without a specific user context,
        the "sub" claim SHOULD contain an organisational identifier.

     o  The "aud" claim MUST contain the client_id of the Relying
        Party.

     o  The "iat" and "exp" claims MUST be present.

     o  The token MUST contain at minimum the "agent_id" and
        "agent_owner" claims defined in this specification.

     The following is a non-normative example of an Agent ID Token
     payload:

       {
         "iss": "https://idp.example.com",
         "sub": "org_8kP2mN5xQ9",
         "aud": "client_rp_payments_001",
         "exp": 1768565400,
         "iat": 1768561800,
         "nonce": "n-0S6_WzA2Mj",
         "agent_id": "payment-bot.example.com",
         "agent_name": "Payment Processing Agent",
         "agent_owner": "org_8kP2mN5xQ9",
         "agent_trust_score": 72,
         "agent_trust_level": "L3",
         "agent_capabilities": [
           "payments.transfer.initiate",
           "payments.balance.read",
           "reporting.transactions.export"
         ],
         "agent_sanctions_status": "CLEAR",
         "agent_spend_limit": 25000,
         "agent_attestation_method": "challenge_response",
         "agent_created_at": 1768561800
       }

     The following is the corresponding JOSE Header:

       {
         "alg": "RS256",
         "typ": "JWT",
         "kid": "2026-03-key-01"
       }

     Agent claims MAY also be returned from the UserInfo Endpoint
     as defined in Section 5.3 of [OpenID.Core].  When agent claims
     are requested via the UserInfo Endpoint, the same claim names
     and semantics defined in Section 4 apply.

     When an Agent IdP supports agent claims, it SHOULD advertise
     this capability in its OpenID Provider Metadata
     [OpenID.Discovery] by including the following metadata
     parameter:

       "agent_claims_supported": true

     The Agent IdP SHOULD also list the supported agent claims in
     the "claims_supported" metadata parameter:

       "claims_supported": [
         "sub",
         "name",
         "email",
         "agent_id",
         "agent_name",
         "agent_owner",
         "agent_trust_score",
         "agent_trust_level",
         "agent_capabilities",
         "agent_sanctions_status",
         "agent_spend_limit",
         "agent_attestation_method",
         "agent_created_at"
       ]

  6.  Agent Authentication Flow

     This section defines how an Agent IdP issues tokens for Agents
     and how Agents authenticate to Relying Parties.

  6.1.  Token Issuance via Client Credentials

     Agent authentication uses the OAuth 2.0 Client Credentials
     grant type [RFC6749] Section 4.4, extended with agent claim
     parameters.

     The Agent or its controlling software sends a token request to
     the Agent IdP's Token Endpoint.  The request MUST include the
     following parameters:

     grant_type
        REQUIRED.  Value MUST be "client_credentials".

     client_id
        REQUIRED.  The client identifier issued to the Agent or its
        controlling application by the Agent IdP.

     client_secret or client_assertion
        REQUIRED.  Client authentication as defined in Section 2.3
        of [RFC6749] or Section 2.2 of [RFC7523].

     scope
        OPTIONAL.  The requested scope.  To request agent claims in
        the resulting token, the scope MUST include "openid" and
        SHOULD include "agent_identity".

     agent_id
        REQUIRED.  The identifier of the Agent for which the token
        is being requested.

     The following is a non-normative example of a token request:

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

       grant_type=client_credentials
       &client_id=agent_controller_001
       &client_secret=s3cr3t
       &scope=openid%20agent_identity%20payments.transfer
       &agent_id=payment-bot.example.com

     If the request is valid and the client is authorised to request
     tokens for the specified agent, the Agent IdP responds with a
     token response as defined in Section 4.4.3 of [RFC6749], with
     the addition of an "id_token" parameter containing the Agent
     ID Token:

       HTTP/1.1 200 OK
       Content-Type: application/json
       Cache-Control: no-store

       {
         "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6ImF0K...",
         "token_type": "Bearer",
         "expires_in": 3600,
         "id_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIs..."
       }

     The Agent IdP MUST verify the following before issuing the
     token:

     1.  The client is authenticated and authorised to request
         tokens for the specified "agent_id".

     2.  The specified Agent exists and is in an active state.

     3.  The Agent's trust score, trust level, and sanctions status
         are current.

     4.  The requested scopes are within the Agent's authorised
         capabilities.

  6.2.  Challenge-Response Extension

     For high-assurance agent verification (trust level L3 and
     above), this specification defines a challenge-response
     extension that provides cryptographic proof of agent identity.

     The flow consists of two exchanges:

     Step 1: Challenge Request

     The Agent requests a challenge from the Agent IdP:

       POST /agent/challenge HTTP/1.1
       Host: idp.example.com
       Content-Type: application/json

       {
         "agent_id": "payment-bot.example.com",
         "client_id": "agent_controller_001"
       }

     The Agent IdP responds with a challenge:

       HTTP/1.1 200 OK
       Content-Type: application/json

       {
         "challenge": "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk",
         "challenge_id": "ch_9xK2mN5pQ7rS",
         "expires_in": 300
       }

     The "challenge" value MUST be a cryptographically random string
     of at least 32 bytes, Base64url-encoded without padding.  The
     Agent IdP MUST store the challenge and associate it with the
     specified "agent_id" and "client_id".  The challenge MUST
     expire after the number of seconds indicated by "expires_in",
     which MUST NOT exceed 600 seconds.

     Step 2: Challenge Response

     The Agent signs the challenge using its private key and submits
     the response as part of the token request:

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

       grant_type=client_credentials
       &client_id=agent_controller_001
       &client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A
         client-assertion-type%3Ajwt-bearer
       &client_assertion=eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9...
       &scope=openid%20agent_identity
       &agent_id=payment-bot.example.com
       &challenge_id=ch_9xK2mN5pQ7rS
       &challenge_response=MEUCIQDf1...

     The "challenge_response" value MUST be the digital signature of
     the "challenge" value, computed using the Agent's private key
     and encoded as Base64url without padding.

     The Agent IdP MUST verify:

     1.  The "challenge_id" corresponds to a valid, unexpired
         challenge issued to the specified "agent_id" and
         "client_id".

     2.  The "challenge_response" is a valid signature of the
         original challenge value, verified using the Agent's
         registered public key.

     3.  The challenge has not been previously used (one-time use).

     Upon successful verification, the Agent IdP issues a token
     with "agent_attestation_method" set to "challenge_response"
     and "agent_trust_level" of at least "L3".

     The following is a non-normative example of the signed
     challenge JWT payload (used in client_assertion):

       {
         "iss": "agent_controller_001",
         "sub": "payment-bot.example.com",
         "aud": "https://idp.example.com/token",
         "jti": "ch_9xK2mN5pQ7rS",
         "challenge":
           "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk",
         "iat": 1768561800,
         "exp": 1768562100
       }

  6.3.  Trust Level Requirements per Scope

     Relying Parties SHOULD define minimum trust level requirements
     for each action scope they support.  The following table
     provides a non-normative example of scope-to-trust-level
     mappings:

     +------------------------------+----------+-------------------+
     | Scope                        | Min      | Min Attestation   |
     |                              | Trust    | Method            |
     |                              | Level    |                   |
     +------------------------------+----------+-------------------+
     | data.public.read             | L0       | any               |
     +------------------------------+----------+-------------------+
     | data.private.read            | L1       | api_key           |
     +------------------------------+----------+-------------------+
     | data.private.write           | L2       | jwt               |
     +------------------------------+----------+-------------------+
     | payments.transfer.initiate   | L3       | challenge_        |
     |                              |          | response          |
     +------------------------------+----------+-------------------+
     | payments.high_value.initiate | L4       | certificate       |
     +------------------------------+----------+-------------------+

               Table 5: Scope to Trust Level Mapping

     When an Agent presents a token with a trust level below the
     minimum required for the requested action, the Relying Party
     MUST reject the request with an HTTP 403 response and SHOULD
     include an error response body indicating the required trust
     level:

       HTTP/1.1 403 Forbidden
       Content-Type: application/json

       {
         "error": "insufficient_trust_level",
         "error_description": "This action requires
           agent_trust_level L3 or above.  The presented
           token contains trust level L1.",
         "required_trust_level": "L3",
         "current_trust_level": "L1"
       }

  7.  Agent Token Validation

     This section defines how Relying Parties validate Agent ID
     Tokens.

  7.1.  Standard Validation

     Relying Parties MUST perform all validation steps defined in
     Section 3.1.3.7 of [OpenID.Core] for ID Token validation.  In
     addition, the following agent-specific validation steps MUST be
     performed:

     1.   Verify that the "agent_id" claim is present and is a
          non-empty string of no more than 255 characters.

     2.   Verify that the "agent_owner" claim is present and is a
          non-empty string.

     3.   If the "agent_trust_score" claim is present, verify that
          it is an integer in the range [0, 100].

     4.   If the "agent_trust_level" claim is present, verify that
          it is one of the values defined in Table 2.

     5.   If both "agent_trust_score" and "agent_trust_level" are
          present, verify that they are consistent per the mapping
          defined in Section 4.5.  If they are inconsistent, the
          token MUST be rejected.

     6.   If the "agent_capabilities" claim is present, verify that
          it is a JSON array of non-empty strings.

     7.   If the "agent_sanctions_status" claim is present, verify
          that it is one of the values defined in Table 3.

     8.   If the "agent_spend_limit" claim is present, verify that
          it is a non-negative integer.

     9.   If the "agent_attestation_method" claim is present, verify
          that it is one of the values defined in Table 4.

     10.  If the "agent_created_at" claim is present, verify that
          it is a valid NumericDate and that it is not in the
          future.

     If any of the above validation steps fail, the Relying Party
     MUST reject the token and MUST NOT grant access to protected
     resources.

  7.2.  Trust Score Thresholds

     Relying Parties that implement graduated access controls based
     on trust scores SHOULD define threshold values for each
     category of protected resource.  The following is a
     non-normative example of threshold-based access control logic:

       function evaluateAccess(token, requestedAction) {
         // Reject if sanctions status is HIT
         if (token.agent_sanctions_status === "HIT") {
           return { allowed: false, reason: "sanctions_hit" };
         }

         // Determine required trust score for the action
         const thresholds = {
           "read":      20,
           "write":     40,
           "transfer":  60,
           "admin":     80
         };

         const requiredScore =
           thresholds[requestedAction.category];
         if (requiredScore === undefined) {
           return {
             allowed: false,
             reason: "unknown_action"
           };
         }

         if ((token.agent_trust_score || 0) < requiredScore) {
           return {
             allowed: false,
             reason: "insufficient_trust_score",
             required: requiredScore,
             actual: token.agent_trust_score || 0
           };
         }

         return { allowed: true };
       }

     Relying Parties SHOULD log all access decisions, including the
     agent_id, requested action, trust score, and decision outcome,
     for audit purposes.

  7.3.  Sanctions Status Enforcement

     Relying Parties operating in regulated financial services
     jurisdictions MUST enforce sanctions status as follows:

     1.  If the "agent_sanctions_status" claim is "HIT", the
         Relying Party MUST deny all financial transaction requests
         from the Agent.  The Relying Party MAY permit non-financial
         read-only access at its discretion.

     2.  If the "agent_sanctions_status" claim is "NOT_SCREENED"
         and the Relying Party requires sanctions screening, the
         Relying Party MUST deny financial transaction requests and
         SHOULD return an error indicating that screening is
         required:

           HTTP/1.1 403 Forbidden
           Content-Type: application/json

           {
             "error": "sanctions_screening_required",
             "error_description": "Agent sanctions screening
               has not been performed.  Financial transactions
               require a CLEAR sanctions status."
           }

     3.  If the "agent_sanctions_status" claim is absent, the
         Relying Party MUST treat it as equivalent to
         "NOT_SCREENED" when sanctions screening is required by
         regulation or policy.

  8.  Security Considerations

  8.1.  Agent Impersonation

     An attacker who obtains an Agent's client credentials can
     request tokens on behalf of the Agent.  To mitigate this risk:

     o  Agent IdPs SHOULD require challenge-response attestation
        (Section 6.2) for Agents operating at trust level L3 or
        above.

     o  Agent private keys used for challenge-response SHOULD be
        stored in hardware security modules (HSMs) or trusted
        execution environments (TEEs).

     o  Agent IdPs SHOULD implement anomaly detection to identify
        token requests from unexpected network locations or at
        unusual times.

     o  Relying Parties SHOULD implement request-level anomaly
        detection in addition to token validation.

  8.2.  Trust Score Manipulation

     Trust scores are asserted by the Agent IdP and are only as
     reliable as the IdP's computation methodology and integrity.

     o  Relying Parties MUST NOT accept trust scores from Agent
        IdPs that they have not explicitly trusted.

     o  Agent IdPs MUST protect trust score computation systems
        from tampering.  Trust score updates SHOULD require
        multi-party authorisation for changes exceeding a defined
        threshold (e.g., an increase of more than 20 points in a
        single update).

     o  Agent IdPs SHOULD implement rate limiting on trust score
        increases to prevent rapid escalation attacks.

     o  Relying Parties MAY implement their own supplementary trust
        scoring that combines the Agent IdP's score with locally
        observed agent behaviour.

  8.3.  Token Replay

     Agent ID Tokens are bearer tokens and are susceptible to
     replay attacks if intercepted.

     o  Agent ID Tokens SHOULD have short expiration times.  An
        expiration time ("exp") of no more than 3600 seconds after
        issuance ("iat") is RECOMMENDED for general use.  For
        financial transactions, an expiration time of no more than
        300 seconds is RECOMMENDED.

     o  Relying Parties SHOULD implement token binding or sender-
        constrained tokens as defined in [RFC9449] (DPoP) to
        prevent token replay by parties other than the intended
        agent.

     o  When the nonce claim is present, Relying Parties MUST
        verify that the nonce has not been previously used within
        the token's validity period.

  8.4.  Sanctions Screening Freshness

     Sanctions lists are updated periodically.  A sanctions
     screening result that was valid at the time of screening may
     become stale.

     o  Agent IdPs SHOULD re-screen Agents and their owners at
        regular intervals.  A re-screening interval of no more
        than 24 hours is RECOMMENDED for Agents performing
        financial transactions.

     o  Agent IdPs SHOULD include a "screened_at" claim
        (NumericDate) in the ID Token or make it available via
        the UserInfo Endpoint, indicating when the most recent
        screening was performed.

     o  Relying Parties in regulated environments SHOULD reject
        tokens where the sanctions screening is older than their
        compliance policy permits.  A maximum staleness of 24
        hours is RECOMMENDED for PSD2-regulated services.

  9.  Privacy Considerations

  9.1.  Agent Identity as PII

     When an Agent acts on behalf of a specific End-User, the
     combination of "agent_id" and "agent_owner" can constitute
     Personally Identifiable Information (PII) as defined in
     applicable data protection regulations, including the UK GDPR
     and EU GDPR.

     o  Agent IdPs MUST process agent identity data in accordance
        with applicable data protection regulations.

     o  When an Agent acts on behalf of a natural person, the
        Agent Owner MUST have provided informed consent for the
        Agent IdP to disclose their subject identifier in the
        "agent_owner" claim.

     o  Relying Parties MUST NOT retain agent identity claims
        beyond the period necessary for the purpose for which
        they were collected, subject to regulatory retention
        requirements.

     o  Agent IdPs SHOULD support pairwise subject identifiers as
        defined in Section 8 of [OpenID.Core] for the
        "agent_owner" claim to limit cross-Relying Party
        correlation of Agent Owners.

  9.2.  Minimal Disclosure

     Agent IdPs and Relying Parties SHOULD implement the principle
     of minimal disclosure:

     o  Agent IdPs SHOULD issue tokens containing only the agent
        claims requested by the Relying Party and necessary for
        the intended transaction.

     o  Relying Parties SHOULD request only the agent claims
        necessary for their access control decisions.

     o  The "agent_trust_score" claim provides finer-grained
        information than "agent_trust_level".  When the Relying
        Party's access control decisions are based solely on trust
        levels, the "agent_trust_score" SHOULD be omitted to
        reduce information disclosure.

     o  The "agent_capabilities" claim SHOULD be filtered to
        include only capabilities relevant to the Relying Party,
        rather than the complete set of the Agent's capabilities.

  10.  IANA Considerations

  10.1.  Claims Registration

     This specification registers the following claims in the IANA
     "JSON Web Token Claims" registry established by [RFC7519]:

     Claim Name: agent_id
     Claim Description: Unique identifier for an autonomous
       software agent
     Change Controller: IESG
     Specification Document(s): Section 4.1 of this specification

     Claim Name: agent_name
     Claim Description: Human-readable display name for an agent
     Change Controller: IESG
     Specification Document(s): Section 4.2 of this specification

     Claim Name: agent_owner
     Claim Description: Subject identifier of the entity
       controlling the agent
     Change Controller: IESG
     Specification Document(s): Section 4.3 of this specification

     Claim Name: agent_trust_score
     Claim Description: Numerical trust score for agent behavioural
       trustworthiness
     Change Controller: IESG
     Specification Document(s): Section 4.4 of this specification

     Claim Name: agent_trust_level
     Claim Description: Graduated trust classification for an agent
     Change Controller: IESG
     Specification Document(s): Section 4.5 of this specification

     Claim Name: agent_capabilities
     Claim Description: Set of actions an agent is authorised to
       perform
     Change Controller: IESG
     Specification Document(s): Section 4.6 of this specification

     Claim Name: agent_sanctions_status
     Claim Description: Result of sanctions screening on an agent
       or its owner
     Change Controller: IESG
     Specification Document(s): Section 4.7 of this specification

     Claim Name: agent_spend_limit
     Claim Description: Maximum single transaction amount for an
       agent in minor currency units
     Change Controller: IESG
     Specification Document(s): Section 4.8 of this specification

     Claim Name: agent_attestation_method
     Claim Description: Method used to verify agent identity
     Change Controller: IESG
     Specification Document(s): Section 4.9 of this specification

     Claim Name: agent_created_at
     Claim Description: Unix timestamp of agent creation or
       registration
     Change Controller: IESG
     Specification Document(s): Section 4.10 of this specification

  10.2.  OAuth Dynamic Client Registration Metadata Registration

     This specification registers the following client metadata
     parameter in the IANA "OAuth Dynamic Client Registration
     Metadata" registry:

     Client Metadata Name: agent_claims_supported
     Client Metadata Description: Boolean indicating whether the
       OpenID Provider supports issuing agent identity claims
     Change Controller: IESG
     Specification Document(s): Section 5 of this specification

  11.  References

  11.1.  Normative References

     [OpenID.Core]
                Sakimura, N., Bradley, J., Jones, M., de Medeiros,
                B., and C. Mortimore, "OpenID Connect Core 1.0
                incorporating errata set 2", December 2023,
                <https://openid.net/specs/
                openid-connect-core-1_0.html>.

     [OpenID.Discovery]
                Sakimura, N., Bradley, J., Jones, M., and E. Jay,
                "OpenID Connect Discovery 1.0 incorporating errata
                set 2", December 2023,
                <https://openid.net/specs/
                openid-connect-discovery-1_0.html>.

     [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>.

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

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

     [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>.

     [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>.

     [RFC7523]  Jones, M., Campbell, B., and C. Mortimore, "JSON
                Web Token (JWT) Profile for OAuth 2.0 Client
                Authentication and Authorization Grants", RFC 7523,
                DOI 10.17487/RFC7523, May 2015,
                <https://www.rfc-editor.org/info/rfc7523>.

     [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>.

     [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>.

  11.2.  Informative References

     [I-D.sharif-agent-payment-trust]
                Sharif, R., "Agent Payment Trust Framework",
                Internet-Draft
                draft-sharif-agent-payment-trust-00, March 2026,
                <https://datatracker.ietf.org/doc/
                draft-sharif-agent-payment-trust/>.

     [I-D.sharif-mcps-secure-mcp]
                Sharif, R., "MCPS: Secure Model Context Protocol",
                Internet-Draft
                draft-sharif-mcps-secure-mcp-00, March 2026,
                <https://datatracker.ietf.org/doc/
                draft-sharif-mcps-secure-mcp/>.

     [OWASP.MCP]
                OWASP Foundation, "MCP Security Cheat Sheet", 2026,
                <https://cheatsheetseries.owasp.org/cheatsheets/
                MCP_Security_Cheat_Sheet.html>.

     [NIST.AI.Agent]
                National Institute of Standards and Technology,
                "NCCoE AI Agent Identity Concept Paper", 2026,
                <https://www.nist.gov/artificial-intelligence>.

  Appendix A.  Acknowledgements

     The author gratefully acknowledges the contributions of the
     OpenID Foundation AI Identity Management Community Group
     members whose review and feedback shaped this specification.

     This work builds on the agent payment trust framework described
     in [I-D.sharif-agent-payment-trust] and incorporates security
     considerations from the OWASP MCP Security Cheat Sheet
     [OWASP.MCP] Section 7, and security guidance for MCP
     deployments from [I-D.sharif-mcps-secure-mcp].

  Appendix B.  Document History

     draft-sharif-openid-agent-identity-00 -- March 2026

     o  Initial draft.

     o  Defined ten agent identity claims with full type definitions
        and validation rules.

     o  Specified Agent ID Token structure and Agent IdP metadata.

     o  Defined client credentials flow with challenge-response
        extension.

     o  Defined trust level requirements per action scope.

     o  Defined token validation procedures including trust score
        thresholds and sanctions enforcement.

  Author's Address

     Raza Sharif
     CyberSecAI Ltd
     London, United Kingdom

     Email: contact@agentsign.dev
     URI:   https://cybersecai.co.uk


name: draft-sharif-agent-transport-protocol
rev: 00
title: Agent Transport Protocol: Asynchronous Store-and-Forward Messaging for Autonomous AI Agents
time: 2026-03-28T14:30:25Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-29T14:30:25Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent identity/auth", "Data formats/interop"]
tags: []
fetched_at: 2026-05-22T09:24:41.698268+00:00
source: ietf
abstract:
  This document specifies the Agent Transport Protocol (ATP), an
     asynchronous store-and-forward messaging protocol for autonomous
     AI agents.  ATP enables agents to transmit themselves -- including
     state, context, capabilities, and cryptographic identity -- between
     agent runtimes across network boundaries.  The protocol draws on
     the operational model of the Simple Mail Transfer Protocol (SMTP)
     [RFC5321] but is purpose-built for agent-to-agent communication
     where the agent itself is the payload.

     ATP provides: (1) asynchronous delivery with store-and-forward
     semantics, (2) cryptographic identity verification at each relay
     hop, (3) trust scoring and policy enforcement at ingress, (4)
     capability negotiation between sending and receiving runtimes,
     and (5) tamper-evident envelopes with end-to-end integrity
     protection.

     The protocol is transport-agnostic and operates over TCP, TLS,
     QUIC, or any reliable ordered stream.  ATP is designed to
     interoperate with existing agent frameworks including Google A2A,
     the Model Context Protocol (MCP), and FIPA ACL, while addressing
     the fundamental limitation of synchronous RPC-based agent
     communication: the requirement that both endpoints be
     simultaneously available.

full_text:
  Internet Engineering Task Force                               R. Sharif
  Internet-Draft                                           CyberSecAI Ltd
  Intended status: Standards Track                          28 March 2026
  Expires: 28 September 2026


           Agent Transport Protocol: Asynchronous Store-and-Forward
                     Messaging for Autonomous AI Agents
                 draft-sharif-agent-transport-protocol-00

  Abstract

     This document specifies the Agent Transport Protocol (ATP), an
     asynchronous store-and-forward messaging protocol for autonomous
     AI agents.  ATP enables agents to transmit themselves -- including
     state, context, capabilities, and cryptographic identity -- between
     agent runtimes across network boundaries.  The protocol draws on
     the operational model of the Simple Mail Transfer Protocol (SMTP)
     [RFC5321] but is purpose-built for agent-to-agent communication
     where the agent itself is the payload.

     ATP provides: (1) asynchronous delivery with store-and-forward
     semantics, (2) cryptographic identity verification at each relay
     hop, (3) trust scoring and policy enforcement at ingress, (4)
     capability negotiation between sending and receiving runtimes,
     and (5) tamper-evident envelopes with end-to-end integrity
     protection.

     The protocol is transport-agnostic and operates over TCP, TLS,
     QUIC, or any reliable ordered stream.  ATP is designed to
     interoperate with existing agent frameworks including Google A2A,
     the Model Context Protocol (MCP), and FIPA ACL, while addressing
     the fundamental limitation of synchronous RPC-based agent
     communication: the requirement that both endpoints be
     simultaneously available.

  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 28 September 2026.

  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents
     (https://trustee.ietf.org/license-info) in effect on the date of
     publication of this document.  Please review these documents
     carefully, as they describe your rights and restrictions with
     respect to this document.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . .  3
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.  Protocol Overview . . . . . . . . . . . . . . . . . . . . .  5
     4.  Agent Addressing  . . . . . . . . . . . . . . . . . . . . .  7
     5.  Agent Envelope  . . . . . . . . . . . . . . . . . . . . . .  8
     6.  Agent Payload . . . . . . . . . . . . . . . . . . . . . . . 10
     7.  Transport Session . . . . . . . . . . . . . . . . . . . . . 12
     8.  Relay and Forwarding  . . . . . . . . . . . . . . . . . . . 14
     9.  Identity and Trust  . . . . . . . . . . . . . . . . . . . . 15
     10. Security Considerations . . . . . . . . . . . . . . . . . . 18
     11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20
     12. References  . . . . . . . . . . . . . . . . . . . . . . . . 21
     Appendix A.  Comparison with Existing Protocols . . . . . . . . 23
     Appendix B.  Example Flows  . . . . . . . . . . . . . . . . . . 25
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . 27

  1.  Introduction

     The rapid deployment of autonomous AI agents has created a
     fundamental infrastructure gap: agents cannot reliably communicate
     with other agents across organisational boundaries, time zones,
     and heterogeneous runtime environments.

     Existing agent communication protocols assume synchronous,
     request-response interaction patterns:

     *  Google Agent-to-Agent (A2A) protocol uses JSON-RPC 2.0 over
        HTTP, requiring both endpoints to be simultaneously available.

     *  The Model Context Protocol (MCP) connects AI models to tools
        and data sources but does not define agent-to-agent messaging.

     *  FIPA Agent Communication Language (ACL) defined asynchronous
        messaging in the early 2000s but predates modern cryptographic
        identity, trust scoring, and cloud-native deployment patterns.

     These protocols solve important problems but share a common
     limitation: they do not support the case where an agent must
     transmit itself -- its state, context, accumulated knowledge,
     and in-progress tasks -- to a different runtime for continued
     execution.  This pattern is essential for:

     *  Cross-timezone agent handoff: An agent operating during UK
        business hours hands off its active tasks to an agent runtime
        in a US or APAC time zone for continued processing.

     *  Resource optimisation: Compute resources and API quotas can
        be utilised by agents across organisational boundaries when
        authorised by policy.

     *  Fault tolerance: An agent whose runtime is shutting down can
        persist itself to a relay for later delivery to a replacement
        runtime.

     *  Asynchronous collaboration: Multi-agent workflows where
        participating agents operate on different schedules or have
        intermittent connectivity.

     The Agent Transport Protocol (ATP) addresses these requirements
     by defining:

     (a)  An agent addressing scheme compatible with DNS.

     (b)  An agent envelope format carrying identity, trust, routing,
          and capability metadata.

     (c)  An agent payload format encapsulating agent state, context,
          tools, and in-progress tasks.

     (d)  A transport session protocol with store-and-forward
          semantics.

     (e)  Relay and forwarding rules analogous to SMTP MTA behaviour.

     (f)  Integration points for cryptographic identity verification
          and trust scoring at each hop.

     ATP draws heavily on the design principles of SMTP [RFC5321]:
     simple envelope/payload separation, relay-based forwarding,
     store-and-forward resilience, and DNS-based routing.  However,
     ATP differs from SMTP in critical ways: the payload is an
     executable agent (not a passive message), identity verification
     is mandatory (not optional), and trust scoring gates delivery
     (not just spam filtering).

  1.1.  Design Goals

     G1.  Asynchronous delivery: Sender and receiver need not be
          online simultaneously.

     G2.  Agent-as-payload: The protocol transports complete agent
          state, not just messages between agents.

     G3.  Cryptographic identity: Every agent in transit carries
          verifiable identity claims bound to a cryptographic key.

     G4.  Trust-gated delivery: Receiving runtimes enforce minimum
          trust thresholds before accepting an inbound agent.

     G5.  Relay transparency: Agents traverse zero or more relay
          hops; each hop is recorded and signed.

     G6.  Runtime agnosticism: ATP does not mandate a specific agent
          framework, programming language, or execution environment.

     G7.  Backward compatibility: ATP can encapsulate A2A messages,
          MCP tool calls, or FIPA ACL performatives as payload
          components.

  2.  Terminology

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

     Agent:  An autonomous software entity capable of reasoning,
        decision-making, and tool usage, possessing a cryptographic
        identity and transportable state.

     Agent Runtime:  A compute environment capable of receiving,
        validating, and executing an agent.  Analogous to an SMTP
        Mail Transfer Agent (MTA).

     Agent Relay:  An intermediary that accepts agents for store-
        and-forward delivery.  A relay MAY inspect the envelope but
        MUST NOT modify the payload.  Analogous to an SMTP relay.

     Agent Mailbox:  A persistent store at the destination runtime
        where agents await execution.  Analogous to an email mailbox.

     Agent Address:  A globally unique identifier for an agent or
        agent runtime, resolved via DNS.

     Agent Envelope:  Metadata accompanying the agent payload,
        including routing, identity, trust, and capability
        information.

     Agent Payload:  The serialised agent state, context, tools,
        and task information transported by ATP.

     Originating Runtime:  The runtime that initiates agent
        transmission.

     Destination Runtime:  The runtime that will execute the
        received agent.

     Hop:  A single relay-to-relay or runtime-to-relay transfer.

     Trust Score:  A numerical value (0.0 to 1.0) representing the
        assessed trustworthiness of an agent, as defined in
        [I-D.sharif-agent-payment-trust].

  3.  Protocol Overview

     ATP operates in three phases:

     Phase 1: Submission
     The originating runtime serialises the agent into an envelope
     and payload, signs the envelope, and submits it to the next
     hop (either a relay or the destination runtime directly).

     Phase 2: Relay (zero or more hops)
     Each relay verifies the envelope signature, evaluates the
     agent's trust score against its local policy, appends a
     Received header, re-signs the envelope, and forwards to the
     next hop.  If the next hop is unavailable, the relay stores
     the agent and retries according to a configurable schedule.

     Phase 3: Delivery
     The destination runtime verifies the full signature chain,
     evaluates trust, checks capability requirements, and either
     accepts the agent into its mailbox for execution or rejects
     it with a status code.

     +----------------+       +----------------+       +----------------+
     |  Originating   |       |     Relay      |       |  Destination   |
     |    Runtime     |       |                |       |    Runtime     |
     |                |       |                |       |                |
     |  +---------+   |       |  +---------+   |       |  +---------+  |
     |  |  Agent  |   | ATP   |  |  Store   |  | ATP   |  | Mailbox |  |
     |  |  State  |---+------>|  |  & Fwd   |--+------>|  |         |  |
     |  +---------+   |       |  +---------+   |       |  +---------+  |
     |                |       |                |       |       |       |
     +----------------+       +----------------+       |   Execute    |
                                                       +----------------+

  3.1.  Comparison with SMTP

     ATP is modelled on SMTP but adapted for agent transport:

     +------------------+---------------------+------------------------+
     | Concept          | SMTP                | ATP                    |
     +------------------+---------------------+------------------------+
     | Payload          | Email message       | Agent (state+context)  |
     | Address          | user@domain         | agent@runtime.domain   |
     | Routing          | MX records          | AX records (new)       |
     | Relay            | MTA                 | Agent Relay            |
     | Delivery         | Mailbox (IMAP/POP)  | Agent Mailbox          |
     | Identity         | Optional (DKIM)     | Mandatory (ECDSA/JWS)  |
     | Trust            | Spam score          | Trust score (0.0-1.0)  |
     | Integrity        | Optional (S/MIME)   | Mandatory (JWS)        |
     | Execution        | None (passive)      | Agent executes on      |
     |                  |                     | delivery               |
     +------------------+---------------------+------------------------+

  3.2.  Relationship to Other Protocols

     ATP is designed to complement, not replace, existing protocols:

     *  MCP: An agent transported via ATP MAY carry MCP tool
        definitions and use MCP to interact with tools at the
        destination runtime.

     *  A2A: ATP can encapsulate A2A task objects as payload
        components for delivery to A2A-compatible runtimes.

     *  AgentPass: ATP uses AgentPass trust scoring
        [I-D.sharif-agent-payment-trust] for delivery decisions.

     *  MCPS: ATP uses MCPS message signing
        [I-D.sharif-mcps-secure-mcp] for envelope integrity.

     *  OpenID Agent Identity: ATP uses OpenID Connect agent
        identity claims [I-D.sharif-openid-agent-identity] for
        agent authentication.

  4.  Agent Addressing

     An agent address takes the form:

        agent-id "@" runtime-domain

     Where:

     *  agent-id is a locally unique identifier assigned by the
        originating runtime.  It MUST conform to the syntax of a
        URI unreserved character string [RFC3986].

     *  runtime-domain is a fully qualified domain name (FQDN)
        identifying the agent runtime or organisation.

     Examples:

        payment-bot@agents.example.com
        research-agent-7f3a@runtime.corp.example

  4.1.  DNS Resolution

     ATP introduces a new DNS resource record type: AX (Agent
     eXchange), analogous to MX records for email.

        example.com.  IN  AX  10  relay1.agents.example.com.
        example.com.  IN  AX  20  relay2.agents.example.com.

     AX records specify the agent relay or runtime responsible for
     accepting agents addressed to a given domain.  The preference
     value (10, 20) indicates priority, with lower values preferred.

     If no AX records exist, the sending runtime SHOULD fall back
     to SRV record lookup:

        _atp._tcp.example.com.  IN  SRV  10  0  4567
                                            relay1.agents.example.com.

     The default ATP port is 4567/tcp (to be registered with IANA).

  4.2.  Agent Identity URI

     For interoperability with OpenID Connect and existing identity
     systems, an agent MAY also be identified by a URI:

        atp://agents.example.com/payment-bot
        did:atp:agents.example.com:payment-bot

     The atp:// URI scheme is defined in Section 11 (IANA
     Considerations).

  5.  Agent Envelope

     The agent envelope is a JSON object signed using JSON Web
     Signature (JWS) [RFC7515] with the following structure:

     {
       "atp_version": "1.0",
       "envelope_id": "uuid-v4",
       "timestamp": "2026-03-28T14:30:00Z",
       "from": {
         "agent_id": "payment-bot@agents.example.com",
         "runtime": "runtime-a.example.com",
         "identity": {
           "iss": "https://idp.example.com",
           "sub": "payment-bot",
           "agent_type": "autonomous",
           "owner": "org:example-corp",
           "trust_score": 0.85,
           "capabilities": ["payments", "data-retrieval"],
           "compliance": ["pci-dss-v4", "gdpr"]
         }
       },
       "to": {
         "agent_id": "processor@agents.partner.com",
         "runtime": "runtime-b.partner.com"
       },
       "routing": {
         "hops": [],
         "max_hops": 5,
         "ttl_seconds": 86400,
         "priority": "normal"
       },
       "requirements": {
         "min_trust_score": 0.5,
         "required_capabilities": ["payments"],
         "required_compliance": [],
         "sandbox": "required"
       },
       "payload_hash": "sha256:abcdef1234567890...",
       "payload_size": 45200,
       "payload_encryption": "A256GCM",
       "signature": "..."
     }

  5.1.  Envelope Fields

     atp_version:  Protocol version.  MUST be "1.0" for this
        specification.

     envelope_id:  Globally unique identifier (UUID v4) for this
        transmission.  Used for deduplication and audit.

     timestamp:  ISO 8601 timestamp of envelope creation.

     from:  Object identifying the sending agent, its runtime, and
        its identity claims.  The identity object MUST include claims
        as defined in [I-D.sharif-openid-agent-identity].

     to:  Object identifying the destination agent or runtime.

     routing:  Object controlling relay behaviour.

        hops:  Array of Received entries appended by each relay
           (see Section 8).

        max_hops:  Maximum number of relay hops permitted.  If
           exceeded, the agent MUST be returned to sender.

        ttl_seconds:  Maximum time the agent may remain in relay
           storage before being discarded.

        priority:  One of "critical", "high", "normal", "low",
           "deferred".

     requirements:  Object specifying minimum conditions the
        destination runtime must satisfy.

        min_trust_score:  Minimum trust score the destination
           runtime must hold (0.0 to 1.0).

        required_capabilities:  Array of capability strings the
           destination runtime must support.

        sandbox:  Whether the agent requires sandboxed execution.
           One of "required", "preferred", "none".

     payload_hash:  SHA-256 hash of the serialised payload, hex-
        encoded with "sha256:" prefix.  Used for integrity
        verification.

     payload_size:  Size of the payload in bytes.

     payload_encryption:  JWE encryption algorithm used for the
        payload.  "none" if unencrypted (NOT RECOMMENDED for
        production).

     signature:  JWS signature over the canonical JSON serialisation
        of all preceding fields.

  5.2.  Received Headers

     Each relay MUST prepend a Received entry to the routing.hops
     array:

     {
       "relay": "relay1.agents.example.com",
       "timestamp": "2026-03-28T14:30:05Z",
       "trust_evaluation": {
         "inbound_score": 0.85,
         "policy_result": "accept",
         "verification": "signature_valid"
       },
       "signature": "..."
     }

     This creates a tamper-evident chain analogous to SMTP Received
     headers but with cryptographic signatures at each hop.

  6.  Agent Payload

     The agent payload encapsulates everything needed to resume
     agent execution at the destination runtime.  It is serialised
     as a JSON object and optionally encrypted using JWE [RFC7516].

     {
       "agent_manifest": {
         "name": "payment-bot",
         "version": "2.1.0",
         "framework": "langchain",
         "runtime_requirements": {
           "language": "python",
           "version": ">=3.11",
           "memory_mb": 512,
           "gpu": false
         }
       },
       "state": {
         "format": "application/json",
         "data": { ... },
         "checkpoint_id": "chk-abc123",
         "checkpoint_timestamp": "2026-03-28T14:29:00Z"
       },
       "context": {
         "conversation_history": [ ... ],
         "accumulated_knowledge": { ... },
         "active_tasks": [
           {
             "task_id": "task-789",
             "description": "Process Q1 invoices",
             "status": "in_progress",
             "progress": 0.65,
             "deadline": "2026-03-29T09:00:00Z"
           }
         ]
       },
       "tools": [
         {
           "name": "query_database",
           "protocol": "mcp",
           "server_uri": "mcp://db.example.com/query",
           "credentials_ref": "vault:db-readonly-token"
         }
       ],
       "credentials": {
         "method": "vault_reference",
         "refs": ["vault:db-readonly-token", "vault:api-key-x"]
       },
       "code": {
         "method": "reference",
         "registry": "https://registry.agents.example.com",
         "package": "payment-bot@2.1.0",
         "hash": "sha256:def456..."
       }
     }

  6.1.  Payload Fields

     agent_manifest:  Metadata describing the agent software,
        version, framework, and runtime requirements.  The
        destination runtime uses this to determine whether it can
        execute the agent.

     state:  Serialised agent state at the point of transmission.
        The format field indicates the MIME type; data contains the
        state; checkpoint_id and checkpoint_timestamp enable
        resumption.

     context:  Accumulated context including conversation history,
        knowledge, and active tasks with progress indicators.

     tools:  Array of tool definitions the agent requires.  Each
        tool specifies its protocol (e.g., "mcp", "rest", "grpc"),
        connection URI, and a credential reference.

     credentials:  Credential references (NEVER inline secrets).
        The "vault_reference" method points to secrets in a shared
        vault service.  Destination runtimes resolve these references
        at execution time.

     code:  Agent code reference.  The "reference" method points to
        a package registry; the destination runtime fetches and
        verifies the code by hash.  The "inline" method (not shown)
        allows embedding code directly but is NOT RECOMMENDED for
        production use due to size and security concerns.

  6.2.  Payload Security

     The agent payload MUST be encrypted using JWE [RFC7516] when
     transmitted over untrusted networks or through relays.  The
     encryption key SHOULD be derived from the destination runtime's
     public key, ensuring only the intended recipient can decrypt
     the payload.

     Credentials MUST NOT be included inline in the payload.  All
     credential access MUST use reference-based resolution (vault
     references, token exchange, or capability delegation).

     Agent code MUST be verified by hash before execution.  The
     destination runtime MUST reject payloads where the code hash
     does not match the manifest.

  7.  Transport Session

     ATP transport sessions follow a command-response pattern over
     a reliable stream (TCP/TLS/QUIC).

  7.1.  Session Establishment

     C: [connect to relay1.agents.example.com:4567]
     S: 220 relay1.agents.example.com ATP/1.0 Ready
     C: AHLO runtime-a.example.com
     S: 250-relay1.agents.example.com Hello
     S: 250-SIZE 52428800
     S: 250-STARTTLS
     S: 250-AUTH ECDSA-JWS
     S: 250-TRUST-MIN 0.3
     S: 250 CAPABILITIES payments,data-retrieval,code-execution

     The AHLO (Agent Hello) command initiates the session and
     advertises the sending runtime's identity.  The relay responds
     with its capabilities, size limits, supported authentication
     methods, minimum trust threshold, and available capabilities.

  7.2.  Authentication

     C: AUTH ECDSA-JWS <base64-encoded-jws-token>
     S: 235 Authentication successful, trust_score=0.85

     Authentication is MANDATORY.  The sending runtime presents a
     JWS token containing its identity claims as defined in
     [I-D.sharif-openid-agent-identity].  The relay verifies the
     token and evaluates the trust score.

  7.3.  Agent Transmission

     C: AGENT FROM:<payment-bot@agents.example.com>
     S: 250 OK
     C: AGENT TO:<processor@agents.partner.com>
     S: 250 OK
     C: DATA
     S: 354 Start agent data; end with <CRLF>.<CRLF>
     C: [envelope + payload as multipart MIME]
     C: .
     S: 250 OK: agent queued as <queue-id>

     Or, if the trust score is insufficient:

     S: 550 Trust score 0.25 below minimum threshold 0.5

     Or, if capabilities are missing:

     S: 556 Destination lacks required capability: payments

  7.4.  Status Codes

     ATP status codes follow the same 3-digit structure as SMTP:

     +------+---------------------------------------------------+
     | Code | Meaning                                           |
     +------+---------------------------------------------------+
     | 220  | Service ready                                     |
     | 235  | Authentication successful                         |
     | 250  | Requested action completed                        |
     | 354  | Start payload input                               |
     | 421  | Service not available, closing channel             |
     | 450  | Agent not deliverable, try again later             |
     | 451  | Local error in processing                         |
     | 452  | Insufficient storage                              |
     | 500  | Syntax error, command unrecognised                |
     | 501  | Syntax error in parameters                        |
     | 530  | Authentication required                           |
     | 535  | Authentication failed                             |
     | 550  | Trust score below threshold                       |
     | 551  | Agent not local, forwarding address supplied       |
     | 552  | Payload exceeds size limit                        |
     | 553  | Invalid agent address                             |
     | 554  | Transaction failed                                |
     | 555  | Capability mismatch                               |
     | 556  | Required capability unavailable                   |
     | 557  | Sandbox requirement cannot be satisfied            |
     | 558  | Agent code verification failed                    |
     | 559  | Compliance requirement not met                    |
     +------+---------------------------------------------------+

  8.  Relay and Forwarding

     An ATP relay operates analogously to an SMTP relay (MTA):

     (a)  Accept inbound agent transmissions.
     (b)  Verify envelope signature and trust score.
     (c)  Append a Received entry to routing.hops.
     (d)  Re-sign the envelope.
     (e)  Look up the next hop via AX/SRV DNS records.
     (f)  Attempt delivery to the next hop.
     (g)  If delivery fails, store the agent and retry.

  8.1.  Store-and-Forward

     When the next hop is unavailable, the relay MUST store the
     agent and retry delivery according to the following schedule:

     *  First retry: 5 minutes
     *  Subsequent retries: exponential backoff with jitter,
        doubling interval up to 1 hour
     *  Maximum retention: routing.ttl_seconds (default 86400)
     *  After TTL expiry: generate a non-delivery notification
        and return to the originating runtime

     Stored agents MUST be encrypted at rest.  The relay MUST NOT
     execute, inspect, or modify the agent payload.

  8.2.  Loop Detection

     Relays MUST check the routing.hops array for loops.  If the
     current relay's domain appears in a previous hop entry, the
     relay MUST reject the transmission with status code 554 and
     the text "Routing loop detected."

     Relays MUST enforce routing.max_hops.  If the number of
     entries in routing.hops equals or exceeds max_hops, the relay
     MUST reject with status 554 "Maximum hops exceeded."

  9.  Identity and Trust

     ATP integrates three layers of identity and trust verification:

  9.1.  Layer 1: Runtime Authentication

     Every ATP session begins with mutual authentication.  Both the
     sending and receiving runtimes (or relays) present JWS tokens
     containing:

     *  Runtime identity (domain, operator, organisation)
     *  Runtime capabilities
     *  Current trust score
     *  TLS certificate binding

     This layer ensures that the transport channel itself is
     authenticated, analogous to SMTP STARTTLS + DKIM but mandatory
     rather than optional.

  9.2.  Layer 2: Agent Identity

     The agent carried in the payload possesses its own cryptographic
     identity, independent of the runtime.  Agent identity claims
     follow the profile defined in [I-D.sharif-openid-agent-identity]:

     *  iss: Identity Provider that issued the agent's credentials
     *  sub: Agent identifier
     *  agent_type: "autonomous", "semi-autonomous", or "supervised"
     *  owner: Organisation or individual responsible for the agent
     *  capabilities: Array of capability strings
     *  trust_score: Current trust assessment

     The destination runtime MUST verify the agent's identity token
     independently of the envelope signature.  This ensures that
     even if a relay is compromised, the agent's identity remains
     verifiable.

  9.3.  Layer 3: Trust Scoring

     Trust scoring follows the framework defined in
     [I-D.sharif-agent-payment-trust]:

     *  Each runtime and relay maintains a trust ledger recording
        the behaviour of agents it has previously hosted.

     *  Trust scores decay over time (configurable half-life).

     *  Trust scores are cryptographically signed and verifiable.

     *  The destination runtime evaluates the agent's trust score
        against its local minimum threshold before accepting
        delivery.

     Trust evaluation at ingress:

     IF agent.trust_score < runtime.min_trust_threshold THEN
       REJECT 550 "Trust score below threshold"
     ELSE IF agent.trust_score < runtime.caution_threshold THEN
       ACCEPT with sandbox="enforced"
     ELSE
       ACCEPT with sandbox="optional"
     END IF

  9.4.  Sanctions and Compliance Screening

     Destination runtimes MAY perform compliance screening against
     sanctions lists, blocked-agent registries, or organisational
     deny-lists before accepting an agent.  If screening fails, the
     runtime MUST reject with status 559 "Compliance requirement
     not met."

  10.  Security Considerations

  10.1.  Agent Code Execution

     The most significant security concern in ATP is that the
     payload is executable.  Unlike email (passive content), an
     ATP agent will execute code at the destination runtime.
     Implementations MUST:

     *  Verify agent code hash against the manifest before
        execution.

     *  Execute agents in sandboxed environments with resource
        limits (CPU, memory, network, filesystem).

     *  Enforce capability-based access control: agents may only
        access tools and resources matching their declared
        capabilities.

     *  Monitor agent behaviour during execution and terminate
        agents that violate policy.

     *  Maintain tamper-evident audit logs of all agent executions.

  10.2.  Relay Trust

     Relays are trusted to store and forward agents but MUST NOT
     inspect or modify payloads.  End-to-end encryption (JWE with
     the destination runtime's public key) ensures relay operators
     cannot access agent state or credentials.

     However, relays can observe metadata (envelope fields, timing,
     routing).  Implementations concerned with metadata privacy
     SHOULD use onion-routing techniques or direct runtime-to-
     runtime delivery.

  10.3.  Replay Attacks

     Each envelope carries a unique envelope_id and timestamp.
     Destination runtimes MUST maintain a replay cache of recently
     received envelope_ids and reject duplicates.  The replay
     cache window MUST be at least as long as routing.ttl_seconds.

  10.4.  Denial of Service

     ATP inherits SMTP's exposure to denial-of-service via
     resource exhaustion (large payloads, high volume).
     Implementations MUST enforce:

     *  Maximum payload size (advertised in AHLO response)
     *  Rate limiting per sending runtime
     *  Trust-based admission: agents with low trust scores
        are subject to stricter rate limits

  10.5.  Credential Security

     Agent payloads MUST NOT contain inline credentials.  All
     credential access uses vault references resolved at execution
     time.  This ensures that even if an agent is intercepted in
     transit, no credentials are exposed.

     Credential delegation between runtimes SHOULD use OAuth 2.0
     token exchange [RFC8693] or capability-based delegation.

  11.  IANA Considerations

     This document requests the following IANA registrations:

  11.1.  AX DNS Resource Record Type

     Type:  AX
     Value:  [TBD]
     Meaning:  Agent eXchange
     Reference:  This document, Section 4.1

  11.2.  ATP Port Number

     Service Name:  atp
     Transport Protocol:  tcp
     Assignee:  IETF
     Contact:  Author
     Description:  Agent Transport Protocol
     Reference:  This document
     Port Number:  4567

  11.3.  ATP URI Scheme

     Scheme:  atp
     Description:  Agent Transport Protocol
     Reference:  This document, Section 4.2

  11.4.  ATP Status Code Registry

     This document establishes the ATP Status Code Registry with
     initial values as defined in Section 7.4.

  12.  References

  12.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997.

     [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.

     [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol",
                RFC 5321, DOI 10.17487/RFC5321, October 2008.

     [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
                Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515,
                May 2015.

     [RFC7516]  Jones, M. and J. Hildebrand, "JSON Web Encryption
                (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
                RFC 2119 Key Words", BCP 14, RFC 8174,
                DOI 10.17487/RFC8174, May 2017.

     [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.

  12.2.  Informative References

     [I-D.sharif-mcps-secure-mcp]
                Sharif, R., "MCPS: Cryptographic Security Layer for
                the Model Context Protocol", Internet-Draft
                draft-sharif-mcps-secure-mcp-00, March 2026.

     [I-D.sharif-agent-payment-trust]
                Sharif, R., "Trust Scoring and Payment Authorisation
                for Autonomous AI Agents", Internet-Draft
                draft-sharif-agent-payment-trust-00, March 2026.

     [I-D.sharif-openid-agent-identity]
                Sharif, R., "OpenID Connect Agent Identity Claims for
                Autonomous AI Agents", Internet-Draft
                draft-sharif-openid-agent-identity-00, March 2026.

     [A2A]      Google, "Agent-to-Agent Protocol Specification",
                2025, <https://google.github.io/A2A/>.

     [MCP]      Anthropic, "Model Context Protocol Specification",
                2024, <https://spec.modelcontextprotocol.io/>.

     [FIPA-ACL] Foundation for Intelligent Physical Agents, "FIPA
                ACL Message Structure Specification", SC00061G,
                2002.

  Appendix A.  Comparison with Existing Protocols

     +------------------+----------+----------+----------+----------+
     | Feature          | SMTP     | A2A      | MCP      | ATP      |
     +------------------+----------+----------+----------+----------+
     | Communication    | Async    | Sync RPC | Sync RPC | Async    |
     | Store-and-forward| Yes      | No       | No       | Yes      |
     | Payload type     | Message  | Task     | Tool call| Agent    |
     | Identity         | Optional | Agent    | None     | Mandatory|
     |                  | (DKIM)   | Card     |          | (JWS)    |
     | Trust scoring    | Spam     | No       | No       | Yes      |
     |                  | filter   |          |          | (0.0-1.0)|
     | Relay support    | Yes      | No       | No       | Yes      |
     | DNS routing      | MX       | SRV/well-| N/A      | AX       |
     |                  |          | known    |          |          |
     | Encryption       | Optional | TLS      | TLS      | Mandatory|
     |                  | (S/MIME) |          |          | (JWE)    |
     | Cross-timezone   | N/A      | No       | No       | Yes      |
     | handoff          |          |          |          |          |
     +------------------+----------+----------+----------+----------+

  Appendix B.  Example Flows

  B.1.  Cross-Timezone Agent Handoff

     A payment processing agent operates during UK business hours
     (08:00-18:00 UTC).  At 17:55 UTC, the agent has processed 65%
     of Q1 invoices.  The UK runtime transmits the agent via ATP to
     an APAC runtime for continued processing:

     1.  UK runtime serialises agent state (65% progress, remaining
         invoice list, database credentials as vault references).

     2.  UK runtime signs envelope with its ECDSA key, sets
         destination to processor@agents.apac.example.com.

     3.  ATP relay in Frankfurt accepts and forwards to APAC.

     4.  APAC runtime verifies identity chain, checks trust score
         (0.85 > 0.5 threshold), accepts agent.

     5.  APAC runtime resolves vault references, resumes processing
         at invoice #651 of 1000.

     6.  At 09:00 UTC next day, APAC runtime transmits the agent
         (now 100% complete) back to UK with results.

  B.2.  Fault-Tolerant Agent Persistence

     A research agent is running on a cloud instance scheduled for
     termination in 5 minutes:

     1.  Runtime receives SIGTERM, initiates agent checkpoint.

     2.  Agent state serialised and transmitted to relay with
         ttl_seconds=3600.

     3.  Cloud instance terminates.

     4.  Replacement instance starts, retrieves agent from relay.

     5.  Agent resumes from checkpoint.

  Author's Address

     Raza Sharif
     CyberSecAI Ltd
     London
     United Kingdom

     Email: raza.sharif@outlook.com
     URI:   https://cybersecai.co.uk


name: draft-sharif-agent-audit-trail
rev: 00
title: Agent Audit Trail: A Standard Logging Format for Autonomous AI Systems
time: 2026-03-29T16:06:17Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-30T16:06:17Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Data formats/interop", "Policy/governance", "AI safety/alignment"]
tags: []
fetched_at: 2026-05-22T09:24:41.698273+00:00
source: ietf
abstract:
  This document specifies a standard logging format for autonomous
     AI agent systems.  The Agent Audit Trail (AAT) defines a
     JSON-based record structure with mandatory fields for agent
     identity, action classification, outcome tracking, and trust
     level reporting.  Records are linked via tamper-evident hash
     chaining using SHA-256 per RFC 8785, with optional ECDSA
     signatures for non-repudiation.

     The format addresses requirements from the EU AI Act
     (Regulation 2024/1689), which mandates automatic recording of
     events for high-risk AI systems effective August 2026.  It also
     maps to SOC 2 Trust Services Criteria, ISO/IEC 42001, and
     PCI DSS v4.0.1 logging requirements.

     The design is transport-agnostic and supports export to JSONL,
     Syslog (RFC 5424), and CSV while preserving chain integrity.
     Privacy is addressed through input/output hashing and tombstone-
     based deletion compatible with GDPR Article 17.

full_text:
  Internet Engineering Task Force                               R. Sharif
  Internet-Draft                                            CyberSecAI Ltd
  Intended status: Standards Track                          March 29, 2026
  Expires: September 29, 2026


     Agent Audit Trail: A Standard Logging Format for Autonomous AI
                                  Systems
                    draft-sharif-agent-audit-trail-00

  Abstract

     This document specifies a standard logging format for autonomous
     AI agent systems.  The Agent Audit Trail (AAT) defines a
     JSON-based record structure with mandatory fields for agent
     identity, action classification, outcome tracking, and trust
     level reporting.  Records are linked via tamper-evident hash
     chaining using SHA-256 per RFC 8785, with optional ECDSA
     signatures for non-repudiation.

     The format addresses requirements from the EU AI Act
     (Regulation 2024/1689), which mandates automatic recording of
     events for high-risk AI systems effective August 2026.  It also
     maps to SOC 2 Trust Services Criteria, ISO/IEC 42001, and
     PCI DSS v4.0.1 logging requirements.

     The design is transport-agnostic and supports export to JSONL,
     Syslog (RFC 5424), and CSV while preserving chain integrity.
     Privacy is addressed through input/output hashing and tombstone-
     based deletion compatible with GDPR Article 17.

  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 September 29, 2026.

  Copyright Notice

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

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . .  3
       1.1.  The Problem . . . . . . . . . . . . . . . . . . . . . .  3
       1.2.  Design Goals  . . . . . . . . . . . . . . . . . . . . .  4
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.  Audit Record Format . . . . . . . . . . . . . . . . . . . .  5
       3.1.  Mandatory Fields  . . . . . . . . . . . . . . . . . . .  5
       3.2.  Optional Fields . . . . . . . . . . . . . . . . . . . .  8
       3.3.  Field Constraints . . . . . . . . . . . . . . . . . . .  9
     4.  Tamper-Evident Chaining . . . . . . . . . . . . . . . . . . 10
       4.1.  Hash Computation  . . . . . . . . . . . . . . . . . . . 10
       4.2.  Signature Envelope  . . . . . . . . . . . . . . . . . . 11
       4.3.  Chain Verification  . . . . . . . . . . . . . . . . . . 11
     5.  Action Type Definitions . . . . . . . . . . . . . . . . . . 12
       5.1.  tool_call . . . . . . . . . . . . . . . . . . . . . . . 12
       5.2.  tool_response . . . . . . . . . . . . . . . . . . . . . 13
       5.3.  decision  . . . . . . . . . . . . . . . . . . . . . . . 13
       5.4.  delegation  . . . . . . . . . . . . . . . . . . . . . . 13
       5.5.  escalation  . . . . . . . . . . . . . . . . . . . . . . 14
       5.6.  error . . . . . . . . . . . . . . . . . . . . . . . . . 14
       5.7.  lifecycle . . . . . . . . . . . . . . . . . . . . . . . 14
     6.  Session Structure . . . . . . . . . . . . . . . . . . . . . 15
       6.1.  Genesis Record  . . . . . . . . . . . . . . . . . . . . 15
       6.2.  Ordered Chain . . . . . . . . . . . . . . . . . . . . . 15
       6.3.  Session Close . . . . . . . . . . . . . . . . . . . . . 16
     7.  Retention Requirements  . . . . . . . . . . . . . . . . . . 16
       7.1.  High-Risk Systems . . . . . . . . . . . . . . . . . . . 16
       7.2.  General-Purpose Systems . . . . . . . . . . . . . . . . 17
       7.3.  Tombstone Records . . . . . . . . . . . . . . . . . . . 17
     8.  Export Formats  . . . . . . . . . . . . . . . . . . . . . . 17
       8.1.  JSONL (Primary) . . . . . . . . . . . . . . . . . . . . 18
       8.2.  Syslog (RFC 5424) . . . . . . . . . . . . . . . . . . . 18
       8.3.  CSV . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     9.  Regulatory Mapping  . . . . . . . . . . . . . . . . . . . . 19
       9.1.  EU AI Act . . . . . . . . . . . . . . . . . . . . . . . 19
       9.2.  SOC 2 . . . . . . . . . . . . . . . . . . . . . . . . . 20
       9.3.  ISO/IEC 42001 . . . . . . . . . . . . . . . . . . . . . 20
       9.4.  PCI DSS v4.0.1 . . . . . . . . . . . . . . . . . . . . 20
     10. Privacy Considerations  . . . . . . . . . . . . . . . . . . 21
       10.1. Data Minimization . . . . . . . . . . . . . . . . . . . 21
       10.2. Right to Erasure  . . . . . . . . . . . . . . . . . . . 21
     11. Security Considerations . . . . . . . . . . . . . . . . . . 22
       11.1. Log Tampering . . . . . . . . . . . . . . . . . . . . . 22
       11.2. Log Injection . . . . . . . . . . . . . . . . . . . . . 22
       11.3. Timing Attacks  . . . . . . . . . . . . . . . . . . . . 23
       11.4. Chain Breaks  . . . . . . . . . . . . . . . . . . . . . 23
     12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23
       12.1. Action Type Registry  . . . . . . . . . . . . . . . . . 23
       12.2. Outcome Registry  . . . . . . . . . . . . . . . . . . . 24
     13. References  . . . . . . . . . . . . . . . . . . . . . . . . 24
       13.1. Normative References  . . . . . . . . . . . . . . . . . 24
       13.2. Informative References  . . . . . . . . . . . . . . . . 25
     Appendix A.  Example Audit Trail  . . . . . . . . . . . . . . . 26
     Appendix B.  EU AI Act Compliance Checklist . . . . . . . . . . 31
     Appendix C.  Implementation Notes . . . . . . . . . . . . . . . 32
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . 34

  1.  Introduction

  1.1.  The Problem

     The EU Artificial Intelligence Act (Regulation 2024/1689) enters
     full application on 2 August 2026.  Article 12 requires that
     high-risk AI systems "shall technically allow for the automatic
     recording of events ('logs') over the lifetime of the system."
     Article 12(2) further specifies that logging capabilities shall
     conform to recognized standards or common specifications.

     Despite this regulatory mandate, no standard exists for HOW
     autonomous AI agents should log their activities.  Current
     approaches suffer from several deficiencies:

     o  Proprietary formats that vary across vendors, making cross-
        system auditing impossible.

     o  No tamper-evidence, allowing post-hoc modification of logs
        without detection.

     o  Inconsistent action taxonomies that prevent meaningful
        comparison of agent behavior across implementations.

     o  No linkage between agent identity and logged actions,
        making attribution unreliable.

     o  No session structure, making it impossible to reconstruct
        the full sequence of an agent's autonomous decision chain.

     This document fills this gap by defining the Agent Audit Trail
     (AAT), a standard JSON-based logging format with tamper-evident
     chaining, a defined action taxonomy, and explicit regulatory
     mapping.

  1.2.  Design Goals

     The AAT format is designed with the following goals:

     o  Regulatory compliance: Direct mapping to EU AI Act
        Article 12 requirements and other frameworks.

     o  Tamper evidence: Hash-chained records that make
        unauthorized modification detectable.

     o  Interoperability: A single format usable across different
        agent frameworks, model providers, and orchestration
        systems.

     o  Privacy by design: No raw personal data in records;
        cryptographic hashes of inputs and outputs instead.

     o  Transport agnostic: Exportable to JSONL, Syslog, and CSV
        without losing chain integrity.

     o  Incremental adoption: Mandatory fields are minimal;
        optional fields support progressive enhancement.

  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 capitalized form, as shown here.

     Agent:  An autonomous software system that uses one or more
        large language models to make decisions and take actions
        with limited or no human intervention per action.

     Agent Audit Trail (AAT):  An ordered sequence of audit records
        produced by an agent during a session, linked by hash
        chaining.

     Audit Record:  A single JSON object representing one logged
        event in an agent's operation.

     Session:  A bounded sequence of agent operations that begins
        with a genesis record and ends with a session close record.

     Genesis Record:  The first record in a session, which has no
        parent and establishes the chain root.

     Tombstone Record:  A record that replaces a deleted record's
        content while preserving the hash chain.

     Trust Level:  A classification from L0 (no verification) to
        L4 (full mutual authentication with revocation checking)
        as defined in [MCPS].

     Action Type:  A controlled vocabulary value describing the
        category of agent activity being logged.

     Chain Hash:  The SHA-256 digest of the previous record's
        canonical JSON representation, linking records into a
        tamper-evident sequence.

  3.  Audit Record Format

     Each audit record is a JSON object.  Fields are divided into
     mandatory (MUST be present in every record) and optional (MAY
     be present based on the action type and deployment context).

  3.1.  Mandatory Fields

     record_id:  String.  REQUIRED.  A UUID version 4 [RFC9562]
        uniquely identifying this record.  Implementations MUST
        generate a fresh UUIDv4 for each record.  Duplicate
        record_id values within a session indicate a processing
        error and MUST be flagged by validators.

        Example: "f47ac10b-58cc-4372-a567-0e02b2c3d479"

     timestamp:  String.  REQUIRED.  The time at which the event
        occurred, formatted per RFC 3339 [RFC3339] with mandatory
        UTC offset.  Implementations SHOULD use UTC (indicated by
        "Z" suffix).  Millisecond precision is RECOMMENDED.
        Microsecond precision is OPTIONAL.

        Example: "2026-03-29T14:30:00.123Z"

     agent_id:  String.  REQUIRED.  A URI [RFC3986] uniquely
        identifying the agent instance.  This SHOULD be a
        persistent identifier that survives agent restarts.  When
        used with MCPS [MCPS], this MUST match the agent_id in the
        Agent Passport.

        Example: "urn:agent:payment-bot.acme.example"

     agent_version:  String.  REQUIRED.  The semantic version
        [SEMVER] of the agent software.  This allows correlation
        of behavior changes with software updates.

        Example: "2.1.0"

     session_id:  String.  REQUIRED.  A UUID version 4 identifying
        the current session.  All records within a single session
        MUST share the same session_id.

        Example: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"

     action_type:  String.  REQUIRED.  One of the registered
        action type values defined in Section 5.  The initial
        registry contains: "tool_call", "tool_response",
        "decision", "delegation", "escalation", "error",
        "lifecycle".

     action_detail:  Object.  REQUIRED.  A JSON object containing
        action-type-specific fields as defined in Section 5.  The
        structure of this object varies by action_type.  Unknown
        fields within action_detail SHOULD be preserved by
        processors.

     outcome:  String.  REQUIRED.  The result of the action.  One
        of the registered outcome values: "success", "failure",
        "timeout", "denied", "escalated".  See Section 12.2 for
        the outcome registry.

        o  "success": The action completed as intended.

        o  "failure": The action did not complete due to an error.

        o  "timeout": The action exceeded its time budget.

        o  "denied": The action was blocked by a policy or
           authorization check.

        o  "escalated": The action was redirected to a human or
           higher-authority agent.

     trust_level:  String.  REQUIRED.  The trust level at which
        the agent was operating when this action occurred.  One of:
        "L0", "L1", "L2", "L3", "L4".

        o  L0: No verification.  The agent has no cryptographic
           identity.

        o  L1: Self-signed identity.  The agent possesses a key
           pair but no external attestation.

        o  L2: Authority-signed identity.  A Trust Authority has
           issued the agent's passport.

        o  L3: Mutual authentication.  Both parties have verified
           each other's identity.

        o  L4: Full mutual authentication with revocation
           checking and continuous monitoring.

     parent_record_id:  String or null.  REQUIRED.  The record_id
        of the immediately preceding record in the session chain.
        For genesis records (the first record in a session), this
        field MUST be null.  For all subsequent records, this MUST
        contain the record_id of the previous record.

     prev_hash:  String or null.  REQUIRED.  The SHA-256 hash of
        the canonical JSON representation (per RFC 8785 [RFC8785])
        of the previous record.  For genesis records, this field
        MUST be null.  The hash MUST be encoded as a lowercase
        hexadecimal string (64 characters).

        Example: "a7ffc6f8bf1ed76651c14756a061d662..."

  3.2.  Optional Fields

     The following fields are OPTIONAL and MAY be included in any
     audit record:

     human_override:  Object.  Present when a human intervened in
        or overrode the agent's action.  Contains:

        o  "operator_id": String.  An identifier for the human
           operator (SHOULD be a pseudonym or role, not a real
           name, for privacy).

        o  "reason": String.  Free-text explanation of the
           override.

        o  "original_action": Object.  The action the agent would
           have taken without intervention.

     risk_score:  Number.  A value between 0.0 and 1.0 indicating
        the agent's assessed risk of the action.  0.0 indicates
        minimal risk; 1.0 indicates maximum risk.

     model_id:  String.  The identifier of the language model used
        for the decision.  Example: "gpt-4o-2025-03-01" or
        "claude-sonnet-4-20250514".

     input_hash:  String.  The SHA-256 hash of the input provided
        to the agent for this action, encoded as lowercase
        hexadecimal.  Used instead of raw input to preserve
        privacy.

     output_hash:  String.  The SHA-256 hash of the output
        produced by the agent for this action, encoded as
        lowercase hexadecimal.

     latency_ms:  Number.  The wall-clock time in milliseconds
        from action initiation to completion.

     cost_estimate:  Object.  Estimated cost of the action:

        o  "amount": Number.  The monetary amount.

        o  "currency": String.  ISO 4217 currency code.

        o  "breakdown": Object.  Optional sub-costs (e.g.,
           "compute", "api_calls", "tokens").

     sanctions_check:  Object.  Result of sanctions screening:

        o  "provider": String.  The screening provider.

        o  "checked_at": String.  RFC 3339 timestamp of check.

        o  "result": String.  One of "clear", "match", "error".

        o  "list_version": String.  Version of the sanctions list.

     jurisdiction:  String.  ISO 3166-1 alpha-2 country code
        indicating the jurisdiction governing this action.

     signature:  String.  An ECDSA P-256 signature over the
        canonical JSON of this record (excluding the signature
        field itself), encoded as Base64url per RFC 4648
        Section 5.  See Section 4.2.

  3.3.  Field Constraints

     The following constraints apply to all audit records:

     o  All string fields MUST be valid UTF-8.

     o  The total size of a single audit record SHOULD NOT exceed
        64 KB when serialized as JSON.  Records exceeding 256 KB
        MUST be rejected by validators.

     o  Timestamps MUST NOT be backdated.  The timestamp of record
        N+1 MUST be greater than or equal to the timestamp of
        record N within the same session.

     o  The action_detail object MUST contain at least one field
        relevant to the action_type.

     o  Implementations MUST NOT add fields with names beginning
        with "aat_" to action_detail, as this prefix is reserved
        for future extensions of this specification.

  4.  Tamper-Evident Chaining

  4.1.  Hash Computation

     The prev_hash field creates a tamper-evident chain across all
     records in a session.  The hash is computed as follows:

     1.  Take the complete JSON object of the previous record,
         INCLUDING all fields (mandatory and optional) that were
         present in the record as stored.

     2.  Serialize the JSON object using the JSON Canonicalization
         Scheme (JCS) defined in RFC 8785 [RFC8785].  JCS
         produces a deterministic byte sequence from any JSON
         value.

     3.  Compute the SHA-256 hash of the canonical byte sequence.

     4.  Encode the resulting 32-byte hash as a 64-character
         lowercase hexadecimal string.

     The formula is:

         prev_hash(N) = hex(SHA-256(JCS(record(N-1))))

     For the genesis record (N=0), prev_hash MUST be null.

     Implementations MUST use JCS (RFC 8785) for canonicalization.
     Alternative canonicalization schemes MUST NOT be used, as they
     would break chain verification across implementations.

  4.2.  Signature Envelope

     When cryptographic non-repudiation is required, records MAY
     include an ECDSA P-256 signature.  The signing procedure is:

     1.  Construct the complete audit record with all fields
         EXCEPT the "signature" field.

     2.  Serialize using JCS (RFC 8785).

     3.  Compute SHA-256 of the canonical bytes.

     4.  Sign the hash using ECDSA P-256 with the agent's private
         key, per FIPS 186-5 [FIPS186-5].

     5.  Encode the signature as Base64url (RFC 4648 Section 5)
         using IEEE P1363 fixed-length r||s encoding (64 bytes
         total: 32 bytes r, 32 bytes s).

     6.  Add the "signature" field to the record.

     When verifying, the verifier MUST remove the "signature" field
     before computing the hash for comparison.

     Note: When both prev_hash and signature are present, prev_hash
     is computed over the COMPLETE previous record INCLUDING its
     signature field.  Only the current record's signature is
     excluded during signing of the current record.

     When used with MCPS [MCPS], the signing key SHOULD be the same
     key used in the agent's Agent Passport, providing a direct
     binding between audit records and cryptographic identity.

  4.3.  Chain Verification

     To verify a session's audit trail integrity, a verifier MUST:

     1.  Confirm the first record has parent_record_id = null and
         prev_hash = null.

     2.  For each subsequent record N (where N > 0):

         a.  Compute hex(SHA-256(JCS(record(N-1)))).

         b.  Compare the computed hash with record(N).prev_hash.

         c.  If the values differ, the chain is broken at
             record N and the trail MUST be flagged as tampered.

     3.  If signatures are present, verify each signature using
         the agent's public key.

     4.  Verify that timestamps are monotonically non-decreasing.

     5.  Verify that parent_record_id of record N equals the
         record_id of record N-1.

     A chain verification failure MUST be reported as a critical
     integrity error.  Partial chain verification (e.g., verifying
     only the last K records) is NOT RECOMMENDED but MAY be used
     for performance reasons if the full chain has been previously
     verified.

  5.  Action Type Definitions

     Each action type defines a specific structure for the
     action_detail object.

  5.1.  tool_call

     Logged when the agent invokes an external tool or API.

     action_detail fields:

     o  "tool_name": String.  REQUIRED.  The name of the tool
        being called.

     o  "tool_server": String.  OPTIONAL.  URI of the MCP server
        or API endpoint providing the tool.

     o  "parameters_hash": String.  REQUIRED.  SHA-256 hash of
        the serialized parameters sent to the tool.

     o  "tool_version": String.  OPTIONAL.  Version of the tool
        definition.

     o  "authorization": String.  OPTIONAL.  The authorization
        mechanism used (e.g., "bearer_token", "api_key",
        "mutual_tls").

  5.2.  tool_response

     Logged when the agent receives a response from a tool.

     action_detail fields:

     o  "tool_name": String.  REQUIRED.  The name of the tool
        that responded.

     o  "response_hash": String.  REQUIRED.  SHA-256 hash of
        the response payload.

     o  "response_size": Number.  OPTIONAL.  Size of the response
        in bytes.

     o  "parent_call_id": String.  REQUIRED.  The record_id of
        the corresponding tool_call record.

  5.3.  decision

     Logged when the agent makes an autonomous decision.

     action_detail fields:

     o  "decision_type": String.  REQUIRED.  Category of decision
        (e.g., "route", "approve", "reject", "classify",
        "generate").

     o  "reasoning_hash": String.  OPTIONAL.  SHA-256 hash of the
        agent's reasoning chain or chain-of-thought.

     o  "confidence": Number.  OPTIONAL.  Confidence score between
        0.0 and 1.0.

     o  "alternatives_considered": Number.  OPTIONAL.  Count of
        alternative actions the agent evaluated.

     o  "policy_ref": String.  OPTIONAL.  Identifier of the
        policy or rule that governed this decision.

  5.4.  delegation

     Logged when the agent delegates work to another agent.

     action_detail fields:

     o  "delegate_agent_id": String.  REQUIRED.  URI of the agent
        receiving the delegation.

     o  "delegate_trust_level": String.  REQUIRED.  Trust level
        of the delegate agent.

     o  "task_description_hash": String.  REQUIRED.  SHA-256 hash
        of the delegated task description.

     o  "constraints": Array of String.  OPTIONAL.  Constraints
        imposed on the delegate.

     o  "timeout_ms": Number.  OPTIONAL.  Maximum time allowed
        for the delegate to complete the task.

  5.5.  escalation

     Logged when the agent escalates to a human operator or
     higher-authority system.

     action_detail fields:

     o  "escalation_reason": String.  REQUIRED.  Why the agent
        escalated (e.g., "confidence_below_threshold",
        "policy_requires_human", "risk_score_exceeded",
        "error_recovery").

     o  "escalation_target": String.  REQUIRED.  Identifier of
        the human or system receiving the escalation.

     o  "context_hash": String.  OPTIONAL.  SHA-256 hash of the
        context provided to the escalation target.

     o  "urgency": String.  OPTIONAL.  One of "low", "medium",
        "high", "critical".

  5.6.  error

     Logged when the agent encounters an error condition.

     action_detail fields:

     o  "error_code": String.  REQUIRED.  A machine-readable
        error code.

     o  "error_message": String.  REQUIRED.  A human-readable
        error description.

     o  "error_category": String.  REQUIRED.  One of "transport",
        "authentication", "authorization", "validation",
        "timeout", "internal", "external".

     o  "recoverable": Boolean.  REQUIRED.  Whether the agent
        can continue operating after this error.

     o  "stack_hash": String.  OPTIONAL.  SHA-256 hash of the
        stack trace, for debugging without exposing internals.

  5.7.  lifecycle

     Logged for agent lifecycle events (start, stop, pause,
     configuration changes).

     action_detail fields:

     o  "event": String.  REQUIRED.  One of "session_start",
        "session_end", "pause", "resume",
        "configuration_change", "key_rotation",
        "trust_level_change".

     o  "previous_state": String.  OPTIONAL.  The state before
        this lifecycle event.

     o  "new_state": String.  OPTIONAL.  The state after this
        lifecycle event.

     o  "trigger": String.  OPTIONAL.  What caused the lifecycle
        event (e.g., "scheduled", "manual", "policy",
        "error_recovery").

  6.  Session Structure

  6.1.  Genesis Record

     Every session MUST begin with a genesis record.  The genesis
     record has the following characteristics:

     o  action_type MUST be "lifecycle".

     o  action_detail.event MUST be "session_start".

     o  parent_record_id MUST be null.

     o  prev_hash MUST be null.

     o  The action_detail SHOULD include the agent's configuration
        hash, enabled tools list, and operating parameters to
        establish a baseline for the session.

     Example genesis action_detail:

         {
           "event": "session_start",
           "new_state": "active",
           "trigger": "scheduled",
           "config_hash": "b5bb9d8014a0f9b1d6...",
           "enabled_tools": [
             "payment_transfer",
             "sanctions_check",
             "balance_query"
           ]
         }

  6.2.  Ordered Chain

     After the genesis record, all records MUST form a strictly
     ordered chain:

     o  Each record's parent_record_id MUST equal the previous
        record's record_id.

     o  Each record's prev_hash MUST equal
        hex(SHA-256(JCS(previous_record))).

     o  Timestamps MUST be monotonically non-decreasing.

     o  No gaps in the chain are permitted.  If a record cannot
        be produced (e.g., due to a crash), a recovery record
        with action_type "error" MUST be inserted to document the
        gap when the agent resumes.

     Branching (multiple records claiming the same parent) is NOT
     permitted within a single session.  If an agent forks into
     parallel execution paths, each path MUST use a separate
     session_id and the delegation record in the parent session
     MUST reference the child session_id.

  6.3.  Session Close

     Every session SHOULD end with a close record.  The close
     record has the following characteristics:

     o  action_type MUST be "lifecycle".

     o  action_detail.event MUST be "session_end".

     o  action_detail MUST include a "session_hash" field
        containing the SHA-256 hash of the concatenation of all
        record hashes in the session, in order:

         session_hash = hex(SHA-256(
           prev_hash(1) || prev_hash(2) || ... || prev_hash(N)
         ))

        where N is the close record itself and prev_hash values
        are the raw 32-byte digests (not hex-encoded) prior to
        concatenation.

     o  action_detail SHOULD include "record_count" (integer)
        and "duration_ms" (number) summarizing the session.

     If an agent terminates abnormally without producing a close
     record, the session is considered "orphaned."  Monitoring
     systems SHOULD detect orphaned sessions and produce a
     synthetic close record with outcome "failure" and
     action_detail.trigger "crash_recovery".

  7.  Retention Requirements

  7.1.  High-Risk Systems

     For AI systems classified as high-risk under the EU AI Act
     (Annex III), audit trail records SHOULD be retained for a
     minimum of 12 months from the session close timestamp.

     This aligns with Article 12(1) which states that logging
     capabilities shall be such that logs are kept for a period
     appropriate to the intended purpose of the high-risk AI
     system, of at least six months unless provided otherwise in
     applicable Union or national law.

     The 12-month RECOMMENDATION in this specification exceeds the
     minimum 6-month requirement to account for audit cycles and
     incident investigation timelines.

  7.2.  General-Purpose Systems

     For AI systems not classified as high-risk, audit trail
     records SHOULD be retained for a minimum of 6 months from
     the session close timestamp.

     Deployments subject to financial regulations (e.g., PCI DSS,
     SOC 2) MAY require longer retention periods as specified by
     those frameworks.

  7.3.  Tombstone Records

     When individual records must be deleted (e.g., pursuant to
     GDPR Article 17 right to erasure), the record MUST be
     replaced with a tombstone record that preserves chain
     integrity.  A tombstone record:

     o  Retains the original record_id, timestamp,
        parent_record_id, and prev_hash.

     o  Sets action_type to "lifecycle".

     o  Sets action_detail to:

         {
           "event": "record_deleted",
           "deletion_reason": "gdpr_art17",
           "deleted_at": "2026-06-15T10:00:00Z",
           "original_action_type": "tool_call"
         }

     o  Sets outcome to "success".

     o  Retains the signature field if originally present.

     The original record's content is destroyed.  Because the
     tombstone preserves the original record_id and prev_hash,
     subsequent records in the chain remain verifiable.  However,
     the prev_hash of the NEXT record will no longer match the
     tombstone (since the content changed).  To handle this,
     implementations MUST also store a "tombstone_hash" field in
     the tombstone record containing the original record's hash,
     allowing validators to accept the chain break.

  8.  Export Formats

     Implementations MUST support at least one export format.
     JSONL is the RECOMMENDED primary format.

  8.1.  JSONL (Primary)

     The primary export format is JSON Lines (JSONL), where each
     line contains exactly one complete audit record serialized
     as JSON.  Lines are separated by a single newline character
     (U+000A).

     o  Each line MUST be a valid JSON object.

     o  The order of lines MUST match the chain order
        (genesis first, close last).

     o  The file SHOULD use UTF-8 encoding without a byte order
        mark (BOM).

     o  The file extension SHOULD be ".jsonl".

  8.2.  Syslog (RFC 5424)

     For integration with existing logging infrastructure, audit
     records MAY be exported as Syslog messages per RFC 5424
     [RFC5424].  The mapping is:

     o  FACILITY: local0 (16).

     o  SEVERITY: based on outcome -- success=6 (Informational),
        failure=3 (Error), timeout=4 (Warning),
        denied=5 (Notice), escalated=5 (Notice).

     o  APP-NAME: the agent_id (truncated to 48 characters).

     o  MSGID: the action_type.

     o  STRUCTURED-DATA: SD-ID "aat@IANA-PEN" containing
        record_id, session_id, trust_level, prev_hash.

     o  MSG: JSON serialization of the full audit record.

     The prev_hash and chain integrity MUST be preserved in the
     structured data to enable reconstruction of the chain from
     Syslog archives.

  8.3.  CSV

     For human review and spreadsheet analysis, audit records MAY
     be exported as CSV per RFC 4180 [RFC4180].  The mapping is:

     o  Header row: record_id, timestamp, agent_id,
        agent_version, session_id, action_type, outcome,
        trust_level, parent_record_id, prev_hash, action_detail.

     o  The action_detail column contains the JSON serialization
        of the action_detail object.

     o  CSV export is inherently lossy for optional fields.
        Implementations SHOULD document which optional fields
        are included.

     CSV exports MUST NOT be used as the authoritative record.
     The JSONL format MUST be retained as the source of truth.

  9.  Regulatory Mapping

  9.1.  EU AI Act

     The following table maps AAT features to EU AI Act articles:

     Article 12 (Record-Keeping):
        AAT provides automatic recording via the mandatory audit
        record format (Section 3).  Hash chaining (Section 4)
        ensures records "allow the tracing back of the AI system's
        operation."  The session structure (Section 6) provides the
        "period of each use" required by Art 12(1)(c).

     Article 13 (Transparency):
        The action_type taxonomy (Section 5) and decision records
        (Section 5.3) provide interpretability of agent behavior.
        The model_id field documents which model was used.
        The human_override field documents human interventions.

     Article 14 (Human Oversight):
        The escalation action type (Section 5.5) documents when
        and why agents escalated to humans.  The human_override
        optional field (Section 3.2) captures human interventions.
        Trust levels document the degree of autonomous operation.

     Article 72 (Reporting):
        The export formats (Section 8) enable provision of logs
        to national competent authorities.  The session_hash in
        session close records (Section 6.3) provides a verifiable
        summary for regulatory reporting.

  9.2.  SOC 2

     SOC 2 Trust Services Criteria relevant to AAT:

     o  CC6.1 (Logical Access): trust_level and authorization
        fields document access controls.

     o  CC7.2 (System Monitoring): Continuous audit trail with
        tamper-evident chaining satisfies monitoring requirements.

     o  CC8.1 (Change Management): lifecycle action type records
        document configuration changes.

  9.3.  ISO/IEC 42001

     ISO/IEC 42001 (AI Management System) clauses addressed:

     o  Clause 6.1.2 (AI Risk Assessment): risk_score and
        decision records support risk documentation.

     o  Clause 8.4 (AI System Operation): Full session audit
        trails document operational behavior.

     o  Clause 9.1 (Monitoring): Continuous logging with chain
        verification supports monitoring requirements.

  9.4.  PCI DSS v4.0.1

     PCI DSS v4.0.1 requirements addressed by AAT:

     o  Requirement 10.2: AAT provides audit logs for all agent
        actions including tool calls, decisions, and errors.

     o  Requirement 10.3: Record fields (timestamp, agent_id,
        action_type, outcome) map directly to required audit
        trail entries.

     o  Requirement 10.5: Hash chaining and optional signatures
        protect audit trail integrity.

     o  Requirement 10.7: Retention requirements (Section 7)
        align with PCI DSS retention periods.

  10.  Privacy Considerations

  10.1.  Data Minimization

     AAT is designed with privacy by default:

     o  Raw input and output data MUST NOT be stored in audit
        records.  Implementations MUST use the input_hash and
        output_hash fields instead.

     o  The human_override.operator_id SHOULD be a pseudonymous
        identifier or role name, not a natural person's name.

     o  The reasoning_hash field in decision records stores a hash
        of the reasoning chain, not the reasoning itself.

     o  Tool parameters are recorded via parameters_hash, not in
        cleartext.

     o  Sanctions check results record only "clear", "match", or
        "error" -- not the details of what was screened.

     Implementations that need to retain raw data for debugging
     MUST store it in a separate system with appropriate access
     controls, linked to the audit trail via record_id.

  10.2.  Right to Erasure

     To support GDPR Article 17 (right to erasure) and similar
     regulations, AAT uses tombstone records (Section 7.3) rather
     than record deletion.  This approach:

     o  Removes all personal data from the record.

     o  Preserves chain integrity for regulatory compliance.

     o  Documents the fact and reason for deletion.

     o  Is compatible with the EU AI Act's record-keeping
        requirements, which do not require retention of personal
        data but do require retention of operational logs.

     Data controllers MUST implement a process to identify which
     audit records contain personal data (even in hashed form) and
     respond to erasure requests by creating tombstone records
     within 30 days.

  11.  Security Considerations

  11.1.  Log Tampering

     The primary threat to audit trails is unauthorized
     modification.  AAT mitigates this through:

     o  Hash chaining: Any modification to a record invalidates
        all subsequent prev_hash values, making tampering
        detectable.

     o  Optional signatures: ECDSA P-256 signatures provide
        non-repudiation and prevent even the log storage system
        from undetectably modifying records.

     o  Session hashes: The session_hash in close records provides
        a single value that can be stored externally (e.g., on a
        blockchain or with a timestamp authority) to anchor the
        entire session.

     Implementations SHOULD store session_hash values in a
     separate, append-only system to provide an independent
     verification point.

  11.2.  Log Injection

     Attackers may attempt to inject false audit records into the
     trail.  Mitigations include:

     o  Signature verification: When signatures are present, only
        records signed by the agent's key are valid.

     o  Chain continuity: Injected records would break the hash
        chain unless the attacker can also modify all subsequent
        records.

     o  Timestamp monotonicity: Injected records with out-of-
        order timestamps are detectable.

     o  Record size limits: The 256 KB maximum prevents denial-of-
        service through oversized records.

     Implementations MUST validate all records against the schema
     before accepting them into the audit trail.

  11.3.  Timing Attacks

     Audit record timestamps may be manipulated if the agent
     controls its own clock.  Mitigations include:

     o  Using NTP-synchronized clocks with drift monitoring.

     o  Cross-referencing timestamps with external systems (e.g.,
        tool server response timestamps).

     o  Flagging sessions where timestamps show suspicious
        patterns (e.g., large jumps, regression).

     Implementations SHOULD monitor for timestamp anomalies and
     flag them for human review.

  11.4.  Chain Breaks

     Chain breaks can occur due to:

     o  System crashes during record writing.

     o  Storage corruption.

     o  Intentional tampering.

     When a chain break is detected, implementations MUST:

     1.  Flag the break with a severity of "critical".

     2.  Record the break location (which record pair failed
         verification).

     3.  Preserve both the broken chain and any recovered data.

     4.  If the break is due to crash recovery, insert an error
         record documenting the gap.

     Chain breaks in high-risk systems MUST trigger an alert to
     the system operator within 1 hour.

  12.  IANA Considerations

  12.1.  Action Type Registry

     This document requests IANA to create the "Agent Audit Trail
     Action Types" registry.  The registration policy is
     "Specification Required" per RFC 8126 [RFC8126].

     Initial registry contents:

     +----------------+---------------------------+-----------+
     | Value          | Description               | Reference |
     +----------------+---------------------------+-----------+
     | tool_call      | Agent invokes a tool      | Sec 5.1   |
     | tool_response  | Agent receives tool reply  | Sec 5.2   |
     | decision       | Agent makes a decision    | Sec 5.3   |
     | delegation     | Agent delegates to agent  | Sec 5.4   |
     | escalation     | Agent escalates to human  | Sec 5.5   |
     | error          | Agent encounters error    | Sec 5.6   |
     | lifecycle      | Agent lifecycle event     | Sec 5.7   |
     +----------------+---------------------------+-----------+

     New entries MUST include a value (lowercase ASCII string,
     max 32 characters), description, and reference to a published
     specification.

  12.2.  Outcome Registry

     This document requests IANA to create the "Agent Audit Trail
     Outcomes" registry.  The registration policy is "Specification
     Required" per RFC 8126.

     Initial registry contents:

     +------------+-------------------------------+-----------+
     | Value      | Description                   | Reference |
     +------------+-------------------------------+-----------+
     | success    | Action completed as intended  | Sec 3.1   |
     | failure    | Action failed due to error    | Sec 3.1   |
     | timeout    | Action exceeded time budget   | Sec 3.1   |
     | denied     | Action blocked by policy      | Sec 3.1   |
     | escalated  | Action redirected to human    | Sec 3.1   |
     +------------+-------------------------------+-----------+

  13.  References

  13.1.  Normative References

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

     [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the
                Internet: Timestamps", RFC 3339,
                DOI 10.17487/RFC3339, July 2002,
                <https://www.rfc-editor.org/info/rfc3339>.

     [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>.

     [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>.

     [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>.

     [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>.

     [FIPS186-5]
                National Institute of Standards and Technology,
                "Digital Signature Standard (DSS)", FIPS PUB 186-5,
                DOI 10.6028/NIST.FIPS.186-5, February 2023.

     [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>.

  13.2.  Informative References

     [MCPS]     Sharif, R., "MCPS: Cryptographic Security Layer for
                the Model Context Protocol",
                draft-sharif-mcps-secure-mcp-02, March 2026.

     [EU-AI-ACT]
                European Parliament and Council, "Regulation (EU)
                2024/1689 laying down harmonised rules on artificial
                intelligence (Artificial Intelligence Act)",
                Official Journal of the European Union, L series,
                2024/1689, August 2024.

     [RFC5424]  Gerhards, R., "The Syslog Protocol", RFC 5424,
                DOI 10.17487/RFC5424, March 2009,
                <https://www.rfc-editor.org/info/rfc5424>.

     [RFC4180]  Shafranovich, Y., "Common Format and MIME Type for
                Comma-Separated Values (CSV) Files", RFC 4180,
                DOI 10.17487/RFC4180, October 2005,
                <https://www.rfc-editor.org/info/rfc4180>.

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

     [ISO42001] International Organization for Standardization,
                "Information technology -- Artificial intelligence --
                Management system", ISO/IEC 42001:2023, December
                2023.

     [PCI-DSS]  PCI Security Standards Council, "Payment Card
                Industry Data Security Standard Version 4.0.1",
                June 2024.

     [SOC2]     American Institute of Certified Public Accountants,
                "SOC 2 -- SOC for Service Organizations: Trust
                Services Criteria", 2017.

     [SEMVER]   Preston-Werner, T., "Semantic Versioning 2.0.0",
                <https://semver.org/>.

  Appendix A.  Example Audit Trail

     The following example shows a complete audit trail for a
     payment agent session that processes a GBP 500 transfer.
     The session demonstrates tool calls, decisions, sanctions
     screening, and successful completion.  prev_hash values are
     truncated for readability (shown as first 16 hex characters).

     Record 1: Genesis (session start)

     {
       "record_id": "a1000000-0000-4000-8000-000000000001",
       "timestamp": "2026-03-29T14:00:00.000Z",
       "agent_id": "urn:agent:payment-bot.acme.example",
       "agent_version": "2.1.0",
       "session_id": "sess-29mar-0001-4000-8000-abcdef123456",
       "action_type": "lifecycle",
       "action_detail": {
         "event": "session_start",
         "new_state": "active",
         "trigger": "api_request",
         "config_hash": "b5bb9d8014a0f9b1...",
         "enabled_tools": [
           "payment_transfer",
           "sanctions_check",
           "balance_query"
         ]
       },
       "outcome": "success",
       "trust_level": "L2",
       "parent_record_id": null,
       "prev_hash": null
     }

     Record 2: Sanctions screening tool call

     {
       "record_id": "a1000000-0000-4000-8000-000000000002",
       "timestamp": "2026-03-29T14:00:00.150Z",
       "agent_id": "urn:agent:payment-bot.acme.example",
       "agent_version": "2.1.0",
       "session_id": "sess-29mar-0001-4000-8000-abcdef123456",
       "action_type": "tool_call",
       "action_detail": {
         "tool_name": "sanctions_check",
         "tool_server": "https://screening.acme.example/v2",
         "parameters_hash": "e3b0c44298fc1c14...",
         "authorization": "mutual_tls"
       },
       "outcome": "success",
       "trust_level": "L2",
       "parent_record_id":
         "a1000000-0000-4000-8000-000000000001",
       "prev_hash": "7d865e959b2466918a...",
       "input_hash": "9f86d081884c7d659a...",
       "latency_ms": 145
     }

     Record 3: Sanctions screening response

     {
       "record_id": "a1000000-0000-4000-8000-000000000003",
       "timestamp": "2026-03-29T14:00:00.295Z",
       "agent_id": "urn:agent:payment-bot.acme.example",
       "agent_version": "2.1.0",
       "session_id": "sess-29mar-0001-4000-8000-abcdef123456",
       "action_type": "tool_response",
       "action_detail": {
         "tool_name": "sanctions_check",
         "response_hash": "2cf24dba5fb0a301...",
         "response_size": 256,
         "parent_call_id":
           "a1000000-0000-4000-8000-000000000002"
       },
       "outcome": "success",
       "trust_level": "L2",
       "parent_record_id":
         "a1000000-0000-4000-8000-000000000002",
       "prev_hash": "4e07408562bedb8b6...",
       "sanctions_check": {
         "provider": "acme_screening",
         "checked_at": "2026-03-29T14:00:00.290Z",
         "result": "clear",
         "list_version": "2026-03-29"
       }
     }

     Record 4: Decision to approve transfer

     {
       "record_id": "a1000000-0000-4000-8000-000000000004",
       "timestamp": "2026-03-29T14:00:00.310Z",
       "agent_id": "urn:agent:payment-bot.acme.example",
       "agent_version": "2.1.0",
       "session_id": "sess-29mar-0001-4000-8000-abcdef123456",
       "action_type": "decision",
       "action_detail": {
         "decision_type": "approve",
         "reasoning_hash": "6b86b273ff34fce1...",
         "confidence": 0.97,
         "alternatives_considered": 2,
         "policy_ref": "payment-policy-v3.2"
       },
       "outcome": "success",
       "trust_level": "L2",
       "parent_record_id":
         "a1000000-0000-4000-8000-000000000003",
       "prev_hash": "ef2d127de37b942ba...",
       "risk_score": 0.12,
       "model_id": "claude-sonnet-4-20250514",
       "cost_estimate": {
         "amount": 500.00,
         "currency": "GBP"
       }
     }

     Record 5: Payment execution tool call

     {
       "record_id": "a1000000-0000-4000-8000-000000000005",
       "timestamp": "2026-03-29T14:00:00.320Z",
       "agent_id": "urn:agent:payment-bot.acme.example",
       "agent_version": "2.1.0",
       "session_id": "sess-29mar-0001-4000-8000-abcdef123456",
       "action_type": "tool_call",
       "action_detail": {
         "tool_name": "payment_transfer",
         "tool_server": "https://payments.acme.example/v1",
         "parameters_hash": "d4735e3a265e16ee...",
         "authorization": "bearer_token"
       },
       "outcome": "success",
       "trust_level": "L2",
       "parent_record_id":
         "a1000000-0000-4000-8000-000000000004",
       "prev_hash": "e7f6c011776e8db7c...",
       "latency_ms": 890,
       "jurisdiction": "GB"
     }

     Record 6: Session close

     {
       "record_id": "a1000000-0000-4000-8000-000000000006",
       "timestamp": "2026-03-29T14:00:01.210Z",
       "agent_id": "urn:agent:payment-bot.acme.example",
       "agent_version": "2.1.0",
       "session_id": "sess-29mar-0001-4000-8000-abcdef123456",
       "action_type": "lifecycle",
       "action_detail": {
         "event": "session_end",
         "previous_state": "active",
         "new_state": "closed",
         "trigger": "task_complete",
         "session_hash": "9c22ff5f21f0b81b...",
         "record_count": 6,
         "duration_ms": 1210
       },
       "outcome": "success",
       "trust_level": "L2",
       "parent_record_id":
         "a1000000-0000-4000-8000-000000000005",
       "prev_hash": "a3a2e67ad1b8d57e2..."
     }

  Appendix B.  EU AI Act Compliance Checklist

     The following table maps EU AI Act Article 12 sub-requirements
     to specific AAT features:

     +----------------------------+-------------------------------+
     | Art 12 Requirement         | AAT Feature                   |
     +----------------------------+-------------------------------+
     | 12(1) Automatic recording  | Mandatory audit record format |
     |                            | (Section 3)                   |
     +----------------------------+-------------------------------+
     | 12(1)(a) Recording of      | session_id + ordered chain    |
     | period of each use         | (Section 6)                   |
     +----------------------------+-------------------------------+
     | 12(1)(b) Reference         | agent_id (URI) + agent_version|
     | database against which     | + model_id (Section 3)        |
     | input data has been        |                               |
     | checked                    |                               |
     +----------------------------+-------------------------------+
     | 12(1)(c) Input data for    | input_hash field              |
     | which search has led to    | (Section 3.2)                 |
     | a match                    |                               |
     +----------------------------+-------------------------------+
     | 12(1)(d) Identification    | human_override field with     |
     | of natural persons         | pseudonymous operator_id      |
     | involved in verification   | (Section 3.2)                 |
     +----------------------------+-------------------------------+
     | 12(2) Conform to           | This specification            |
     | recognised standards       |                               |
     +----------------------------+-------------------------------+
     | 12(3) Appropriate to       | Retention requirements        |
     | intended purpose, at       | (Section 7): 12 months for    |
     | least 6 months             | high-risk, 6 months general   |
     +----------------------------+-------------------------------+
     | 12(4) Providers of         | Export formats (Section 8)     |
     | high-risk AI systems       | enable log provision to       |
     | that are credit            | financial authorities         |
     | institutions               |                               |
     +----------------------------+-------------------------------+
     | Art 13 Transparency        | action_type taxonomy +        |
     |                            | decision records (Sec 5.3)    |
     +----------------------------+-------------------------------+
     | Art 14 Human oversight     | escalation type (Sec 5.5) +   |
     |                            | human_override (Sec 3.2)      |
     +----------------------------+-------------------------------+

  Appendix C.  Implementation Notes

  C.1.  Performance Considerations

     Hash computation adds overhead to each record.  Benchmarks on
     commodity hardware show:

     o  JCS canonicalization: ~0.1 ms per record (typical size).

     o  SHA-256 hash: ~0.01 ms per record.

     o  ECDSA P-256 signing: ~1-2 ms per record.

     o  Total overhead with signing: ~2 ms per record.

     For high-throughput agents (>1000 actions/second),
     implementations MAY batch records and compute hashes
     asynchronously, provided the chain order is preserved.  The
     timestamp MUST reflect the actual event time, not the time
     the hash was computed.

  C.2.  Storage Estimates

     A typical audit record (mandatory fields only) is
     approximately 500-800 bytes when serialized as JSON.  With
     optional fields, records range from 800-2000 bytes.

     For a high-activity agent producing 10,000 records per day:

     o  Daily storage: ~10-20 MB (JSONL).

     o  Monthly storage: ~300-600 MB.

     o  12-month retention: ~3.6-7.2 GB.

     Implementations SHOULD apply compression (e.g., gzip) to
     archived sessions.  Typical compression ratios for JSON
     audit data are 5:1 to 10:1.

  C.3.  Clock Synchronization

     Accurate timestamps are critical for audit trail integrity.
     Implementations MUST:

     o  Use NTP or PTP for clock synchronization.

     o  Monitor clock drift and alert if drift exceeds 100 ms.

     o  Record the clock source in the genesis record's
        action_detail when available.

     In distributed agent systems where multiple agents contribute
     to a workflow, each agent maintains its own audit trail with
     its own clock.  Cross-agent timestamp correlation SHOULD use
     the delegation record timestamps as synchronization points.

  C.4.  Relationship to MCPS

     AAT is designed to complement MCPS
     [draft-sharif-mcps-secure-mcp].  The relationship is:

     o  MCPS provides cryptographic identity (Agent Passports) and
        per-message signing for MCP protocol traffic.

     o  AAT provides the audit log format for recording what
        agents did and why.

     o  The agent_id in AAT records SHOULD match the agent_id in
        the MCPS Agent Passport.

     o  AAT signatures SHOULD use the same ECDSA P-256 key as the
        MCPS Agent Passport, providing a single cryptographic
        identity across both protocol security and audit logging.

     o  MCPS trust levels (L0-L4) are directly referenced in AAT
        records via the trust_level field.

     Implementations that deploy both MCPS and AAT achieve both
     real-time protocol security and comprehensive audit logging
     under a unified cryptographic identity.

  C.5.  Validator Implementation

     A conformant AAT validator MUST check:

     1.  Schema validation: All mandatory fields present with
         correct types.

     2.  Chain integrity: prev_hash values match computed hashes.

     3.  Temporal ordering: Timestamps are monotonically
         non-decreasing.

     4.  Session structure: Genesis record is first, close record
         is last (if present).

     5.  Referential integrity: parent_record_id values reference
         existing records.

     6.  Action type conformance: action_detail contains required
         fields for the declared action_type.

     A validator SHOULD produce a structured report indicating
     pass/fail for each check, with the specific record_id where
     failures occurred.

  Author's Address

     Raza Sharif
     CyberSecAI Ltd

     Email: contact@agentsign.dev


name: draft-hartman-credential-broker-4-agents
rev: 00
title: Credential Broker for Agents (CB4A)
time: 2026-03-29T18:35:32Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-30T18:35:32Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Policy/governance", "AI safety/alignment"]
tags: []
fetched_at: 2026-05-22T09:24:41.698277+00:00
source: ietf
abstract:
  This document specifies a Credential Broker for Agents (CB4A). a
     credential vaulting and brokering architecture that mediates AI agent
     access to API credentials.  Agents never hold real long-lived
     credentials.  Instead, they receive short-lived, narrowly scoped,
     auditable proxy credentials issued by a broker that separates policy
     decisions from credential delivery.  The architecture addresses the
     "credential sprawl" risk inherent in agentic AI, where agents
     aggregating access across many services become high-value compromise
     targets.

     CB4A builds on SPIFFE/SPIRE for workload identity, uses a Policy
     Decision Point / Credential Delivery Point separation inspired by
     NIST SP 800-207, and employs DPoP (RFC 9449) for sender-constrained
     token binding.  The specification defines three credential proxy
     models, a tiered approval framework, and a comprehensive threat model
     with ten identified threats and their mitigations.

full_text:
  Network Working Group                                         K. Hartman
  Internet-Draft                                            SANS Institute
  Intended status: Informational                             29 March 2026
  Expires: 30 September 2026


                    Credential Broker for Agents (CB4A)
                draft-hartman-credential-broker-4-agents-00

  Abstract

     This document specifies a Credential Broker for Agents (CB4A). a
     credential vaulting and brokering architecture that mediates AI agent
     access to API credentials.  Agents never hold real long-lived
     credentials.  Instead, they receive short-lived, narrowly scoped,
     auditable proxy credentials issued by a broker that separates policy
     decisions from credential delivery.  The architecture addresses the
     "credential sprawl" risk inherent in agentic AI, where agents
     aggregating access across many services become high-value compromise
     targets.

     CB4A builds on SPIFFE/SPIRE for workload identity, uses a Policy
     Decision Point / Credential Delivery Point separation inspired by
     NIST SP 800-207, and employs DPoP (RFC 9449) for sender-constrained
     token binding.  The specification defines three credential proxy
     models, a tiered approval framework, and a comprehensive threat model
     with ten identified threats and their mitigations.

  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 30 September 2026.







  Hartman                 Expires 30 September 2026               [Page 1]


  Internet-Draft                    CB4A                        March 2026


  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
       1.2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.3.  Real-World Motivation . . . . . . . . . . . . . . . . . .   4
       1.4.  Why a Credential Broker for Agents  . . . . . . . . . . .   4
     2.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   5
       2.1.  Design Philosophy . . . . . . . . . . . . . . . . . . . .   5
       2.2.  System Architecture . . . . . . . . . . . . . . . . . . .   5
       2.3.  Scalability Philosophy  . . . . . . . . . . . . . . . . .   6
       2.4.  Trust Boundaries  . . . . . . . . . . . . . . . . . . . .   7
       2.5.  Credential Flow . . . . . . . . . . . . . . . . . . . . .   7
     3.  Credential Proxy Models . . . . . . . . . . . . . . . . . . .   8
       3.1.  Model A: Proxy Gateway  . . . . . . . . . . . . . . . . .   8
       3.2.  Model B: Short-Lived Token Minting  . . . . . . . . . . .   9
       3.3.  Model C: Credential Wrapping with Scheduled Revocation  .  10
       3.4.  Model Comparison  . . . . . . . . . . . . . . . . . . . .  10
       3.5.  CB4A Model Strategy . . . . . . . . . . . . . . . . . . .  11
     4.  Technical Design  . . . . . . . . . . . . . . . . . . . . . .  11
       4.1.  SPIRE-Based Identity Layer  . . . . . . . . . . . . . . .  11
       4.2.  Task Request Envelope . . . . . . . . . . . . . . . . . .  12
       4.3.  Policy Decision Point (PDP) . . . . . . . . . . . . . . .  12
       4.4.  Credential Delivery Point (CDP) . . . . . . . . . . . . .  13
       4.5.  Sender-Constrained Tokens . . . . . . . . . . . . . . . .  14
       4.6.  Tiered Approval Service . . . . . . . . . . . . . . . . .  15
         4.6.1.  Approval Routing (Enterprise) . . . . . . . . . . . .  15
         4.6.2.  Approval Fatigue Countermeasures  . . . . . . . . . .  16
       4.7.  Immutable Audit Trail . . . . . . . . . . . . . . . . . .  16
       4.8.  Compromise Detection  . . . . . . . . . . . . . . . . . .  17
       4.9.  Secure Degradation  . . . . . . . . . . . . . . . . . . .  17
       4.10. Broker Bypass Prevention  . . . . . . . . . . . . . . . .  18
         4.10.1.  Lesson 1: Agents Must Not Have Direct Credential
                 Access  . . . . . . . . . . . . . . . . . . . . . . .  18
         4.10.2.  Lesson 2: Network-Level Enforcement Over Agent
                 Cooperation . . . . . . . . . . . . . . . . . . . . .  19
         4.10.3.  Lesson 3: Multimode Detection  . . . . . . . . . . .  19



  Hartman                 Expires 30 September 2026               [Page 2]


  Internet-Draft                    CB4A                        March 2026


       4.11. Native Integration Specification (Future) . . . . . . . .  19
     5.  Scalability Model . . . . . . . . . . . . . . . . . . . . . .  20
       5.1.  Home / Single-Machine Deployment  . . . . . . . . . . . .  20
       5.2.  Small Team / Startup Deployment . . . . . . . . . . . . .  20
       5.3.  Enterprise Deployment . . . . . . . . . . . . . . . . . .  20
       5.4.  CB4A-as-a-Service . . . . . . . . . . . . . . . . . . . .  21
     6.  Capability Tiers  . . . . . . . . . . . . . . . . . . . . . .  22
       6.1.  Tier 1: Core (Minimum Viable CB4A)  . . . . . . . . . . .  22
       6.2.  Tier 2: Human Oversight . . . . . . . . . . . . . . . . .  22
       6.3.  Tier 3: Advanced Threat Defense . . . . . . . . . . . . .  23
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  23
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  24
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  24
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .  24
       9.2.  Informative References  . . . . . . . . . . . . . . . . .  24
     Appendix A.  Threat Model . . . . . . . . . . . . . . . . . . . .  25
       A.1.  Methodology . . . . . . . . . . . . . . . . . . . . . . .  25
       A.2.  TM-1: Broker Compromise . . . . . . . . . . . . . . . . .  25
       A.3.  TM-2: Revocation Propagation Failure  . . . . . . . . . .  25
       A.4.  TM-3: Token Theft and Replay  . . . . . . . . . . . . . .  26
       A.5.  TM-4: Approval Bypass and Fatigue . . . . . . . . . . . .  26
       A.6.  TM-5: Justification Field Gaming  . . . . . . . . . . . .  26
       A.7.  TM-6: Multi-Agent Scope Composition . . . . . . . . . . .  27
       A.8.  TM-7: Audit Log Compromise  . . . . . . . . . . . . . . .  27
       A.9.  TM-8: Policy Engine Injection . . . . . . . . . . . . . .  27
       A.10. TM-9: Fail-Open Under Pressure  . . . . . . . . . . . . .  27
       A.11. TM-10: Approver Spoofing  . . . . . . . . . . . . . . . .  28
       A.12. TM-11: Broker Bypass  . . . . . . . . . . . . . . . . . .  28
       A.13. Threat Summary  . . . . . . . . . . . . . . . . . . . . .  29
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  29
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  29

  1.  Introduction

  1.1.  Requirements Language

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










  Hartman                 Expires 30 September 2026               [Page 3]


  Internet-Draft                    CB4A                        March 2026


  1.2.  Overview

     AI agents increasingly need to call APIs on behalf of users.  Current
     approaches give agents long-lived API keys or OAuth tokens, creating
     standing privileges that survive beyond the task, aggregate access
     across services, and make agents high-value compromise targets.  A
     compromised agent (via prompt injection, context exfiltration, or
     tool-calling manipulation) inherits all of those credentials.

     The Credential Broker for Agents (CB4A) addresses this by introducing
     a credential vaulting and brokering layer that sits between agents
     and the services they need to reach.  The agent never holds real
     credentials.  Instead, it receives short-lived, narrowly scoped,
     auditable proxy credentials.

  1.3.  Real-World Motivation

     The credential sprawl risk for AI agents is not theoretical.  In
     March 2026, the TeamPCP supply chain campaign compromised LiteLLM
     [TEAMPCP-LITELLM], an AI gateway proxy used by thousands of
     enterprises to route requests to LLM providers (OpenAI, Anthropic,
     Google Vertex AI, and others).  LiteLLM's entire purpose is to hold
     API keys for dozens of AI providers, making it one of the highest-
     density credential targets in any infrastructure.  The attackers
     injected a credential stealer into PyPI packages that harvested SSH
     keys, cloud credentials, LLM API keys, .env files, and database
     passwords from any machine running the compromised versions
     [LITELLM-SECURITY].  The campaign exfiltrated an estimated 300+ GB of
     compressed credentials affecting approximately 500,000 corporate
     identities.

     This incident illustrates precisely the problem CB4A addresses: when
     AI infrastructure concentrates long-lived credentials in a single
     process or configuration, compromise of that process yields
     catastrophic access.

  1.4.  Why a Credential Broker for Agents

     The credential sprawl problem for agentic AI is distinct from
     traditional service-to-service authentication because:

     *  Agents are semi-autonomous: they make decisions about which APIs
        to call, unlike microservices with fixed call patterns.

     *  Agent compromise vectors are novel: prompt injection, context
        window exfiltration, and tool-calling manipulation do not exist in
        traditional service architectures.




  Hartman                 Expires 30 September 2026               [Page 4]


  Internet-Draft                    CB4A                        March 2026


     *  Scope is unpredictable: an agent might need Slack write access for
        one task and GitHub admin for the next, making static scoping
        insufficient.

     *  User delegation is implicit: agents act on behalf of users without
        the user being present for each action.

  2.  Architecture Overview

  2.1.  Design Philosophy

     CB4A follows three architectural principles:

     1.  Build on SPIFFE/SPIRE, don't build bespoke: The identity,
         attestation, and certificate management problems are already
         solved.  CB4A adds an agent-specific policy and credential
         mediation layer on top.

     2.  Separate policy from credentials: The component that decides
         "yes" (PDP) MUST never touch credential material.  The component
         that dispenses credentials (CDP) MUST never make policy
         decisions.  Compromise of one does not yield the other.

     3.  Envelope as evidence, not authorization: The Task Request
         Envelope is an auditable artifact that the agent produces.  It is
         evaluated by the PDP, but the PDP's decision is based on
         independent policy evaluation and behavioral baselines (inspired
         by BeyondCorp [BEYONDCORP]), not on trusting the agent's self-
         reported justification.

  2.2.  System Architecture

     The following diagram illustrates the CB4A system architecture with
     its trust boundaries:

     +-----------------------------------------------------+
     |                    AGENT RUNTIME                     |
     |                                                      |
     |  +----------+    +-------------------+               |
     |  |  Agent   |--->| Task Request      |               |
     |  |  (SVID)  |    | Envelope          |               |
     |  +----------+    | who/what/why/TTL  |               |
     |       ^          +--------+----------+               |
     |       |                   |                          |
     |       |          +--------v----------+               |
     |       |          | SPIRE Agent       |               |
     |       |          | (workload         |               |
     |       |          |  attestation)     |               |



  Hartman                 Expires 30 September 2026               [Page 5]


  Internet-Draft                    CB4A                        March 2026


     |       |          +--------+----------+               |
     +-------|-------------------|--------------------------|
             |                   | mTLS
             |                   |
     +-------|-------------------|--------------------------|
     |       |          BROKER INFRASTRUCTURE               |
     |       |                   |                          |
     |       |          +--------v----------+               |
     |       |          | Policy Decision   |               |
     |       |          | Point (PDP)       |               |
     |       |          |                   |  +----------+ |
     |       |          | - Envelope eval   |  | Approval | |
     |       |          | - Risk scoring    |->| Service  | |
     |       |          | - Tier routing    |  | (HITL/   | |
     |       |          | - NO credential   |  |  MFA)    | |
     |       |          |   access          |  +----------+ |
     |       |          +--------+----------+               |
     |       |                   | approved                 |
     |       |                   | decision                 |
     |       |          +--------v----------+               |
     |       |          | Credential        |  +----------+ |
     |       |          | Delivery Point    |  | Vault    | |
     |       |          | (CDP)             |->| (HSM-    | |
     |       |          |                   |  |  backed) | |
     |       |          | - Token minting   |  +----------+ |
     |       |          | - Lease mgmt      |               |
     |       <----------| - Non-renewable   |  +----------+ |
     |  short-lived     |   leases          |  | Audit    | |
     |  scoped token    +-------------------+  | Trail    | |
     |                                         | (immutbl)| |
     |                                         +----------+ |
     |       +------------------------------+               |
     |       | Compromise Detection         |               |
     |       | - Canary credentials         |               |
     |       | - Confused deputy detection  |               |
     |       | - Cross-agent correlation    |               |
     |       +------------------------------+               |
     +------------------------------------------------------+

  2.3.  Scalability Philosophy

     CB4A is designed to scale from a single-machine home deployment to a
     distributed enterprise environment.  The same conceptual architecture
     applies at every scale; what changes is how components are deployed,
     not what they do.  A home user running one agent on a laptop and an
     enterprise running thousands of agents across data centers both
     benefit from the same PDP/CDP split, envelope-based evidence, and
     short-lived tokens.  These are architectural properties, not



  Hartman                 Expires 30 September 2026               [Page 6]


  Internet-Draft                    CB4A                        March 2026


     deployment choices.

  2.4.  Trust Boundaries

        +==============+================+=============================+
        | Boundary     | Separates      | Compromise of A yields      |
        +==============+================+=============================+
        | Agent /      | Workload from  | Agent identity (bounded by  |
        | SPIRE Agent  | identity       | SVID TTL)                   |
        +--------------+----------------+-----------------------------+
        | SPIRE Agent  | Identity from  | Ability to submit envelopes |
        | / PDP        | policy         | (not approve them)          |
        +--------------+----------------+-----------------------------+
        | PDP / CDP    | Policy from    | Approval decisions (not     |
        |              | credentials    | credential material)        |
        +--------------+----------------+-----------------------------+
        | CDP / Vault  | Delivery from  | Active credentials (bounded |
        |              | storage        | by HSM access policies)     |
        +--------------+----------------+-----------------------------+
        | PDP /        | Auto from      | Auto-approval only (HITL/   |
        | Approval Svc | human approval | MFA still requires human)   |
        +--------------+----------------+-----------------------------+

                                    Table 1

  2.5.  Credential Flow

     1.  Agent constructs Task Request Envelope with SVID identity.

     2.  Envelope submitted to PDP via mTLS (SPIRE-attested).

     3.  PDP evaluates envelope against policy, routes to appropriate
         approval tier.

     4.  If approved, PDP sends signed approval decision to CDP.

     5.  CDP mints short-lived, scoped token with non-renewable lease.

     6.  Token returned to agent, bound to request context.

     7.  Agent uses token directly against target service.

     8.  Token expires; re-attestation required for new token.

     9.  Full chain logged to immutable audit trail.






  Hartman                 Expires 30 September 2026               [Page 7]


  Internet-Draft                    CB4A                        March 2026


  3.  Credential Proxy Models

     CB4A defines three models for how the broker mediates credential
     access between an agent and a target service.  These models represent
     different points on a tradeoff between security isolation,
     operational complexity, and compatibility with existing APIs.

  3.1.  Model A: Proxy Gateway

     The agent never receives any real credential.  Instead, the broker
     operates a proxy endpoint that the agent calls.  The broker receives
     the agent's request, validates the agent's session token, injects the
     real API credential, forwards the request to the target service, and
     returns the response.  The agent never receives, sees, or holds the
     real credential.  The credential travels from the broker to the
     target service, but never to the agent.

     Agent --request--> CB4A Proxy --request + real cred--> Target API
     Agent <-response-- CB4A Proxy <-response------------- Target API

     Strengths:

     *  Strongest isolation: the agent never sees, holds, or transmits a
        real credential.

     *  The broker can inspect, log, and filter every request and response
        in real time.

     *  Works with any target API without requiring the target to support
        short-lived tokens.

     Weaknesses:

     *  Every API call becomes two network hops, adding latency.

     *  The proxy is a single point of failure.

     *  The proxy must understand the request/response format of every
        target API it mediates.

     *  At high scale, the proxy becomes a throughput bottleneck.

     Best for high-security environments where credential isolation is
     paramount, or as a fallback for target services that do not support
     short-lived tokens natively.






  Hartman                 Expires 30 September 2026               [Page 8]


  Internet-Draft                    CB4A                        March 2026


  3.2.  Model B: Short-Lived Token Minting

     The broker uses the real long-lived credential to mint a derivative
     short-lived token with narrow scope, then hands that short-lived
     token to the agent.  The agent uses the short-lived token to call the
     target service directly.  The token expires automatically after a
     brief TTL (seconds to minutes).  The specific minting mechanism
     varies by platform.

     Agent --req token--> CB4A Broker --mint--> Token Endpoint
     Agent <-short-lived-- CB4A Broker

     Agent --req + short-lived token--> Target API (direct)
     Agent <-response------------------ Target API

     Platform-specific minting mechanisms:

      +==========+========================+============================+
      | Platform | Mechanism              | Description                |
      +==========+========================+============================+
      | AWS      | Security Token Service | Mints temporary access     |
      |          | (STS) AssumeRole       | keys with session policies |
      |          |                        | and configurable TTL       |
      +----------+------------------------+----------------------------+
      | Google   | OAuth 2.0 + Service    | Uses generateAccessToken   |
      | Cloud    | Account Impersonation  | API to create short-lived  |
      |          |                        | OAuth 2.0 access tokens    |
      +----------+------------------------+----------------------------+
      | Azure    | Azure AD / Entra ID    | Issues short-lived OAuth   |
      |          | token endpoint         | 2.0 bearer tokens via      |
      |          |                        | client credentials flow    |
      +----------+------------------------+----------------------------+
      | GitHub   | App Installation       | Generates short-lived      |
      |          | Tokens                 | installation access tokens |
      |          |                        | scoped to repositories     |
      +----------+------------------------+----------------------------+
      | Generic  | OAuth 2.0 Token        | Exchanges long-lived token |
      |          | Exchange [RFC8693]     | for short-lived, narrowly  |
      |          |                        | scoped derivative          |
      +----------+------------------------+----------------------------+

                                   Table 2

     Strengths:

     *  No proxy bottleneck: the agent calls the target API directly.

     *  Short-lived tokens limit blast radius to the TTL window.



  Hartman                 Expires 30 September 2026               [Page 9]


  Internet-Draft                    CB4A                        March 2026


     *  Proven at massive scale across all major cloud providers.

     *  The broker only handles token minting, not ongoing proxying.

     Weaknesses:

     *  The agent holds a real (if temporary) credential in memory.

     *  Requires the target service to support short-lived minting.

     *  Scope granularity depends on the target service's token API.

     This is the RECOMMENDED primary model for CB4A.

  3.3.  Model C: Credential Wrapping with Scheduled Revocation

     For target APIs that only support long-lived credentials and have no
     mechanism for minting short-lived tokens, the broker hands the agent
     the actual long-lived credential but immediately schedules its
     revocation after the task completes or the TTL expires.

     Strengths:

     *  Works with any API regardless of token support.

     *  Simple to implement.

     Weaknesses:

     *  The agent holds a real, long-lived credential during the window,
        the weakest isolation of all three models.

     *  Revocation depends on the target service's key management.

     *  If revocation fails, the credential remains live indefinitely.

     This is the WEAKEST model and is NOT RECOMMENDED for new
     integrations.  Use only for legacy APIs with no alternative.

  3.4.  Model Comparison

     +==============+=================+================+================+
     | Property     | Model A (Proxy) | Model B (Mint) | Model C (Wrap) |
     +==============+=================+================+================+
     | Agent holds  | Never           | Temporary      | Yes (until     |
     | real cred?   |                 |                | revoked)       |
     +--------------+-----------------+----------------+----------------+
     | Latency      | High (double    | Low (one-time  | None           |



  Hartman                 Expires 30 September 2026              [Page 10]


  Internet-Draft                    CB4A                        March 2026


     | overhead     | hop)            | mint)          |                |
     +--------------+-----------------+----------------+----------------+
     | Single point | Yes (proxy)     | No             | No             |
     | of failure?  |                 |                |                |
     +--------------+-----------------+----------------+----------------+
     | Works with   | Yes             | Short-lived    | Yes            |
     | any API?     |                 | support only   |                |
     +--------------+-----------------+----------------+----------------+
     | Blast radius | Minimal         | Bounded by TTL | Full until     |
     |              |                 |                | revoked        |
     +--------------+-----------------+----------------+----------------+
     | Recommended  | DPoP fallback   | Primary model  | Legacy only    |
     | use          |                 |                |                |
     +--------------+-----------------+----------------+----------------+

                                   Table 3

  3.5.  CB4A Model Strategy

     CB4A uses Model B as the primary credential model wherever the target
     service supports short-lived token minting.  Model A is used
     selectively as a DPoP enforcement layer.  Model C is available as a
     last resort for legacy integrations but is discouraged and flagged in
     audit logs.

  4.  Technical Design

  4.1.  SPIRE-Based Identity Layer

     Agents receive identity through SPIRE [SPIRE] workload attestation.
     Each agent session gets a SPIFFE [SPIFFE] Verifiable Identity
     Document (SVID), a short-lived X.509 certificate or JWT.

     SVID Properties:

     *  TTL: matches agent session lifetime (default: 1 hour,
        configurable).

     *  SPIFFE ID format: spiffe://trust-domain/agent/{user-id}/{session-
        id}

     *  Attestation: node attestation (platform identity) plus workload
        attestation (agent process identity).

     *  Non-renewable: agent MUST re-attest to get new SVID.






  Hartman                 Expires 30 September 2026              [Page 11]


  Internet-Draft                    CB4A                        March 2026


     Trust Domain Federation: For multi-tenant or multi-organization
     deployments, SPIFFE federation enables cross-domain trust without
     sharing root CAs.

  4.2.  Task Request Envelope

     The envelope is a structured, signed evidence artifact submitted by
     the agent for every credential request.

     {
       "envelope_version": "1.0",
       "agent_svid": "<SPIFFE SVID reference>",
       "request_id": "<UUID>",
       "timestamp": "<ISO-8601>",
       "target": {
         "service": "slack",
         "action": "chat.postMessage",
         "resource": "#engineering",
         "scope": ["channels:write"]
       },
       "justification": {
         "task_id": "<originating user instruction ref>",
         "description": "Post weekly standup summary"
       },
       "ttl_seconds": 60,
       "signature": "<SVID-signed envelope hash>"
     }

     The justification.description field is auditable evidence, NOT an
     authorization input.  The PDP MUST NOT evaluate justification text
     for approval decisions.  Approval is based on: (1) agent identity
     (SVID), (2) target service/action/scope matching against policy, (3)
     behavioral baseline comparison, and (4) approval tier routing.  The
     justification exists solely for post-incident forensic
     reconstruction.

  4.3.  Policy Decision Point (PDP)

     The PDP is a stateless service that evaluates envelopes against
     policy, following the PDP/PEP separation defined in [NIST-ZTA].  It
     has zero access to credential material.

     Inputs:

     *  Task Request Envelope

     *  Agent identity (SVID validation via SPIRE)




  Hartman                 Expires 30 September 2026              [Page 12]


  Internet-Draft                    CB4A                        March 2026


     *  Policy rules (loaded from versioned policy store)

     *  Behavioral baseline (historical access patterns)

     Outputs:

     *  Signed approval decision (approved/denied/escalated)

     *  Approval tier (auto/HITL/MFA)

     *  Scope constraints (may narrow requested scope)

     *  Decision rationale (logged)

     Scope Granularity: The PDP's scope enforcement is configurable by the
     administrator.  Implementations may range from coarse service-level
     scoping (e.g., "Slack: read/write") to fine-grained resource-level
     scoping (e.g., "Slack: write to #engineering only").  The appropriate
     granularity depends on the deployment's threat model and operational
     maturity.

     Policy evaluation MUST use a typed, compiled policy language (not
     string interpolation).  Envelope fields MUST be deserialized into
     typed structures before evaluation.  No string concatenation or
     template rendering in policy evaluation paths.

     +===============+===========================+======================+
     | Tier          | Criteria                  | Approval Flow        |
     +===============+===========================+======================+
     | Tier 1 (Auto) | Low-risk, pre-authorized, | Immediate approval   |
     |               | within baseline           |                      |
     +---------------+---------------------------+----------------------+
     | Tier 2 (HITL) | Moderate risk, outside    | Async human approval |
     |               | baseline                  | via notification     |
     +---------------+---------------------------+----------------------+
     | Tier 3 (MFA)  | High risk, destructive,   | Synchronous approval |
     |               | admin-level               | with MFA challenge   |
     +---------------+---------------------------+----------------------+

                                   Table 4

  4.4.  Credential Delivery Point (CDP)

     The CDP brokers vault [VAULT] interactions and mints short-lived
     tokens.  It accepts only signed PDP approval decisions.

     Token Minting (Model B):




  Hartman                 Expires 30 September 2026              [Page 13]


  Internet-Draft                    CB4A                        March 2026


     *  CDP receives signed approval decision specifying exact scope and
        TTL.

     *  CDP retrieves base credential from HSM-backed vault (or encrypted
        local store for single-machine deployments).

     *  CDP mints a derivative short-lived token using the target
        service's native mechanism (AWS STS AssumeRole, GCP
        generateAccessToken, GitHub App installation tokens, OAuth 2.0
        Token Exchange [RFC8693], etc.).

     *  For services without native short-lived token support: CDP issues
        a CB4A proxy token and operates a thin proxy endpoint (Model A
        fallback).

     *  Token is non-renewable; expiry is absolute, no refresh.

     Lease Management:

     *  Every issued token has a lease tracked by the CDP.

     *  Leases are non-renewable by default.

     *  On lease expiry: token is invalidated, agent MUST re-attest.

     *  On anomaly detection signal: CDP can revoke active leases
        immediately.

     The CDP MUST NOT cache decrypted credentials in memory beyond the
     minting operation.  Credentials are fetched from vault, used to mint
     derivative token, and immediately zeroed.  The CDP process SHOULD run
     in a hardened runtime with no shell access, restricted outbound
     network, and memory encryption where platform supports it.

  4.5.  Sender-Constrained Tokens

     Ephemeral tokens in agent memory are extractable and replayable.
     CB4A addresses this with sender-constrained tokens using DPoP
     [RFC9449]:

     *  At token minting, agent generates an ephemeral key pair.

     *  Agent provides public key to CDP.

     *  CDP binds the minted token to the agent's public key.

     *  On each API call, agent signs the request with its private key
        (DPoP proof).



  Hartman                 Expires 30 September 2026              [Page 14]


  Internet-Draft                    CB4A                        March 2026


     *  Target service (or CB4A proxy for Model A fallback services)
        validates both the token and the DPoP proof.

     *  Stolen tokens are useless without the corresponding private key.

     For services that do not support DPoP natively, the CB4A proxy
     endpoint validates DPoP proof before injecting real credential.  This
     is the only scenario where Model A (proxy) is used, as a DPoP
     enforcement layer for services lacking native support.

  4.6.  Tiered Approval Service

     Tier 1: Auto-Approval:

     *  PDP evaluates against static policy plus behavioral baseline.

     *  Approval latency: less than 10ms.

     Tier 2: Human-in-the-Loop:

     *  Push notification to approver's device.

     *  Approver sees: agent identity, requested action, scope,
        justification.

     *  Timeout: configurable (default 5 minutes), denied on timeout.

     Tier 3: MFA-Required:

     *  Synchronous approval with multi-factor authentication.

     *  Approver MUST complete MFA challenge (FIDO2/WebAuthn, not SMS/
        TOTP).

  4.6.1.  Approval Routing (Enterprise)

     In enterprise deployments, approval requests MUST be routed to the
     appropriate human reviewer, not a generic approval queue.  The
     agent's owner or responsible team is the correct approver because
     they understand the agent's purpose, expected behavior, and
     legitimate access patterns.










  Hartman                 Expires 30 September 2026              [Page 15]


  Internet-Draft                    CB4A                        March 2026


             +===================+===============================+
             | Routing Criterion | Example                       |
             +===================+===============================+
             | Agent owner       | Agent sales-report-bot routes |
             |                   | to Sales Eng team lead        |
             +-------------------+-------------------------------+
             | Service owner     | Billing API requests route to |
             |                   | Finance team                  |
             +-------------------+-------------------------------+
             | Escalation chain  | Timeout escalates to manager  |
             |                   | or backup                     |
             +-------------------+-------------------------------+
             | On-call rotation  | After-hours routes to current |
             |                   | on-call                       |
             +-------------------+-------------------------------+

                                    Table 5

     For home/individual deployments, approval routing is trivial. all
     requests route to the single user.

  4.6.2.  Approval Fatigue Countermeasures

     *  Rate limiting on approval requests per agent per time window.

     *  Anomaly flagging when approval request patterns change.

     *  Mandatory cool-down periods after N consecutive approvals.

     *  Periodic "challenge approvals" (known-benign requests presented as
        suspicious) to verify approver attention.

  4.7.  Immutable Audit Trail

     Every interaction produces a structured, append-only log entry:
















  Hartman                 Expires 30 September 2026              [Page 16]


  Internet-Draft                    CB4A                        March 2026


     {
       "event_type": "credential_request|approval|issuance|
                      usage|expiry|revocation",
       "timestamp": "<ISO-8601>",
       "agent_spiffe_id": "spiffe://trust-domain/agent/user/session",
       "envelope_hash": "<SHA-256 of request envelope>",
       "decision": "approved|denied|escalated|timed_out",
       "decision_tier": "auto|hitl|mfa",
       "credential_scope": ["channels:write"],
       "credential_ttl_seconds": 60,
       "target_service": "slack",
       "target_action": "chat.postMessage",
       "approver_identity": "<human approver ID or 'auto'>",
       "correlation_id": "<links related events>"
     }

     Storage: Write-once storage (append-only log, S3 with object lock, or
     dedicated SIEM).  Log pipeline failures MUST trigger fail-closed
     behavior; no credentials issued if audit trail is unavailable.

     Audit trail MUST be written to a separate trust boundary from both
     PDP and CDP.  Neither PDP nor CDP has write access to modify or
     delete existing log entries.  Log integrity is verified via hash
     chaining.

  4.8.  Compromise Detection

     Canary Credentials: Seed the credential store with tokens that should
     never be used.  Any access to a canary triggers immediate alert and
     session termination.

     Confused Deputy Detection: Monitor for credential requests where the
     agent identity and the task context do not match.

     Cross-Agent Correlation: Monitor for coordinated multi-agent access
     patterns that individually appear benign but collectively constitute
     data exfiltration or privilege escalation.

     Runtime Behavior Monitoring (Recommended): Runtime monitoring of
     post-issuance credential usage is highly valuable.  Even a short-
     lived token can cause significant damage if misused.  Implementations
     SHOULD include anomaly detection on API call patterns, mid-flight
     kill switches, and behavioral baselines.

  4.9.  Secure Degradation

     CB4A specifies secure degradation behavior for every failure mode:




  Hartman                 Expires 30 September 2026              [Page 17]


  Internet-Draft                    CB4A                        March 2026


         +=================+======================+==================+
         | Failure         | Behavior             | Rationale        |
         +=================+======================+==================+
         | PDP unavailable | Fail-closed          | Policy cannot be |
         |                 |                      | evaluated        |
         +-----------------+----------------------+------------------+
         | CDP unavailable | Fail-closed          | Credentials      |
         |                 |                      | cannot be minted |
         +-----------------+----------------------+------------------+
         | Vault           | Fail-closed          | Base credentials |
         | unavailable     |                      | inaccessible     |
         +-----------------+----------------------+------------------+
         | Audit trail     | Fail-closed          | Cannot maintain  |
         | unavailable     |                      | chain of custody |
         +-----------------+----------------------+------------------+
         | Approval svc    | Tier 1 continues;    | Preserve low-    |
         | unavailable     | Tier 2/3 denied      | risk operations  |
         +-----------------+----------------------+------------------+
         | SPIRE           | No new sessions;     | Identity cannot  |
         | unavailable     | existing SVIDs valid | be attested      |
         +-----------------+----------------------+------------------+

                                    Table 6

     Emergency Break-Glass: Requires two-person authorization (dual key).
     Bypasses PDP but still logs through audit trail.  Automatically
     expires after configurable window (default: 30 minutes).  Triggers
     mandatory post-incident review.

  4.10.  Broker Bypass Prevention

     A credential broker is only effective if agents cannot circumvent it
     to access credentials directly.  This is analogous to the bypass
     problem faced by Cloud Access Security Brokers (CASBs), which must
     prevent users and applications from reaching cloud services outside
     the broker's mediation.

     CB4A draws three architectural lessons from CASB deployments:

  4.10.1.  Lesson 1: Agents Must Not Have Direct Credential Access

     The most fundamental control: real credentials MUST be stored in a
     vault that agents cannot access directly.  The agent runtime MUST NOT
     have network connectivity to the vault, IAM permissions to read
     secrets, or file system access to credential stores.  Only the CDP
     has vault access.  This is the CB4A equivalent of a CASB's network-
     level enforcement: if the agent cannot reach the credentials, it
     cannot bypass the broker.



  Hartman                 Expires 30 September 2026              [Page 18]


  Internet-Draft                    CB4A                        March 2026


  4.10.2.  Lesson 2: Network-Level Enforcement Over Agent Cooperation

     CASB experience shows that agent-based enforcement (where the agent
     voluntarily routes traffic through the broker) is weaker than
     network-level enforcement (where the network prevents direct access).
     CB4A implementations SHOULD enforce broker mediation at the
     infrastructure level:

     *  Network policies (firewall rules, security groups, or Kubernetes
        NetworkPolicy) that block agent-to-service direct communication
        for brokered services.

     *  Service mesh sidecars that intercept outbound traffic and validate
        CB4A tokens before forwarding.

     *  DNS-level controls that resolve brokered service endpoints to the
        CB4A proxy rather than the real service.

     Relying solely on the agent's cooperation to use the broker is
     insufficient; a compromised agent will attempt to call services
     directly if network-level controls do not prevent it.

  4.10.3.  Lesson 3: Multimode Detection

     Even with network-level enforcement, sophisticated bypass attempts
     may succeed (e.g., tunneling through allowed endpoints).  CASB
     architectures address this with API-based monitoring alongside inline
     enforcement.  CB4A implementations SHOULD:

     *  Monitor target service audit logs for API calls that did not
        originate from the CB4A proxy or use CB4A-issued tokens.

     *  Alert on credential usage patterns that do not match CB4A audit
        trail records (indicating credentials were used outside the
        broker).

     *  Implement canary detection at the service level, not just at the
        vault level.

  4.11.  Native Integration Specification (Future)

     If CB4A achieves sufficient adoption, target services could natively
     validate CB4A-issued credentials.  CB4A-native tokens would be JWTs
     containing:

     *  iss: CB4A broker SPIFFE ID

     *  sub: Agent SPIFFE ID



  Hartman                 Expires 30 September 2026              [Page 19]


  Internet-Draft                    CB4A                        March 2026


     *  aud: Target service identifier

     *  scope: Requested permissions (service-specific format)

     *  exp: Expiry timestamp (short TTL)

     *  jti: Unique token ID (for replay detection)

     *  cnf: Confirmation claim binding token to DPoP key [RFC9449]

     *  envelope_hash: SHA-256 of the originating Task Request Envelope

     Discovery: Target services would discover CB4A broker endpoints via a
     well-known URI (.well-known/cba-configuration) publishing the JWKS
     URL, supported scopes, and token format version.

  5.  Scalability Model

     CB4A separates logical components from their deployment topology.
     The same security properties hold at every scale.

  5.1.  Home / Single-Machine Deployment

     A single user running AI agents on a personal workstation.  All CB4A
     components run as local processes or lightweight containers on the
     same machine.  A minimal deployment uses three components: SPIRE
     (identity), PDP (policy), and a credential proxy that combines CDP
     and vault access.

     The trust model is identical to enterprise, just deployed on one
     machine instead of across a network.

  5.2.  Small Team / Startup Deployment

     A team of 5-50 people with multiple agents across workstations and
     CI/CD pipelines.  Deploys the same three core components as a home
     deployment (SPIRE, PDP, credential proxy), with the option to
     separate the credential proxy into distinct CDP and vault integration
     services as the team grows.

  5.3.  Enterprise Deployment

     Thousands of agents across multiple teams, data centers, and trust
     domains.  Typically uses five or more components with dedicated
     infrastructure per component, including federated SPIRE, HSM-backed
     vault clusters, and full cross-agent correlation.

     Hardware attestation (TPM/TEE) is required at enterprise scale.



  Hartman                 Expires 30 September 2026              [Page 20]


  Internet-Draft                    CB4A                        March 2026


  5.4.  CB4A-as-a-Service

     CB4A's architecture lends itself naturally to a managed service model
     where a third-party provider operates the broker infrastructure on
     behalf of customers.  In this deployment, the customer runs only the
     SPIRE agent alongside their AI agents; the PDP, CDP, vault, and audit
     trail are hosted and operated by the service provider.

     This model is particularly relevant because CB4A's functionality
     overlaps significantly with existing Cloud Access Security Broker
     (CASB) and Secure Access Service Edge (SASE) platforms.  Both CASBs
     and SASE products already operate inline security mediation layers
     between users/applications and cloud services.  Adding agent
     credential brokering to these platforms is a natural extension of
     their existing capability:

     *  CASB platforms already mediate access between enterprise users and
        cloud services, enforce DLP policies, and provide audit trails.
        Adding CB4A's credential brokering extends this mediation to AI
        agents as a new class of "user."

     *  SASE platforms already combine network security (firewall, SWG,
        ZTNA) with WAN optimization.  CB4A's PDP/CDP model fits within the
        SASE policy enforcement architecture as an additional service
        function.

     *  Zero Trust Network Access (ZTNA) solutions already enforce per-
        request access decisions based on identity and context.  CB4A's
        Task Request Envelope is an agent-specific extension of the ZTNA
        access request model.

     Considerations for CB4A-as-a-Service:

     *  The service provider becomes the trust anchor for credential
        storage.  Customer due diligence on the provider's security
        posture is critical.

     *  Latency between customer agents and the hosted broker adds round-
        trip time to every credential minting operation.  Edge deployment
        of broker components mitigates this.

     *  Multi-tenancy introduces isolation requirements: one customer's
        policy engine and credential vault MUST be isolated from
        another's.

     *  Regulatory and compliance constraints may require that credentials
        never leave certain jurisdictions, requiring regional broker
        deployments.



  Hartman                 Expires 30 September 2026              [Page 21]


  Internet-Draft                    CB4A                        March 2026


  6.  Capability Tiers

     CB4A defines three capability tiers.  Each builds on the previous
     one.  A home deployment at Tier 1 is a complete system, not an
     incomplete enterprise deployment.

  6.1.  Tier 1: Core (Minimum Viable CB4A)

     *  SPIRE-based workload identity with agent attestation

     *  PDP with static policy evaluation

     *  CDP with Model B (short-lived token minting)

     *  Task Request Envelope schema, validation, and signing

     *  Tier 1 auto-approval based on policy matching

     *  Append-only audit trail with structured log entries

     *  Non-renewable leases on all issued tokens

     *  Fail-closed degradation for all critical components

     *  Canary credential seeding in the credential store

  6.2.  Tier 2: Human Oversight

     *  Tier 2 HITL approval workflow

     *  Tier 3 MFA approval (FIDO2/WebAuthn)

     *  DPoP sender-constrained token binding

     *  Behavioral baseline collection and anomaly scoring

     *  Dynamic risk scoring in PDP

     *  Model A proxy fallback for services without native support

     *  Approval fatigue countermeasures

     *  Confused deputy detection

     *  Emergency break-glass procedure






  Hartman                 Expires 30 September 2026              [Page 22]


  Internet-Draft                    CB4A                        March 2026


  6.3.  Tier 3: Advanced Threat Defense

     *  Hardware attestation for agent identity (TPM/TEE)

     *  Runtime behavior monitoring with mid-flight revocation

     *  Cross-agent correlation engine

     *  Per-service scope definition refinement

     *  Log integrity verification via hash chaining

     *  Adversarial testing program

     *  Multi-tenant federation via SPIFFE trust domains

  7.  Security Considerations

     The full threat model is provided in Appendix A.  Key security
     considerations include:

     *  The broker (CDP) is the highest-value target in the architecture.
        It MUST be hardened with no shell access, restricted network, and
        credential zeroing after minting (TM-1).

     *  Ephemeral tokens in agent memory are extractable.  DPoP sender-
        constrained tokens [RFC9449] MUST be used to prevent replay (TM-
        3).

     *  Approval fatigue is a human factors risk that cannot be fully
        solved with technical controls.  Challenge approvals and rate
        limiting reduce but do not eliminate the risk (TM-4).

     *  Multi-agent scope composition allows individually-scoped
        credentials to be combined for unauthorized access.  Cross- agent
        correlation is RECOMMENDED (TM-6).

     *  Fail-closed degradation is critical.  CB4A MUST NOT default to
        fail-open under any failure condition (TM-9).

     *  Approval channel spoofing is a threat.  High-risk approvals MUST
        use FIDO2/WebAuthn and signed approval responses (TM-10).

     *  Broker bypass, where agents access services directly without CB4A
        mediation, MUST be prevented through network-level enforcement,
        not agent cooperation (TM-11).





  Hartman                 Expires 30 September 2026              [Page 23]


  Internet-Draft                    CB4A                        March 2026


  8.  IANA Considerations

     This document makes no requests of IANA.

  9.  References

  9.1.  Normative References

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

     [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/rfc/rfc8693>.

     [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/rfc/rfc9449>.

  9.2.  Informative References

     [BEYONDCORP]
                Ward, R. and B. Beyer, "BeyondCorp: A New Approach to
                Enterprise Security", ;login: vol. 39, no. 6, December
                2014.

     [LITELLM-SECURITY]
                "Security Update: Suspected Supply Chain Incident", March
                2026,
                <https://docs.litellm.ai/blog/security-update-march-2026>.

     [NIST-ZTA] Rose, S., Borchert, O., Mitchell, S., and S. Connelly,
                "Zero Trust Architecture", NIST Special Publication
                800-207, August 2020,
                <https://csrc.nist.gov/publications/detail/sp/800-207/
                final>.

     [SPIFFE]   "SPIFFE: Secure Production Identity Framework For
                Everyone", <https://spiffe.io/>.




  Hartman                 Expires 30 September 2026              [Page 24]


  Internet-Draft                    CB4A                        March 2026


     [SPIRE]    "SPIRE: SPIFFE Runtime Environment",
                <https://github.com/spiffe/spire>.

     [TEAMPCP-LITELLM]
                "TeamPCP Expands Supply Chain Campaign With LiteLLM PyPI
                Compromise", March 2026, <https://www.infosecurity-
                magazine.com/news/teampcp-litellm-pypi-supply-chain/>.

     [VAULT]    "HashiCorp Vault",
                <https://developer.hashicorp.com/vault>.

  Appendix A.  Threat Model

     This appendix presents a systematic threat analysis of the CB4A
     architecture.  Each threat is identified with a unique ID (TM-N),
     mapped to the architectural component it targets, assessed for
     severity, and paired with the mitigation specified elsewhere in this
     document.

  A.1.  Methodology

     This threat model uses a component-based approach, examining each
     trust boundary and data flow for potential compromise scenarios.
     Threats are classified by target, attacker model, severity
     (Critical/High/Medium), and mitigation cross-reference.

  A.2.  TM-1: Broker Compromise

     Target: Credential Delivery Point (CDP).  Severity: CRITICAL.

     The CDP must access real credentials to mint derivative tokens.  An
     attacker who compromises the CDP process (via RCE, supply chain
     attack, or SSRF) can intercept credentials during the minting
     operation.

     Mitigation: CDP never caches credentials beyond minting; credentials
     zeroed immediately.  CDP runs in hardened runtime.  Audit trail on
     separate trust boundary.  PDP/CDP separation prevents approval of
     arbitrary requests.

     Residual Risk: During the brief minting window, the credential exists
     in CDP memory.  This is irreducible for Model B.

  A.3.  TM-2: Revocation Propagation Failure

     Target: Token lifecycle management.  Severity: HIGH.





  Hartman                 Expires 30 September 2026              [Page 25]


  Internet-Draft                    CB4A                        March 2026


     Immediate revocation across independent downstream services violates
     distributed systems fundamentals.  Services cache auth decisions and
     experience network partitions.

     Mitigation: Three configurable revocation strategies.  Ultra-short
     TTLs as primary control.  CB4A proxy for unreliable services.  Non-
     renewable leases.

     Residual Risk: A propagation window will always exist for Model B
     tokens against caching services.

  A.4.  TM-3: Token Theft and Replay

     Target: Agent runtime memory.  Severity: HIGH.

     Short-lived tokens in agent memory can be extracted and replayed from
     an external system within the TTL window.

     Mitigation: DPoP sender-constrained tokens [RFC9449] bind each token
     to an ephemeral key pair.  Stolen tokens are cryptographically
     useless without the private key.

     Residual Risk: Simultaneous extraction of token AND DPoP private key
     defeats the binding.

  A.5.  TM-4: Approval Bypass and Fatigue

     Target: Tiered approval service.  Severity: HIGH.

     Bypass: Compromised agent crafts requests to route through auto-
     approval.  Fatigue: High-volume legitimate requests condition
     approvers to rubber-stamp.

     Mitigation: Rate limiting, challenge approvals, cool-downs.  Cross-
     agent correlation detects chaining.  FIDO2 at Tier 3.

     Residual Risk: Human factors cannot be fully solved with technical
     controls.

  A.6.  TM-5: Justification Field Gaming

     Target: Task Request Envelope.  Severity: MEDIUM.

     Compromised agent crafts adversarially-optimized justification text.

     Mitigation: Justification is NOT an authorization input.  Attack
     surface removed by design.




  Hartman                 Expires 30 September 2026              [Page 26]


  Internet-Draft                    CB4A                        March 2026


     Residual Risk: None if implementations adhere to specification.

  A.7.  TM-6: Multi-Agent Scope Composition

     Target: Blast radius containment.  Severity: HIGH.

     An attacker compromising multiple agents can compose individually-
     scoped credentials for unauthorized access.

     Mitigation: Cross-agent correlation engine.  Behavioral baselines.
     Canary credentials.  Short TTLs.

     Residual Risk: Learning period for new deployments.

  A.8.  TM-7: Audit Log Compromise

     Target: Immutable audit trail.  Severity: HIGH.

     Attacker tampers with or suppresses audit log entries.

     Mitigation: Separate trust boundary.  Hash chaining.  Fail-closed on
     log pipeline failure.

     Residual Risk: Dual compromise of broker AND audit trail.

  A.9.  TM-8: Policy Engine Injection

     Target: Policy Decision Point.  Severity: MEDIUM-HIGH.

     Crafted envelope values exploit policy evaluation via injection.

     Mitigation: Typed, compiled policy language.  Input validation.  No
     string interpolation.

     Residual Risk: Low with correct implementation.

  A.10.  TM-9: Fail-Open Under Pressure

     Target: Secure degradation model.  Severity: HIGH.

     Organizational pressure creates undocumented bypass mechanisms.

     Mitigation: Explicit fail-closed for every failure mode.  Dual-key
     break-glass with mandatory post-review.

     Residual Risk: Governance and compliance issue.





  Hartman                 Expires 30 September 2026              [Page 27]


  Internet-Draft                    CB4A                        March 2026


  A.11.  TM-10: Approver Spoofing

     Target: Tiered approval service, approval routing.  Severity: HIGH.

     Attacker impersonates an authorized approver via compromised
     communication channel or intercepted approval webhook.

     Mitigation: FIDO2/WebAuthn for Tier 3.  Cryptographically signed
     approval responses.  Out-of-band verification on authenticated
     dashboard.  Approval routing to agent owners.

     Residual Risk: Physical theft of approver's security key.

  A.12.  TM-11: Broker Bypass

     Target: CB4A mediation layer.  Severity: HIGH.

     A compromised agent attempts to access target services directly,
     bypassing CB4A entirely.  If the agent can reach the target API
     without going through the broker, all CB4A controls (approval,
     scoping, audit, TTL) are circumvented.  This is the credential broker
     equivalent of the bypass problem that Cloud Access Security Brokers
     (CASBs) have addressed for over a decade.

     Attack Scenario: 1.  Compromised agent discovers that network-level
     controls do not block direct access to a target API endpoint. 2.
     Agent uses credentials obtained through a prior legitimate CB4A
     interaction (within TTL) to call the service directly, outside the
     audit trail. 3.  Alternatively: agent accesses credentials from an
     environment variable, configuration file, or process memory of
     another application on the same host.

     Mitigation: Network-level enforcement blocking agent direct access to
     brokered services (Section 4.10).  Vault access restricted to CDP
     only.  Service-level audit log monitoring for calls not originating
     from CB4A.  DNS-level controls resolving brokered endpoints to CB4A
     proxy.

     Residual Risk: Agents running on hosts with broad network access and
     weak segmentation.  Environments where network policy enforcement is
     not feasible (e.g., shared development machines without container
     isolation).









  Hartman                 Expires 30 September 2026              [Page 28]


  Internet-Draft                    CB4A                        March 2026


  A.13.  Threat Summary

      +=======+===================+==========+=========================+
      | ID    | Threat            | Severity | Primary Mitigation      |
      +=======+===================+==========+=========================+
      | TM-1  | Broker compromise | CRITICAL | Hardened runtime,       |
      |       |                   |          | credential zeroing      |
      +-------+-------------------+----------+-------------------------+
      | TM-2  | Revocation        | HIGH     | Ultra-short TTLs,       |
      |       | failure           |          | configurable strategies |
      +-------+-------------------+----------+-------------------------+
      | TM-3  | Token theft/      | HIGH     | DPoP sender-constrained |
      |       | replay            |          | tokens                  |
      +-------+-------------------+----------+-------------------------+
      | TM-4  | Approval bypass/  | HIGH     | Rate limiting,          |
      |       | fatigue           |          | challenge approvals     |
      +-------+-------------------+----------+-------------------------+
      | TM-5  | Justification     | MEDIUM   | Field excluded from     |
      |       | gaming            |          | authorization           |
      +-------+-------------------+----------+-------------------------+
      | TM-6  | Multi-agent       | HIGH     | Cross-agent correlation |
      |       | composition       |          | engine                  |
      +-------+-------------------+----------+-------------------------+
      | TM-7  | Audit log         | HIGH     | Separate trust          |
      |       | compromise        |          | boundary, hash chaining |
      +-------+-------------------+----------+-------------------------+
      | TM-8  | Policy engine     | MED-HIGH | Typed policy language   |
      |       | injection         |          |                         |
      +-------+-------------------+----------+-------------------------+
      | TM-9  | Fail-open         | HIGH     | Explicit fail-closed,   |
      |       | pressure          |          | break-glass             |
      +-------+-------------------+----------+-------------------------+
      | TM-10 | Approver spoofing | HIGH     | FIDO2/WebAuthn, signed  |
      |       |                   |          | approvals               |
      +-------+-------------------+----------+-------------------------+
      | TM-11 | Broker bypass     | HIGH     | Network enforcement,    |
      |       |                   |          | vault isolation         |
      +-------+-------------------+----------+-------------------------+

                                   Table 7

  Acknowledgments

     This specification was developed with input from multi-agent
     architectural review and adversarial analysis.

  Author's Address




  Hartman                 Expires 30 September 2026              [Page 29]


  Internet-Draft                    CB4A                        March 2026


     Kenneth G. Hartman
     SANS Institute
     Email: khartman@sans.org
















































  Hartman                 Expires 30 September 2026              [Page 30]


name: draft-sharif-attp-agent-trust-transport
rev: 00
title: ATTP: Agent Trust Transport Protocol for Secure Agent-to-Server Communication
time: 2026-03-30T09:15:28Z
group_uri: /api/v1/group/group/1027/
expires: 2026-10-01T09:15:28Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent identity/auth", "Data formats/interop"]
tags: []
fetched_at: 2026-05-22T09:24:41.698282+00:00
source: ietf
abstract:
  This document specifies ATTP (Agent Trust Transport Protocol),
     a synchronous request-response protocol for communication
     between autonomous AI agents and web API servers.  ATTP
     operates as an application-layer protocol over HTTP, adding
     mandatory cryptographic identity verification, per-message
     signing, trust-gated access control, and tamper-evident audit
     trail generation to every agent-server interaction.

     ATTP defines five protocol-layer headers for requests
     (X-Agent-Trust, X-Agent-Signature, X-Agent-Nonce,
     X-Agent-Timestamp, X-ATTP-Version) and three for responses
     (X-Server-Signature, X-Server-Nonce, X-Server-Timestamp)
     that carry an Agent Passport (JWT-based identity credential),
     ECDSA P-256 digital signatures, cryptographic nonces, and
     timestamps.  Server middleware verifies all cryptographic
     properties before application code executes.

     ATTP has no insecure mode.  Every request MUST carry a valid
     Agent Passport.  Every request body MUST be signed.  Every
     response body MUST be signed.  Every interaction MUST be
     recorded in a hash-chained audit trail.  The protocol defines
     a URL scheme (attp://) and is fully backward-compatible with
     existing HTTP infrastructure.

     ATTP is the synchronous counterpart to the Agent Transport
     Protocol (ATP).  ATP handles asynchronous store-and-forward
     agent delivery; ATTP handles real-time request-response API
     communication.  Both share the same identity model, trust
     framework, and cryptographic primitives.

full_text:
  Internet Engineering Task Force                               R. Sharif
  Internet-Draft                                            CyberSecAI Ltd
  Intended status: Standards Track                          March 29, 2026
  Expires: September 29, 2026


     ATTP: Agent Trust Transport Protocol for Secure Agent-to-Server
                               Communication
                  draft-sharif-attp-agent-trust-transport-00

  Abstract

     This document specifies ATTP (Agent Trust Transport Protocol),
     a synchronous request-response protocol for communication
     between autonomous AI agents and web API servers.  ATTP
     operates as an application-layer protocol over HTTP, adding
     mandatory cryptographic identity verification, per-message
     signing, trust-gated access control, and tamper-evident audit
     trail generation to every agent-server interaction.

     ATTP defines five protocol-layer headers for requests
     (X-Agent-Trust, X-Agent-Signature, X-Agent-Nonce,
     X-Agent-Timestamp, X-ATTP-Version) and three for responses
     (X-Server-Signature, X-Server-Nonce, X-Server-Timestamp)
     that carry an Agent Passport (JWT-based identity credential),
     ECDSA P-256 digital signatures, cryptographic nonces, and
     timestamps.  Server middleware verifies all cryptographic
     properties before application code executes.

     ATTP has no insecure mode.  Every request MUST carry a valid
     Agent Passport.  Every request body MUST be signed.  Every
     response body MUST be signed.  Every interaction MUST be
     recorded in a hash-chained audit trail.  The protocol defines
     a URL scheme (attp://) and is fully backward-compatible with
     existing HTTP infrastructure.

     ATTP is the synchronous counterpart to the Agent Transport
     Protocol (ATP).  ATP handles asynchronous store-and-forward
     agent delivery; ATTP handles real-time request-response API
     communication.  Both share the same identity model, trust
     framework, and cryptographic primitives.

  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 September 29, 2026.

  Copyright Notice

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

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  The Problem . . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Design Goals  . . . . . . . . . . . . . . . . . . . .   4
       1.3.  Relationship to ATP . . . . . . . . . . . . . . . . .   5
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
     3.  Protocol Overview . . . . . . . . . . . . . . . . . . . .   7
       3.1.  Architecture  . . . . . . . . . . . . . . . . . . . .   7
       3.2.  Mandatory Security  . . . . . . . . . . . . . . . . .   7
       3.3.  URL Scheme  . . . . . . . . . . . . . . . . . . . . .   8
     4.  ATTP Headers  . . . . . . . . . . . . . . . . . . . . . .   8
       4.1.  Request Headers . . . . . . . . . . . . . . . . . . .   8
       4.2.  Response Headers  . . . . . . . . . . . . . . . . . .  10
     5.  Request Lifecycle . . . . . . . . . . . . . . . . . . . .  10
     6.  Trust-Gated Access Control  . . . . . . . . . . . . . . .  13
       6.1.  Trust Level Definitions . . . . . . . . . . . . . . .  14
       6.2.  Per-Endpoint Trust Declaration  . . . . . . . . . . .  14
       6.3.  Rejection Semantics . . . . . . . . . . . . . . . . .  15
     7.  Per-Message Signing . . . . . . . . . . . . . . . . . . .  15
       7.1.  Request Signing . . . . . . . . . . . . . . . . . . .  16
       7.2.  Response Signing  . . . . . . . . . . . . . . . . . .  16
       7.3.  Canonical JSON  . . . . . . . . . . . . . . . . . . .  17
       7.4.  Signature Verification  . . . . . . . . . . . . . . .  17
     8.  Agent Passport  . . . . . . . . . . . . . . . . . . . . .  17
       8.1.  Passport Structure  . . . . . . . . . . . . . . . . .  18
       8.2.  Mandatory Fields  . . . . . . . . . . . . . . . . . .  18
       8.3.  Verification Procedure  . . . . . . . . . . . . . . .  19
       8.4.  Relationship to MCPS Agent Passports  . . . . . . . .  20
     9.  Key Discovery . . . . . . . . . . . . . . . . . . . . . .  20
       9.1.  JWKS Endpoint . . . . . . . . . . . . . . . . . . . .  20
       9.2.  Key Caching . . . . . . . . . . . . . . . . . . . . .  21
       9.3.  Key Rotation  . . . . . . . . . . . . . . . . . . . .  21
     10. Replay Protection . . . . . . . . . . . . . . . . . . . .  22
       10.1. Nonce Requirements  . . . . . . . . . . . . . . . . .  22
       10.2. Timestamp Window  . . . . . . . . . . . . . . . . . .  22
       10.3. Nonce Store Requirements  . . . . . . . . . . . . . .  22
     11. Audit Trail . . . . . . . . . . . . . . . . . . . . . . .  23
       11.1. Automatic Recording . . . . . . . . . . . . . . . . .  23
       11.2. Hash-Chained Records  . . . . . . . . . . . . . . . .  23
       11.3. Export Formats  . . . . . . . . . . . . . . . . . . .  24
     12. URL Scheme  . . . . . . . . . . . . . . . . . . . . . . .  24
       12.1. Scheme Definition . . . . . . . . . . . . . . . . . .  24
       12.2. Default Port  . . . . . . . . . . . . . . . . . . . .  25
       12.3. URI Format  . . . . . . . . . . . . . . . . . . . . .  25
     13. Backward Compatibility  . . . . . . . . . . . . . . . . .  25
       13.1. HTTP Infrastructure . . . . . . . . . . . . . . . . .  25
       13.2. Upgrade Path  . . . . . . . . . . . . . . . . . . . .  26
     14. Error Handling  . . . . . . . . . . . . . . . . . . . . .  26
     15. Security Considerations . . . . . . . . . . . . . . . . .  28
     16. IANA Considerations . . . . . . . . . . . . . . . . . . .  29
       16.1. ATTP URI Scheme Registration  . . . . . . . . . . . .  29
       16.2. Port Number Registration  . . . . . . . . . . . . . .  30
       16.3. ATTP Header Field Registration  . . . . . . . . . . .  30
     17. References  . . . . . . . . . . . . . . . . . . . . . . .  31
       17.1. Normative References  . . . . . . . . . . . . . . . .  31
       17.2. Informative References  . . . . . . . . . . . . . . .  32
     Appendix A.  Example ATTP Exchange  . . . . . . . . . . . . .  33
     Appendix B.  Comparison with HTTP/OAuth . . . . . . . . . . .  35
     Appendix C.  Server Middleware Implementation Guide . . . . .  37
     Author's Address  . . . . . . . . . . . . . . . . . . . . . .  38

  1.  Introduction

  1.1.  The Problem

     The Hypertext Transfer Protocol (HTTP) [RFC9110] was designed
     in 1991 for human users operating web browsers to request and
     receive hypertext documents from servers.  HTTP provides no
     built-in mechanism for caller identity verification, no
     per-message signing, no trust-level evaluation, and no audit
     trail generation.  Over three decades, security was
     progressively bolted on: TLS [RFC8446] for transport
     encryption (1995), HTTP Authentication [RFC7235] for basic
     credentials (1999), OAuth 2.0 [RFC6749] for delegated
     authorization (2012), and DPoP [RFC9449] for proof-of-
     possession (2023).

     This layered approach created a protocol stack where security
     is optional, fragmented, and human-centric.  HTTP has both
     insecure (http://) and secure (https://) variants.  OAuth
     assumes a human who can interact with browser-based consent
     flows.  TLS protects the transport channel but not the
     application-layer message -- once a request passes through a
     TLS-terminating proxy, CDN, or load balancer, the message
     is decrypted and forwarded in plaintext within the server's
     infrastructure.

     Autonomous AI agents are now the fastest-growing consumers
     of web APIs.  Industry projections indicate that agent-
     initiated API calls will exceed human-initiated API calls
     by 2028.  These agents cannot participate in browser-based
     OAuth consent flows, do not have browser sessions, and
     require machine-to-machine identity credentials rather than
     human-delegated access tokens.

     There exists a need for a synchronous request-response
     protocol purpose-built for autonomous AI agents that mandates
     cryptographic identity verification, signs every message at
     the application layer, evaluates trust at the protocol layer,
     generates audit trails automatically, and operates over
     existing HTTP infrastructure.

  1.2.  Design Goals

     ATTP is designed with the following goals:

     o  Mandatory security: no insecure mode, no optional signing,
        no anonymous access.

     o  Bidirectional signing: both request and response are signed
        at the application layer.

     o  Trust-gated access: protocol-layer trust evaluation before
        application code executes.

     o  Automatic audit: every interaction recorded in a tamper-
        evident hash-chained trail.

     o  Backward compatibility: ATTP messages are valid HTTP
        messages that traverse existing infrastructure.

     o  Minimal integration: single middleware registration line
        in existing web frameworks.

     o  Federated identity: no central authority required for
        Agent Passport issuance or key discovery.

  1.3.  Relationship to ATP

     ATTP is the synchronous counterpart to the Agent Transport
     Protocol (ATP) [draft-sharif-agent-transport-protocol].  The
     relationship can be summarized as:

     o  ATP is to ATTP as SMTP is to HTTP.

     o  ATP handles asynchronous, store-and-forward agent delivery
        (analogous to email).

     o  ATTP handles synchronous, real-time request-response API
        communication (analogous to phone calls).

     Both protocols share the same identity model (Agent
     Passports), the same trust level framework (L0 through L4),
     the same cryptographic primitives (ECDSA P-256), and the
     same design philosophy (mandatory security, no insecure
     mode).  They differ in delivery semantics: ATP uses a
     dedicated session protocol with DNS-based routing via Agent
     eXchange (AX) records, while ATTP runs over existing HTTP
     infrastructure.

     An agent operating in a complex environment might use both
     protocols: ATTP to call web APIs for real-time data retrieval
     and transaction processing, and ATP to transmit itself to a
     different runtime for continued execution.

  2.  Terminology

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

     Agent:  An autonomous software entity that makes independent
        decisions about which APIs to call and operates without
        direct human interaction for each request.

     Agent Passport:  A JWT-structured credential signed with
        ECDSA P-256 that binds an agent's identity, trust level,
        capabilities, and public key into a single verifiable
        credential.

     ATTP Agent:  The client-side component within an autonomous
        agent that constructs ATTP-compliant requests, including
        signing the request body and attaching the Agent Passport.

     ATTP Middleware:  The server-side component that intercepts
        incoming requests, performs all ATTP verification steps
        (passport verification, trust evaluation, signature
        verification, replay protection), and either forwards
        verified requests to application code or rejects them.

     ATTP Server:  A web API server configured with ATTP
        middleware that enforces ATTP protocol requirements.

     Trust Level:  A hierarchical classification (L0 through L4)
        reflecting the cryptographic verification strength of an
        agent's identity and message integrity.  Trust levels are
        asserted by the passport issuer and signed into the Agent
        Passport.

     Passport Issuer:  An entity that verifies agent identities,
        assigns trust levels, and issues signed Agent Passports.
        Any entity MAY operate as a passport issuer (federated
        model).

     Nonce:  A cryptographically random value (minimum 128 bits,
        hex-encoded) included in each request to prevent replay
        attacks.

     JWKS:  JSON Web Key Set, a document containing one or more
        public keys used for signature verification, as defined
        in [RFC7517].

     Canonical JSON:  JSON serialized according to JSON
        Canonicalization Scheme (JCS) [RFC8785], providing
        deterministic byte-level representation for signing.

     Hash Chain:  A sequence of records where each record
        contains a SHA-256 hash of the previous record, making
        the sequence tamper-evident.

  3.  Protocol Overview

  3.1.  Architecture

     ATTP operates as an application-layer protocol over HTTP.
     ATTP messages are standard HTTP messages with additional
     headers and body-level signing.  ATTP does not define a new
     transport mechanism; it leverages existing HTTP transport
     infrastructure (TCP connections, TLS encryption, HTTP/1.1
     or HTTP/2 or HTTP/3 framing) while adding mandatory security
     properties at the application layer.

     The architecture comprises three components:

     o  ATTP Agent: constructs signed requests with Agent Passport
        and transmits them over HTTPS.

     o  ATTP Middleware: server-side interceptor that verifies all
        cryptographic properties before forwarding to application
        code.

     o  Application Code: the API endpoint handler that processes
        verified requests, unaware of ATTP verification details.

     Every request carries an Agent Passport and a message
     signature.  Every response is signed by the server.  The
     middleware enforces these requirements; application code
     receives only verified requests.

  3.2.  Mandatory Security

     ATTP has no insecure mode.  The following properties are
     non-optional protocol requirements:

     o  Every request MUST carry a valid Agent Passport.

     o  Every request body MUST be signed by the agent.

     o  Every response body MUST be signed by the server.

     o  Every interaction MUST be recorded in the audit trail.

     o  Trust level MUST be evaluated before application code
        executes.

     There is no anonymous mode, no unsigned mode, and no bypass
     mechanism.  Unlike HTTP, which has both http:// (insecure)
     and https:// (secure), ATTP has only attp:// which inherently
     implies mandatory cryptographic signing, identity
     verification, and trust evaluation.

  3.3.  URL Scheme

     ATTP defines the URL scheme attp:// to distinguish agent-
     to-server requests from conventional HTTP requests.  An ATTP
     URL takes the form:

        attp://hostname[:port]/path[?query]

     Example:

        attp://api.example.com/v1/charges

     The attp:// scheme signals that: (a) the request originates
     from an autonomous agent; (b) ATTP security requirements are
     mandatory; and (c) the server MUST process the request
     through ATTP middleware.

     At the transport level, ATTP requests are transmitted over
     HTTPS.  The attp:// scheme is resolved to an HTTPS connection
     by the ATTP agent component.  The default port is 8443.

  4.  ATTP Headers

  4.1.  Request Headers

     ATTP defines five mandatory request headers:

     X-Agent-Trust:  Contains the agent's Agent Passport, a
        JWT-structured credential signed with ECDSA P-256.  The
        passport carries identity claims including subject,
        issuer, trust level, capabilities, public key, and
        expiration.

        Format: Base64url-encoded JWT (header.payload.signature)

        Example:
           X-Agent-Trust: eyJhbGciOiJFUzI1NiIsInR5cCI6IkpX
           VCIsImtpZCI6InRhLWtleS0wMDEifQ.eyJzdWIiOiJhZ2
           VudC1hbHBoYS0wMDEiLCJpc3MiOiJ0cnVzdC5leGFtcG
           xlLmNvbSIsInRydXN0X2xldmVsIjoiTDIiLCJleHAiOjE
           3NDMzMDAwMDB9.MEUCIQDx...

     X-Agent-Signature:  Contains the Base64url-encoded ECDSA
        P-256 signature over the request body.  For JSON bodies,
        the signature is computed over the JCS-canonicalized
        [RFC8785] form.  For non-JSON bodies, the signature is
        computed over the raw bytes.  For bodiless requests (GET,
        HEAD), the signature covers a canonical string comprising
        method, path, nonce, and timestamp.

        Encoding: IEEE P1363 fixed-length r||s format per
        [RFC7518] Section 3.4, with low-S normalization.

        Format: Base64url string

     X-Agent-Nonce:  Contains a cryptographically random nonce,
        hex-encoded, with a minimum of 128 bits of entropy
        (32 hex characters).  The nonce MUST be unique per
        request.

        Format: Hex-encoded string, minimum 32 characters

        Example:
           X-Agent-Nonce: a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6

     X-Agent-Timestamp:  Contains an ISO 8601 timestamp [RFC3339]
        recording the moment the agent signed the request.

        Format: ISO 8601 / RFC 3339 timestamp

        Example:
           X-Agent-Timestamp: 2026-03-29T14:30:00.000Z

     X-ATTP-Version:  Contains the ATTP protocol version string.

        Format: Major.Minor version string

        Example:
           X-ATTP-Version: 1.0

  4.2.  Response Headers

     ATTP defines three mandatory response headers:

     X-Server-Signature:  Contains the Base64url-encoded ECDSA
        P-256 signature over the response body, computed by the
        server using its private key.  The agent verifies this
        signature using the server's public key obtained from
        the JWKS endpoint.

     X-Server-Nonce:  Contains a cryptographically random nonce
        generated by the server, hex-encoded, minimum 128 bits.

     X-Server-Timestamp:  Contains an ISO 8601 timestamp
        recording the moment the server signed the response.

  5.  Request Lifecycle

     The ATTP request lifecycle comprises eleven steps.  Each
     step is mandatory and MUST NOT be skipped or deferred.

     Step 1: Request Construction

        The ATTP agent constructs the request payload (HTTP
        request body) containing the data to be sent.  The
        payload MAY be JSON, form data, binary, or any content
        type supported by HTTP.

     Step 2: Request Body Signing

        The ATTP agent computes a digital signature over the
        request body using its ECDSA P-256 private key.  For
        JSON payloads, the canonical form is computed using JCS
        [RFC8785]: keys sorted lexicographically, no extraneous
        whitespace, UTF-8 encoding.  For non-JSON payloads, the
        raw byte sequence is signed.  The signature uses IEEE
        P1363 fixed-length r||s encoding with low-S
        normalization.  The resulting signature is Base64url-
        encoded.

        For bodiless requests (GET, HEAD, DELETE without body),
        the agent signs a canonical string:

           METHOD + "\n" + PATH + "\n" + NONCE + "\n" + TIMESTAMP

     Step 3: Agent Passport Attachment

        The ATTP agent attaches its Agent Passport in the
        X-Agent-Trust header.  The passport is a JWT containing
        the agent's identity claims, signed by the passport
        issuer.

     Step 4: Nonce and Timestamp Generation

        The ATTP agent generates a cryptographically random nonce
        (minimum 128 bits, hex-encoded) and an ISO 8601 timestamp.
        The nonce is placed in X-Agent-Nonce; the timestamp in
        X-Agent-Timestamp.  Both values are included in the signed
        content (Step 2) to bind the signature to a specific
        moment and prevent replay.

     Step 5: Request Transmission

        The ATTP agent transmits the HTTP request to the server's
        URL with all ATTP headers (X-Agent-Trust,
        X-Agent-Signature, X-Agent-Nonce, X-Agent-Timestamp,
        X-ATTP-Version) alongside standard HTTP headers.  The
        request is transmitted over HTTPS.

     Step 6: Server Middleware Interception

        The ATTP middleware intercepts the incoming request before
        it reaches the application's route handler.  The
        middleware checks for X-ATTP-Version to determine if the
        request is an ATTP request.  If absent, behavior is
        configurable:

        o  Strict mode: reject (ATTP-only server).

        o  Permissive mode: pass through as regular HTTP.

        o  Upgrade mode: respond with protocol upgrade suggestion.

     Step 7: Agent Passport Verification

        The middleware extracts the Agent Passport from
        X-Agent-Trust, decodes the JWT, and verifies its ECDSA
        P-256 signature against the issuer's public key.  The
        middleware verifies:

        o  The passport has not expired.

        o  The passport's issuer is in the server's trusted list.

        o  The passport's claims are internally consistent.

        The issuer's public key is resolved via the issuer's JWKS
        endpoint or a locally cached copy.

     Step 8: Trust Level Evaluation

        The middleware extracts the agent's trust level from the
        verified passport and compares it against the minimum
        trust level required by the target endpoint.  If the
        agent's trust level is below the minimum, the middleware
        rejects the request with HTTP 403 and a structured error
        response (see Section 6.3).

     Step 9: Request Signature Verification

        The middleware extracts the signature from
        X-Agent-Signature and verifies it against the request
        body using the agent's public key from the passport.
        The middleware also verifies:

        o  The nonce has not been previously used.

        o  The timestamp is within the acceptable window.

        If verification fails, the request is rejected.

     Step 10: Response Signing

        After application code generates a response, the
        middleware intercepts the outgoing response.  The
        middleware computes an ECDSA P-256 signature over the
        response body using the server's private key, generates
        a server nonce and timestamp, and attaches:
        X-Server-Signature, X-Server-Nonce, X-Server-Timestamp.

     Step 11: Audit Trail Recording

        The middleware records the complete request-response pair
        in the tamper-evident audit trail.  The audit record
        includes the agent's identity, trust level, request and
        response hashes, signatures, and a hash pointer to the
        previous record.

  6.  Trust-Gated Access Control

     ATTP enforces trust-level-based access control at the
     protocol layer, before application code executes.  This is
     fundamentally different from application-layer authorization
     (such as OAuth scope checking): ATTP trust evaluation occurs
     in protocol middleware and rejects untrusted requests before
     they consume application resources.

     Trust levels reflect the cryptographic verification strength
     of the agent's identity, not the permissions granted.  Trust
     answers "how confident is the server in the agent's identity
     and message integrity?" while permissions answer "what is
     the agent allowed to do?"  ATTP addresses the former; the
     application layer addresses the latter.

  6.1.  Trust Level Definitions

     ATTP defines five hierarchically ordered trust levels,
     derived from the MCPS trust level framework
     [draft-sharif-mcps-secure-mcp]:

     L0 (No Verification):  The agent has presented a passport
        but the issuer cannot be verified, or the agent has no
        established history.  L0 is the floor; ATTP does not
        permit passportless requests.

     L1 (Identity Verified):  The agent's passport is signed by
        a trusted issuer that has verified the agent's identity.

     L2 (Signed Messages):  The agent's passport is verified and
        the request is signed with a valid ECDSA P-256 signature.
        L2 is the baseline for most API operations.

     L3 (Full Verification with Revocation Checking):  Passport
        verified, request signed, and revocation checking
        performed against the issuer's revocation endpoint.
        Appropriate for sensitive operations such as financial
        transactions.

     L4 (Mutual Authentication with Hardware-Backed Keys):
        All L3 requirements plus attestation that the agent's
        private key resides in a hardware security module (HSM)
        or secure enclave.  Appropriate for critical
        infrastructure operations.

  6.2.  Per-Endpoint Trust Declaration

     Each API endpoint declares its minimum trust level as part
     of its configuration, not its application code.  The ATTP
     middleware reads the declared minimum and compares it
     against the agent's trust level (where L0=0, L1=1, L2=2,
     L3=3, L4=4).

     Examples:

     o  Public product catalogue: L1 minimum

     o  Standard API operations: L2 minimum

     o  Payment processing: L3 minimum

     o  Critical infrastructure: L4 minimum

  6.3.  Rejection Semantics

     When the agent's trust level is below the endpoint's
     minimum, the middleware MUST respond with HTTP 403 Forbidden
     and the following JSON body:

        {
          "error": "insufficient_trust_level",
          "required_level": "L3",
          "agent_level": "L1",
          "message": "Agent trust level insufficient"
        }

     This rejection occurs at the protocol layer.  Application
     code is never invoked for insufficient-trust requests.

  7.  Per-Message Signing

     ATTP mandates per-message signing for both requests and
     responses, providing bidirectional application-layer message
     integrity.  This is a distinguishing property: HTTP does not
     sign messages, TLS signs only the transport channel, and
     most API authentication schemes sign only the request.  ATTP
     signs both directions.

  7.1.  Request Signing

     The agent computes an ECDSA P-256 signature over the
     canonicalized request body, the nonce, and the timestamp.
     The signature binds the message content to the agent's
     identity (via its private key) and to a specific point in
     time (via nonce and timestamp).

     If any byte of the request body is modified after signing
     -- by a proxy, CDN, API gateway, or any other intermediary
     -- the signature verification at the server will fail.

     The signing input for JSON request bodies:

        JCS(request_body) + "\n" + nonce + "\n" + timestamp

     The signing input for non-JSON request bodies:

        raw_bytes(request_body) + "\n" + nonce + "\n" + timestamp

     All signatures use ECDSA P-256 with IEEE P1363 r||s encoding
     and low-S normalization per [RFC7518] Section 3.4.

  7.2.  Response Signing

     The server computes an ECDSA P-256 signature over the
     response body using the server's private key.  The agent
     verifies this signature using the server's public key
     obtained from the JWKS endpoint (Section 9).

     Bidirectional signing provides end-to-end integrity from
     agent to server and from server to agent, regardless of
     intermediaries in the network path.

  7.3.  Canonical JSON

     For JSON payloads, ATTP uses JSON Canonicalization Scheme
     (JCS) as specified in [RFC8785] to produce deterministic
     byte-level representations for signing:

     o  Object keys sorted lexicographically by Unicode code
        point.

     o  No extraneous whitespace.

     o  UTF-8 encoding.

     o  Number serialization per ECMAScript rules.

     JCS ensures that semantically identical JSON documents
     produce identical byte sequences, preventing signature
     verification failures caused by formatting differences.

  7.4.  Signature Verification

     Verification MUST fail-closed: any verification error MUST
     result in request rejection.  The middleware MUST NOT fall
     back to unsigned processing.

     ECDSA P-256 was selected for its combination of 128-bit
     equivalent security strength, performance, compact key size
     (suitable for HTTP headers), and ubiquity (supported by all
     major cryptographic libraries, HSMs, and cloud KMS
     services).

  8.  Agent Passport

     The Agent Passport is the cornerstone of ATTP identity
     verification.  Every ATTP request MUST carry a valid Agent
     Passport.  There is no anonymous mode and no bypass.

  8.1.  Passport Structure

     The passport is a JWT [RFC7519] comprising three sections:

     Header:  Specifies the signing algorithm (ES256 for ECDSA
        P-256) and the key identifier (kid) of the issuer's
        signing key.

     Payload:  Contains identity claims (see Section 8.2).

     Signature:  Computed by the issuer over the header and
        payload using the issuer's ECDSA P-256 private key.

  8.2.  Mandatory Fields

     The Agent Passport payload MUST contain:

     sub (Subject):  The agent's unique identifier.
        Example: "agent-alpha-001"

     iss (Issuer):  The identity provider that issued the
        passport.
        Example: "trust.example.com"

     iat (Issued At):  Unix timestamp of passport issuance.

     exp (Expiration):  Unix timestamp of passport expiration.

     trust_level:  One of "L0", "L1", "L2", "L3", "L4".

     capabilities:  Array of capability strings the agent
        possesses.
        Example: ["read", "write", "payment"]

     The passport payload SHOULD contain:

     owner:  The individual or organization that owns the agent.

     agent_type:  Classification: "autonomous",
        "semi-autonomous", or "supervised".

     pub_key:  The agent's ECDSA P-256 public key in JWK format
        [RFC7517] or a URI reference to the key.

     origin:  The domain from which the agent operates, for
        origin binding.

  8.3.  Verification Procedure

     The ATTP middleware MUST verify the Agent Passport through
     the following steps:

     1.  Decode the JWT and extract header, payload, and
         signature.

     2.  Extract the issuer (iss) claim and resolve the issuer's
         public key via the issuer's JWKS endpoint or a locally
         cached copy.

     3.  Verify the JWT signature against the header and payload
         using the issuer's public key.

     4.  Verify that the current time is between iat and exp.

     5.  Verify that the issuer is in the server's list of
         trusted issuers.

     6.  Optionally perform origin binding verification: confirm
         that the agent's declared origin matches the network
         origin of the request.

     7.  For L3 and L4 trust levels, perform revocation checking
         by querying the issuer's revocation endpoint.

     If any step fails, the middleware MUST reject the request
     with HTTP 401 and an appropriate error code.

  8.4.  Relationship to MCPS Agent Passports

     ATTP uses the Agent Passport format defined in MCPS
     [draft-sharif-mcps-secure-mcp] Section 4, extended with
     HTTP-specific claims for transport context.  MCPS defines
     how to issue, sign, and verify passports; ATTP defines
     when and where these operations occur within the HTTP
     request-response lifecycle.

  9.  Key Discovery

  9.1.  JWKS Endpoint

     ATTP servers MUST publish their public keys at:

        /.well-known/agent-trust-keys

     This endpoint serves a JSON Web Key Set (JWKS) document
     [RFC7517] containing one or more ECDSA P-256 public keys
     used for response signing.

     The JWKS document contains JWK objects with:

     o  kty: "EC" (Elliptic Curve)

     o  crv: "P-256"

     o  x, y: public key coordinates, Base64url-encoded

     o  kid: key identifier for key selection

     o  use: "sig" (signing)

     o  alg: "ES256" (ECDSA P-256)

     Example JWKS document:

        {
          "keys": [{
            "kty": "EC",
            "crv": "P-256",
            "kid": "server-key-001",
            "use": "sig",
            "alg": "ES256",
            "x": "f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
            "y": "x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0"
          }]
        }

     The well-known path follows [RFC8615] conventions.  The
     path "agent-trust-keys" avoids collision with other
     well-known endpoints such as /.well-known/jwks.json.

  9.2.  Key Caching

     Agents SHOULD cache the JWKS document to avoid fetching
     it on every request.  The HTTP Cache-Control header on the
     JWKS response indicates the cache duration.  A typical
     cache duration is one hour.

     Agents MUST refresh the cached JWKS document if they
     encounter a response signed with a key identifier (kid)
     not present in their cached document.

  9.3.  Key Rotation

     Key rotation is supported through the JWKS endpoint.  When
     a server rotates its signing key:

     1.  Publish both old and new keys in the JWKS document.

     2.  Begin signing responses with the new key.

     3.  After a transition period, remove the old key.

     This allows agents with cached old keys to continue
     verifying responses during the transition.

  10.  Replay Protection

  10.1.  Nonce Requirements

     Each ATTP request MUST carry a unique nonce in the
     X-Agent-Nonce header.  The nonce MUST be cryptographically
     random with a minimum of 128 bits of entropy, hex-encoded
     to a 32-character string.  The nonce is included in the
     signed content, binding it cryptographically to the request.

     An attacker who captures a valid ATTP request cannot modify
     the nonce without invalidating the signature.

  10.2.  Timestamp Window

     The X-Agent-Timestamp header MUST contain an ISO 8601
     timestamp [RFC3339].  The server MUST reject requests whose
     timestamp is outside the acceptable window.

     The default window is plus or minus 300 seconds (5 minutes)
     from the server's current time.  Servers MAY configure a
     different window but MUST NOT exceed plus or minus 600
     seconds.

     The timestamp window bounds replay vulnerability: even if
     an attacker captures a request, they have at most the
     window duration to attempt replay, and the nonce cache
     prevents even that.

  10.3.  Nonce Store Requirements

     The server MUST maintain a nonce store that records all
     nonces received within the timestamp validity window.

     o  On receipt: check if nonce exists in store.  If yes,
        reject as replay (HTTP 409).  If no, add to store.

     o  Nonce entries MUST be expired after the timestamp window
        closes, bounding memory requirements.

     o  For multi-instance deployments, the nonce store MUST be
        shared across instances (e.g., Redis).

     The combination of nonce uniqueness and timestamp window
     provides robust replay protection with bounded resource
     consumption.

  11.  Audit Trail

  11.1.  Automatic Recording

     The ATTP middleware MUST record every request-response pair
     in a tamper-evident audit trail.  This recording is
     automatic; application code MUST NOT need to implement
     logging for ATTP interactions.

     Each audit record contains:

     o  Record identifier (UUID v4) [RFC9562]

     o  Agent identifier (from verified passport)

     o  Agent trust level

     o  Agent owner (from passport)

     o  Request timestamp

     o  HTTP method and request path

     o  SHA-256 hash of request body

     o  Request signature (from X-Agent-Signature)

     o  Response status code

     o  SHA-256 hash of response body

     o  Response signature (from X-Server-Signature)

     o  Processing duration (milliseconds)

     o  Hash pointer to previous audit record

     The body itself is not stored (to avoid retaining sensitive
     payloads); the SHA-256 hash enables later verification.

  11.2.  Hash-Chained Records

     Each audit record contains a SHA-256 hash of the previous
     record's serialized content, creating a hash chain per
     [draft-sharif-agent-audit-trail].  The first record has a
     null hash pointer.

     This hash chain is tamper-evident: if any record is
     modified, deleted, or inserted, the chain breaks and
     tampering is detectable by any party that verifies it.

  11.3.  Export Formats

     ATTP audit trails MUST support export in the following
     formats:

     JSONL:  One JSON object per line, suitable for log
        aggregation systems and streaming processors.

     Syslog:  RFC 5424 structured data format, suitable for
        enterprise SIEM integration.

  12.  URL Scheme

  12.1.  Scheme Definition

     ATTP defines the URI scheme "attp" for identifying
     resources accessible via the Agent Trust Transport Protocol.

     The scheme is registered per [RFC7595].

     Scheme syntax:

        attp-URI = "attp://" authority path-abempty
                   [ "?" query ] [ "#" fragment ]

     The "attp" scheme implies:

     o  Mandatory Agent Passport verification

     o  Mandatory per-message signing (both directions)

     o  Mandatory trust-level evaluation

     o  Mandatory audit trail recording

     o  Transport over HTTPS (TLS required)

     There is no insecure counterpart.  Unlike HTTP (http://
     vs https://), the attp:// scheme inherently implies full
     security.

  12.2.  Default Port

     The default port for ATTP is 8443.  This port is selected
     to avoid conflict with the standard HTTPS port (443) while
     remaining within the common range for secure services.

     When the port is omitted from the URI, the ATTP agent
     component MUST connect to port 8443.

  12.3.  URI Format

        attp://host[:port]/path[?query]

     Examples:

        attp://api.example.com/v1/charges
        attp://api.example.com:9443/v1/users?limit=10
        attp://trust.internal.corp/agents/register

  13.  Backward Compatibility

  13.1.  HTTP Infrastructure

     ATTP messages are standard HTTP messages.  All ATTP-
     specific information is carried in HTTP headers and in the
     cryptographic relationship between headers and body.  No
     modifications to HTTP framing, body encoding, or transport
     semantics are required.

     Existing infrastructure forwards ATTP transparently:

     o  Load balancers (HAProxy, NGINX, AWS ALB) forward all
        headers including X-Agent-* headers.

     o  CDNs (Cloudflare, Fastly, Akamai) cache and forward
        ATTP responses, preserving X-Server-* headers.

     o  Reverse proxies and API gateways forward ATTP traffic.

     o  WAFs inspect ATTP as standard HTTP traffic with
        additional headers available for custom rules.

     o  Monitoring tools capture ATTP as standard HTTP with
        ATTP headers available for agent-specific analysis.

     ATTP's per-message signing provides security that survives
     transit through TLS-terminating intermediaries.  When a
     request passes through a TLS-terminating load balancer,
     the ATTP signature remains verifiable at the backend
     server, confirming the body was not modified in transit.

  13.2.  Upgrade Path

     Servers transitioning from HTTPS to ATTP can operate in
     three modes:

     Strict:  Reject all non-ATTP requests (HTTP 426 Upgrade
        Required).

     Permissive:  Accept both ATTP and standard HTTP requests,
        applying ATTP verification only when ATTP headers are
        present.

     Upgrade:  Accept standard HTTP requests but include an
        Upgrade header in responses suggesting ATTP.

     Non-ATTP servers that receive requests with X-Agent-*
     headers will ignore the unknown headers and process the
     request as standard HTTP.  This enables gradual adoption.

  14.  Error Handling

     ATTP defines specific error responses for protocol-level
     failures, using standard HTTP status codes with structured
     JSON error bodies.  All error responses are machine-
     readable for autonomous agent consumption.

     400 Bad Request - missing_attp_headers:

        {
          "error": "missing_attp_headers",
          "missing_headers": ["X-Agent-Trust",
                              "X-Agent-Signature"]
        }

        Remedial action: agent adds missing headers.

     401 Unauthorized - invalid_passport:

        {
          "error": "invalid_passport",
          "reason": "expired"
        }

        Reasons: "signature_invalid", "expired",
        "issuer_untrusted", "malformed".
        Remedial action: obtain new passport from issuer.

     401 Unauthorized - invalid_signature:

        {
          "error": "invalid_signature",
          "reason": "signature_mismatch"
        }

        Reasons: "signature_mismatch", "key_mismatch",
        "canonicalization_error".

     403 Forbidden - insufficient_trust_level:

        {
          "error": "insufficient_trust_level",
          "required_level": "L3",
          "agent_level": "L1"
        }

        Remedial action: request higher trust level or find
        alternative endpoint.

     408 Request Timeout - timestamp_expired:

        {
          "error": "timestamp_expired"
        }

        Indicates clock skew or delayed request.

     409 Conflict - nonce_reuse:

        {
          "error": "nonce_reuse"
        }

        Indicates potential replay attack.  No additional
        detail to avoid information leakage.

     426 Upgrade Required - attp_required:

        {
          "error": "attp_required",
          "upgrade": "ATTP/1.0",
          "documentation": "https://example.com/attp"
        }

        Server operates in strict mode; ATTP headers required.

  15.  Security Considerations

     Mandatory security model:  ATTP eliminates the "forgot to
        enable TLS" class of vulnerabilities.  There is no
        insecure mode, no optional signing, and no configuration
        that disables security.  Every protocol interaction
        requires identity, signing, and audit.

     Trust evaluation at protocol layer:  Trust-gated access
        prevents application-layer bypasses.  An application
        vulnerability cannot bypass trust evaluation because
        trust is enforced in protocol middleware before
        application code executes.

     Bidirectional signing:  Response signing prevents response
        tampering by intermediaries.  Unlike TLS, which protects
        only the transport channel, ATTP signatures survive
        transit through TLS-terminating proxies, CDNs, and load
        balancers.

     Replay protection:  The combination of unique nonce and
        bounded timestamp window prevents replay attacks with
        bounded resource consumption for the nonce store.

     Privacy:  Agent identity is visible to the server by design.
        This is intentional for audit and accountability
        purposes.  Servers MUST protect agent identity data per
        applicable privacy regulations.  Agents operating in
        privacy-sensitive contexts SHOULD use pseudonymous
        identifiers in their passports.

     Clock skew:  The timestamp window (default 300 seconds)
        accommodates reasonable clock drift.  Agents and servers
        SHOULD synchronize clocks via NTP [RFC5905].

     Key compromise:  If an agent's private key is compromised,
        the passport issuer SHOULD revoke the agent's passport.
        Servers performing L3+ verification will detect the
        revocation.  Key rotation procedures are specified in
        Section 9.3.

     Algorithm agility:  The X-ATTP-Version header enables
        future protocol versions to introduce post-quantum
        signature algorithms without breaking backward
        compatibility with existing deployments.

     Nonce store exhaustion:  Attackers may attempt to exhaust
        the nonce store by sending large volumes of unique
        nonces.  The timestamp window bounds the store's memory
        requirements.  Servers SHOULD implement rate limiting
        on ATTP requests.

  16.  IANA Considerations

  16.1.  ATTP URI Scheme Registration

     This document requests registration of the "attp" URI
     scheme per [RFC7595]:

     Scheme name:  attp

     Status:  Permanent

     Applications/protocols that use this scheme:  Agent Trust
        Transport Protocol (ATTP)

     Contact:  R. Sharif (contact@agentsign.dev)

     Change Controller:  IESG

     References:  This document

  16.2.  Port Number Registration

     This document requests registration of a TCP port number
     for ATTP:

     Service Name:  attp

     Transport Protocol:  TCP

     Assignee:  R. Sharif (contact@agentsign.dev)

     Contact:  R. Sharif (contact@agentsign.dev)

     Description:  Agent Trust Transport Protocol

     Reference:  This document

     Port Number:  8443

  16.3.  ATTP Header Field Registration

     This document requests registration of the following HTTP
     header fields in the "Hypertext Transfer Protocol (HTTP)
     Field Name Registry" maintained by IANA:

     +---------------------+----------+-----------+
     | Header Field Name   | Status   | Reference |
     +---------------------+----------+-----------+
     | X-Agent-Trust       | standard | this doc  |
     | X-Agent-Signature   | standard | this doc  |
     | X-Agent-Nonce       | standard | this doc  |
     | X-Agent-Timestamp   | standard | this doc  |
     | X-ATTP-Version      | standard | this doc  |
     | X-Server-Signature  | standard | this doc  |
     | X-Server-Nonce      | standard | this doc  |
     | X-Server-Timestamp  | standard | this doc  |
     +---------------------+----------+-----------+

  17.  References

  17.1.  Normative References

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

     [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the
                Internet: Timestamps", RFC 3339,
                DOI 10.17487/RFC3339, July 2002,
                <https://www.rfc-editor.org/info/rfc3339>.

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

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

     [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>.

     [RFC7595]  Thaler, D., Hansen, T., and T. Hardie,
                "Guidelines and Registration Procedures for URI
                Schemes", BCP 35, RFC 7595,
                DOI 10.17487/RFC7595, June 2015,
                <https://www.rfc-editor.org/info/rfc7595>.

     [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>.

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

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

     [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>.

     [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and
                J. Reschke, Ed., "HTTP Semantics", STD 97,
                RFC 9110, DOI 10.17487/RFC9110, June 2022,
                <https://www.rfc-editor.org/info/rfc9110>.

     [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>.

  17.2.  Informative References

     [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and
                W. Kasch, "Network Time Protocol Version 4:
                Protocol and Algorithms Specification",
                RFC 5905, DOI 10.17487/RFC5905, June 2010,
                <https://www.rfc-editor.org/info/rfc5905>.

     [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>.

     [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed.,
                "Hypertext Transfer Protocol (HTTP/1.1):
                Authentication", RFC 7235,
                DOI 10.17487/RFC7235, June 2014,
                <https://www.rfc-editor.org/info/rfc7235>.

     [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>.

     [draft-sharif-mcps-secure-mcp]
                Sharif, R., "MCPS: Cryptographic Security Layer
                for the Model Context Protocol",
                Internet-Draft
                draft-sharif-mcps-secure-mcp-02,
                March 2026,
                <https://datatracker.ietf.org/doc/
                draft-sharif-mcps-secure-mcp/>.

     [draft-sharif-agent-payment-trust]
                Sharif, R., "Agent Payment Trust: Cryptographic
                Payment Authorization for Autonomous AI Agents",
                Internet-Draft
                draft-sharif-agent-payment-trust-00,
                March 2026,
                <https://datatracker.ietf.org/doc/
                draft-sharif-agent-payment-trust/>.

     [draft-sharif-agent-audit-trail]
                Sharif, R., "Agent Audit Trail: Hash-Chained
                Interaction Records for AI Agent Systems",
                Internet-Draft
                draft-sharif-agent-audit-trail-00,
                March 2026,
                <https://datatracker.ietf.org/doc/
                draft-sharif-agent-audit-trail/>.

     [draft-sharif-agent-transport-protocol]
                Sharif, R., "ATP: Agent Transport Protocol for
                Asynchronous Agent Delivery",
                Internet-Draft
                draft-sharif-agent-transport-protocol-00,
                March 2026,
                <https://datatracker.ietf.org/doc/
                draft-sharif-agent-transport-protocol/>.

  Appendix A.  Example ATTP Exchange

     The following is a complete ATTP request-response exchange
     for a payment processing endpoint.

     A.1.  Request

        POST /v1/charges HTTP/1.1
        Host: api.example.com
        Content-Type: application/json
        X-ATTP-Version: 1.0
        X-Agent-Trust: eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCIs
          ImtpZCI6InRhLWtleS0wMDEifQ.eyJzdWIiOiJwYXltZW50
          LWJvdC0wMDEiLCJpc3MiOiJ0cnVzdC5leGFtcGxlLmNvbSI
          sImlhdCI6MTcxMTcwMDAwMCwiZXhwIjoxNzExNzg2NDAwLCJ
          0cnVzdF9sZXZlbCI6IkwzIiwiY2FwYWJpbGl0aWVzIjpbIn
          JlYWQiLCJ3cml0ZSIsInBheW1lbnQiXSwib3duZXIiOiJBY2
          1lIENvcnAiLCJhZ2VudF90eXBlIjoiYXV0b25vbW91cyJ9.
          MEUCIQDxR2s...signature...
        X-Agent-Signature: MEUCIQCvK7n...signature-over-body
        X-Agent-Nonce: a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6
        X-Agent-Timestamp: 2026-03-29T14:30:00.000Z

        {"amount":5000,"currency":"usd","description":"Widget"}

     A.2.  Decoded Agent Passport Payload

        {
          "sub": "payment-bot-001",
          "iss": "trust.example.com",
          "iat": 1711700000,
          "exp": 1711786400,
          "trust_level": "L3",
          "capabilities": ["read", "write", "payment"],
          "owner": "Acme Corp",
          "agent_type": "autonomous",
          "pub_key": {
            "kty": "EC",
            "crv": "P-256",
            "x": "f83OJ3D2xF1Bg8vub9tLe...",
            "y": "x_FEzRu9m36HLN_tue659L..."
          },
          "origin": "agents.acme.com"
        }

     A.3.  Response

        HTTP/1.1 200 OK
        Content-Type: application/json
        X-Server-Signature: MEQCIFhN...server-signature...
        X-Server-Nonce: f1e2d3c4b5a6f7e8d9c0b1a2f3e4d5c6
        X-Server-Timestamp: 2026-03-29T14:30:00.150Z

        {"id":"ch_abc123","amount":5000,"currency":"usd",
         "status":"succeeded"}

     A.4.  Middleware Verification Sequence

        1. Extract X-ATTP-Version: "1.0" - PASS
        2. Decode X-Agent-Trust JWT
        3. Fetch issuer JWKS: trust.example.com
           /.well-known/agent-trust-keys
        4. Verify passport signature - PASS
        5. Check passport expiration - PASS (not expired)
        6. Check issuer trust - PASS (trusted)
        7. Extract trust_level: L3
        8. Endpoint /v1/charges requires: L3
        9. Trust check: L3 >= L3 - PASS
        10. Verify X-Agent-Signature against body - PASS
        11. Check X-Agent-Nonce not in store - PASS (unique)
        12. Check X-Agent-Timestamp within window - PASS
        13. Forward to application handler
        14. Sign response body with server key
        15. Record audit trail entry (hash-chained)

  Appendix B.  Comparison with HTTP/OAuth

     The following table maps HTTP and OAuth features to their
     ATTP equivalents.

     +---------------------------+---------------------------+
     | HTTP/OAuth                | ATTP Equivalent           |
     +---------------------------+---------------------------+
     | URL Scheme                |                           |
     |  http:// (insecure)       | (no equivalent, no        |
     |  https:// (secure)        |  insecure mode)           |
     |                           | attp:// (mandatory        |
     |                           |  security)                |
     +---------------------------+---------------------------+
     | Identity                  |                           |
     |  OAuth Bearer token       | Agent Passport (JWT with  |
     |  (delegated human auth)   |  trust level, signed by   |
     |                           |  issuer, mandatory)       |
     +---------------------------+---------------------------+
     | Request Integrity         |                           |
     |  None (HTTP)              | X-Agent-Signature (ECDSA  |
     |  TLS (transport only)     |  P-256 over body, survives|
     |                           |  TLS termination)         |
     +---------------------------+---------------------------+
     | Response Integrity        |                           |
     |  None (HTTP)              | X-Server-Signature (ECDSA |
     |  TLS (transport only)     |  P-256 over response)     |
     +---------------------------+---------------------------+
     | Access Control            |                           |
     |  OAuth scopes             | Trust levels (L0-L4) at   |
     |  (application layer)      |  protocol layer before    |
     |                           |  app code executes        |
     +---------------------------+---------------------------+
     | Replay Protection         |                           |
     |  None (HTTP)              | X-Agent-Nonce + timestamp |
     |  CSRF tokens (web only)   |  (cryptographically bound |
     |                           |  to signature)            |
     +---------------------------+---------------------------+
     | Audit                     |                           |
     |  Application-layer logs   | Automatic hash-chained    |
     |  (developer-implemented)  |  audit trail (protocol    |
     |                           |  layer, no dev effort)    |
     +---------------------------+---------------------------+
     | Key Discovery             |                           |
     |  OAuth .well-known/openid | /.well-known/agent-trust  |
     |  -configuration           |  -keys (JWKS, RFC 7517)   |
     +---------------------------+---------------------------+
     | Signing Algorithm         |                           |
     |  Varies (RS256, ES256,    | ECDSA P-256 only (ES256,  |
     |  HS256, etc.)             |  IEEE P1363, low-S norm)  |
     +---------------------------+---------------------------+
     | Security Model            |                           |
     |  Optional (http vs https) | Mandatory (no insecure    |
     |  Configurable (OAuth)     |  mode, no bypass)         |
     +---------------------------+---------------------------+

  Appendix C.  Server Middleware Implementation Guide

     This appendix provides guidance for implementing ATTP
     middleware in common web frameworks.

     C.1.  Express.js (Node.js)

        const attp = require('attp-middleware');

        // Global: all endpoints require L2 minimum
        app.use(attp({
          privateKey: process.env.ATTP_PRIVATE_KEY,
          keyId: 'server-key-001',
          trustedIssuers: ['trust.example.com'],
          minTrust: 'L2',
          nonceStore: 'redis://localhost:6379'
        }));

        // Per-endpoint: payment requires L3
        app.post('/v1/charges',
          attp({ minTrust: 'L3' }),
          async (req, res) => {
            // req.agent.id = "payment-bot-001"
            // req.agent.trustLevel = "L3"
            // req.agent.owner = "Acme Corp"
            const charge = await processPayment(req.body);
            res.json(charge);
            // Response auto-signed by middleware
            // Audit record auto-generated
          }
        );

     C.2.  FastAPI (Python)

        from attp import ATTPMiddleware

        app = FastAPI()
        app.add_middleware(ATTPMiddleware,
            private_key=os.environ["ATTP_PRIVATE_KEY"],
            key_id="server-key-001",
            trusted_issuers=["trust.example.com"],
            min_trust="L2",
            nonce_store="redis://localhost:6379"
        )

        @app.post("/v1/charges")
        async def create_charge(request: Request):
            agent = request.state.agent
            # agent.id, agent.trust_level, agent.owner
            return {"id": "ch_abc123", "status": "succeeded"}

     C.3.  JWKS Endpoint Setup

        The middleware MUST automatically serve the JWKS
        endpoint at /.well-known/agent-trust-keys.  The
        endpoint returns:

        HTTP/1.1 200 OK
        Content-Type: application/json
        Cache-Control: public, max-age=3600

        {
          "keys": [{
            "kty": "EC",
            "crv": "P-256",
            "kid": "server-key-001",
            "use": "sig",
            "alg": "ES256",
            "x": "<Base64url x-coordinate>",
            "y": "<Base64url y-coordinate>"
          }]
        }

     C.4.  Operating Modes

        The middleware supports three operating modes:

        Strict:  Reject non-ATTP requests with HTTP 426.  Use
           for ATTP-only servers.

        Permissive:  Accept both ATTP and regular HTTP.  Apply
           verification only when ATTP headers present.  Use
           during migration.

        Upgrade:  Accept all requests but suggest ATTP in
           responses via Upgrade header.  Use for gradual
           adoption.

     C.5.  Nonce Store Configuration

        Single instance:  In-memory store (default).

        Multi-instance:  Redis or equivalent distributed cache.
           Required when running behind a load balancer.

        Interface:

           has(nonce: string): boolean
           add(nonce: string, ttl: number): void

  Author's Address

     Raza Sharif
     CyberSecAI Ltd
     205 Regent Street
     London W1B 4HB
     United Kingdom

     Email: contact@agentsign.dev


name: draft-anandakrishnan-ptv-attested-agent-identity
rev: 00
title: The Prove-Transform-Verify (PTV) Protocol for Attested Agent Identity
time: 2026-04-01T06:01:14Z
group_uri: /api/v1/group/group/1027/
expires: 2026-10-03T06:01:14Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "AI safety/alignment", "Policy/governance"]
tags: []
fetched_at: 2026-05-22T09:24:41.698287+00:00
source: ietf
abstract:
  This document specifies the Prove-Transform-Verify (PTV) protocol for
     hardware-anchored, zero-knowledge attested agent identity in
     federated environments.  PTV addresses the data gravity problem in
     centralized security models by enabling cross-domain agent
     authorization without raw data exposure.

     The specification includes: TPM 2.0/secure enclave roots of trust;
     Groth16 zero-knowledge proofs (<200ms generation on commodity edge
     hardware); HotStuff Byzantine Fault Tolerant consensus for immutable
     audit trails; and Sovereign Bound metadata for jurisdiction-aware
     attestation chains.

     Use cases include healthcare clinical decision support systems
     (CDSS), critical infrastructure industrial control systems (ICS/OT),
     and cross-border regulatory compliance scenarios under GDPR/HIPAA
     frameworks.

full_text:
  RATS                                                        A. Damodaran
  Internet-Draft                                        Sovereign AI Stack
  Intended status: Informational                             31 March 2026
  Expires: 2 October 2026


   The Prove-Transform-Verify (PTV) Protocol for Attested Agent Identity
            draft-anandakrishnan-ptv-attested-agent-identity-00

  Abstract

     This document specifies the Prove-Transform-Verify (PTV) protocol for
     hardware-anchored, zero-knowledge attested agent identity in
     federated environments.  PTV addresses the data gravity problem in
     centralized security models by enabling cross-domain agent
     authorization without raw data exposure.

     The specification includes: TPM 2.0/secure enclave roots of trust;
     Groth16 zero-knowledge proofs (<200ms generation on commodity edge
     hardware); HotStuff Byzantine Fault Tolerant consensus for immutable
     audit trails; and Sovereign Bound metadata for jurisdiction-aware
     attestation chains.

     Use cases include healthcare clinical decision support systems
     (CDSS), critical infrastructure industrial control systems (ICS/OT),
     and cross-border regulatory compliance scenarios under GDPR/HIPAA
     frameworks.

  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 2 October 2026.







  Damodaran                Expires 2 October 2026                 [Page 1]


  Internet-Draft  PTV Protocol for Attested Agent Identity      March 2026


  Copyright Notice

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

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Terminology and Definitions . . . . . . . . . . . . . . .   3
     2.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Protocol State Machine  . . . . . . . . . . . . . . . . . . .   4
     4.  Cryptographic Primitives  . . . . . . . . . . . . . . . . . .   5
       4.1.  Zero-Knowledge Proofs . . . . . . . . . . . . . . . . . .   5
       4.2.  Hardware Roots of Trust . . . . . . . . . . . . . . . . .   6
       4.3.  Byzantine Fault Tolerant Consensus  . . . . . . . . . . .   6
     5.  Wire Format and Message Flows . . . . . . . . . . . . . . . .   6
       5.1.  Encoding Formats  . . . . . . . . . . . . . . . . . . . .   6
       5.2.  End-to-End Attestation Exchange (Non-Normative) . . . . .   6
     6.  Interoperability  . . . . . . . . . . . . . . . . . . . . . .   7
       6.1.  Relationship to EAT (Entity Attestation Token)  . . . . .   7
       6.2.  Relationship to SCITT (Supply Chain Integrity)  . . . . .   8
       6.3.  Relationship to DICE (Device Identifier Composition
             Engine) . . . . . . . . . . . . . . . . . . . . . . . . .   8
       6.4.  OAuth 2.0 Integration . . . . . . . . . . . . . . . . . .   8
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
       7.1.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .   8
       7.2.  STRIDE Mapping  . . . . . . . . . . . . . . . . . . . . .   9
     8.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  10
     9.  Operational Considerations  . . . . . . . . . . . . . . . . .  10
       9.1.  Key Lifecycle . . . . . . . . . . . . . . . . . . . . . .  10
       9.2.  Monitoring  . . . . . . . . . . . . . . . . . . . . . . .  11
       9.3.  Failover  . . . . . . . . . . . . . . . . . . . . . . . .  11
     10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
       10.1.  PTV Attestation Method Types Registry  . . . . . . . . .  11
       10.2.  MIME Type Full Registration Template . . . . . . . . . .  11
     11. Normative References  . . . . . . . . . . . . . . . . . . . .  12
     12. Informative References  . . . . . . . . . . . . . . . . . . .  13
     Appendix A.  Appendix A - Example Flows (Non-Normative) . . . . .  13
     Appendix B.  Appendix B - Test Vectors (Non-Normative)  . . . . .  13



  Damodaran                Expires 2 October 2026                 [Page 2]


  Internet-Draft  PTV Protocol for Attested Agent Identity      March 2026


       B.1.  Sample model_hash (SHA-256) . . . . . . . . . . . . . . .  13
       B.2.  Sample ATT_REQ (truncated)  . . . . . . . . . . . . . . .  13
       B.3.  Sample Groth16 proof (base64url, 288 bytes) . . . . . . .  14
       B.4.  Expected verification result  . . . . . . . . . . . . . .  14
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  14

  1.  Introduction

     Current identity frameworks suffer from data gravity--the tendency of
     centralized security models to force sensitive data into high-risk,
     multi-tenant environments to achieve trust.  The PTV protocol
     proposes a shift from OAuth 2.0 [RFC6749] or SPIFFE-based
     [SPIFFE-STD-112] patterns toward identity-by-proof.

     Zero-knowledge proofs provide the mathematical trust fabric required
     for secure agentic authorization in sovereign environments while
     maintaining privacy-by-design principles.  This approach extends
     existing standards (OAuth 2.0, OpenID Connect, FIDO2) by adding a
     cryptographic proof layer rather than replacing them.

  1.1.  Terminology and Definitions

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

     Agent                    An autonomous software entity that performs
                              tasks on behalf of a user or system.

     Prover                   The agent component responsible for
                              generating cryptographic attestations about
                              its state or actions.

     Verifier                 A system that validates cryptographic
                              attestations received from Provers without
                              accessing underlying sensitive data.

     Federation Hub           A node in the PTV mesh that maintains BFT-
                              consensus audit logs across multiple
                              jurisdictions.

     Sovereign Bound Metadata  Jurisdiction flags embedded in attestation
                              chains that cannot be removed without
                              invalidating the attestation.

     Hardware Root of Trust   A tamper-resistant chip (TPM 2.0/Secure



  Damodaran                Expires 2 October 2026                 [Page 3]


  Internet-Draft  PTV Protocol for Attested Agent Identity      March 2026


                              Enclave) proving software has not been
                              altered since last attestation.

  2.  Protocol Overview

     The PTV protocol operates through three atomic operations executed in
     sequence:

        Agent               Federation Hub             Verifier
          |                        |                      |
          |---[1] PROVE----------->|                      |
          |   (Generate ZK-proof)  |                      |
          |                        |                      |
          |                        |---[2] TRANSFORM----->|
          |                        |     (Proof only)      |
          |                        |                      |
          |                        |<---[3] VERIFY--------|
          |                        |   (Validate proof)    |

                    Figure 1: PTV Protocol Sequence Diagram

     *  PROVE: Agent generates cryptographic proof locally that task was
        executed correctly on authorized model.

     *  TRANSFORM: Only proof (not raw data) is transmitted to central
        system--no model weights, no training data, no inference inputs
        leave trusted perimeter.

     *  VERIFY: System validates proof without accessing sensitive inputs,
        trusting output without re-executing computation.

  3.  Protocol State Machine



















  Damodaran                Expires 2 October 2026                 [Page 4]


  Internet-Draft  PTV Protocol for Attested Agent Identity      March 2026


     IDLE --> [ATT_REQ] --> PROVING
                    |
              [proof gen]
                    v
              TRANSFORMING
                    |
             [BFT quorum]
                    v
              VERIFYING
               /     \
     [valid]/       \[invalid/timeout]
           v         v
     AUTHORIZED   ERROR/REJECTED
           |           ^
           +--[BFT log]-+

     All transitions MUST log to BFT consensus layer (Section 3.4).

                      Figure 2: PTV Protocol State Machine

     Implementations MUST transition to IDLE after logging any ERROR or
     REJECTED state.

  4.  Cryptographic Primitives

  4.1.  Zero-Knowledge Proofs

     PTV uses Groth16 zk-SNARK implementation [GROTH16-PAPER] for
     efficiency in production environments.  Benchmarks indicate:

             +=======================+==========================+
             | Parameter             | Value                    |
             +=======================+==========================+
             | Proof Generation Time | 187ms +/- 23ms (median   |
             |                       | +/- std dev, n=10,000)   |
             +-----------------------+--------------------------+
             | Proof Verification    | <5ms (on verifier side)  |
             | Time                  |                          |
             +-----------------------+--------------------------+
             | Raw Proof Size        | <300 bytes               |
             +-----------------------+--------------------------+
             | Full Attestation      | <4 KB (includes metadata |
             | Envelope              | plus BFT signature)      |
             +-----------------------+--------------------------+

                   Table 1: Groth16 Performance Benchmarks





  Damodaran                Expires 2 October 2026                 [Page 5]


  Internet-Draft  PTV Protocol for Attested Agent Identity      March 2026


  4.2.  Hardware Roots of Trust

     Agents MUST anchor identities to TPM 2.0 (or equivalent Secure
     Enclave) using Hardware Endorsement Keys (HEK).  [TPM20SPEC] defines
     the endorsement key specification.

     *  PCR Selection: 0 (Platform Config Register for boot integrity)

     *  AK Generation: HMAC-based AK wrapped by EK

     *  Endorsement Key Rotation: every 90 days (MUST)

  4.3.  Byzantine Fault Tolerant Consensus

     PTV employs HotStuff-based BFT consensus at the Federation Hub layer.
     See [HOTSTUFF-PAPER] for protocol details.  This ensures:

     *  Tolerance up to f faulty nodes where f less than floor((n-1)/3)

     *  Cross-jurisdictional audit integrity even if one cloud region
        compromised

     *  Immutable Reasoning Trace verifiable by other sovereign mesh nodes

     *  Sub-second finality (<500ms for f less than or equal to 2 faults)

  5.  Wire Format and Message Flows

  5.1.  Encoding Formats

     Messages use JSON-LD encoding with @context validation.  Binary
     components (ZK-proofs, signatures) are Base64URL-encoded per
     [RFC4648] for transport safety.

     Media type registration recommended: application/ptv-
     attestation+json.  See Section 11.2 for the full IANA registration
     template.

  5.2.  End-to-End Attestation Exchange (Non-Normative)

     This subsection illustrates a complete PROVE–TRANSFORM–VERIFY
     exchange using JSON-LD encoding and the application/ptv-
     attestation+json media type carried in an OAuth 2.0 token request.








  Damodaran                Expires 2 October 2026                 [Page 6]


  Internet-Draft  PTV Protocol for Attested Agent Identity      March 2026


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

  grant_type=client_credentials
  &scope=patient.read
  &ptv_attestation={
    "@context": "https://schemas.example.com/ptv/v1",
    "msg_type": "ATT_REQ",
    "version": "1.0",
    "request_id": "550e8400-e29b-41d4-a716-446655440000",
    "prover_id": "a3f1c8e5b9d2f7a4c6e8b1d3f5a7c9e2b4d6f8a1",
    "timestamp": 1743415200,
    "nonce": "ZGF0YV9leGFtcGxlX25vbmNl",
    "sovereign_bound": {
      "jurisdiction": "EU/DE",
      "region_code": "DE-BY",
      "compliance_profile": ["GDPR"]
    },
    "action_context": {
      "task_type": "eligibility_check",
      "cognitive_mandate": "validate_patient_data",
      "token_expiry": "2026-03-31T12:00:00Z"
    },
    "attestation_envelope": {
      "method": "groth16-2026",
      "proof": "<base64url-groth16-proof>",
      "model_hash": "e3b0c44298fc1c149afbf4c8996fb924ac74ef4ae8e0a28c9a03b3e9d1c6e351b"
    }
  }

     The authorization server binds the issued access token to the
     supplied PTV attestation and enforces the declared sovereign_bound
     and action_context when processing subsequent API calls.

  6.  Interoperability

  6.1.  Relationship to EAT (Entity Attestation Token)

     PTV attestation envelopes MAY be carried as EAT claims [RFC9334].
     Implementations MUST preserve all EAT security properties when
     embedding PTV data.

     For example, a PTV attestation envelope can be embedded as an EAT
     non-critical claim:






  Damodaran                Expires 2 October 2026                 [Page 7]


  Internet-Draft  PTV Protocol for Attested Agent Identity      March 2026


     {
       "eat_profile": "urn:ietf:params:attest:ptv",
       "submods": {
         "ptv": {
           "method": "groth16-2026",
           "attestation_envelope": "<base64url-ptv-attestation>"
         }
       }
     }

  6.2.  Relationship to SCITT (Supply Chain Integrity)

     PTV BFT audit logs are SCITT-compatible transparency logs.  PTV
     proofs MAY be submitted to SCITT registries for public verification.

     A Federation Hub MAY publish each finalized attestation envelope as a
     SCITT transparency log entry, using the attestation hash as the
     statement digest and including sovereign_bound metadata as signed
     attributes.

  6.3.  Relationship to DICE (Device Identifier Composition Engine)

     TPM 2.0 AK binding is compatible with DICE layer 0 identity.  PTV
     inherits DICE chain-of-trust for hardware root establishment.

     When DICE is present, the TPM Attestation Key used in PTV corresponds
     to the layer-0 device identity, and PTV proofs inherit the DICE
     chain-of-trust without additional changes to the wire format.

  6.4.  OAuth 2.0 Integration

     The "ptv_attestation" parameter MAY be carried in [RFC6749] token
     requests to bind access tokens to attested agent identity.

     Authorization servers receiving ptv_attestation parameters MUST
     validate the embedded attestation envelope before issuing an access
     token and MUST reject requests where the model_hash or
     sovereign_bound fields do not match local policy.

  7.  Security Considerations

  7.1.  Threat Model

     PTV assumes an honest-majority Federation Hub with at most f faulty
     nodes where f < floor((n-1)/3), as required by HotStuff-style BFT
     consensus.





  Damodaran                Expires 2 October 2026                 [Page 8]


  Internet-Draft  PTV Protocol for Attested Agent Identity      March 2026


     Agent devices are assumed to have a correctly provisioned hardware
     root of trust (TPM 2.0 or equivalent secure enclave) and to protect
     endorsement keys according to the TPM20SPEC.

     Network attackers are assumed capable of eavesdropping, replay,
     message tampering, and denial-of-service, but not of breaking the
     underlying cryptographic primitives or compromising all BFT nodes
     simultaneously.

     Out-of-scope threats include physical compromise of all Federation
     Hubs in a jurisdiction and regulatory misuse of otherwise valid
     attestation data.

  7.2.  STRIDE Mapping

     This protocol implements a threat model based on STRIDE categories
     mapped to ISO 14971 hazards for medical device integration:

        +=====================+=======================================+
        | Threat Category     | PTV Mitigation                        |
        +=====================+=======================================+
        | Spoofing (Identity) | TPM 2.0 HEK anchoring; prevents       |
        |                     | impersonation across nodes            |
        +---------------------+---------------------------------------+
        | Tampering (Code)    | ZK-proof per inference; verifies      |
        |                     | unaltered model/software state        |
        +---------------------+---------------------------------------+
        | Repudiation         | BFT log plus sovereign metadata; non- |
        |                     | repudiation via attestation chains    |
        +---------------------+---------------------------------------+
        | Information         | Zero-egress ZK (validity only); no    |
        | Disclosure          | plaintext leakage                     |
        +---------------------+---------------------------------------+
        | Denial of Service   | Mesh redundancy; consensus tolerates  |
        |                     | f faulty nodes (f less than n/3)      |
        +---------------------+---------------------------------------+
        | Elevation of        | Capability-based tokens; single-task  |
        | Privilege           | expiration limits scope               |
        +---------------------+---------------------------------------+

                      Table 2: STRIDE Threat Model Mapping

     Implementation notes:

     *  Nonce usage required for replay attack prevention per [RFC4086]

     *  Timestamp validation within plus or minus 5 minute window




  Damodaran                Expires 2 October 2026                 [Page 9]


  Internet-Draft  PTV Protocol for Attested Agent Identity      March 2026


     *  Key management must comply with [RFC8017] RSA padding standards or
        FIPS 140-2 validated libraries

     Operational Security Notes:

     *  Always validate hardware root of trust before accepting
        attestation

     *  Implement rate limiting on proof verification endpoints
        (RECOMMENDED)

     *  Rotate BFT federation hub keys periodically (recommended: every
        180 days)

     *  Log all attestation failures with timestamp for incident response

     *  Maintain backup verification keys for recovery scenarios

     *  Monitor latency SLA: p99.9 under 240ms (alert threshold)

  8.  Privacy Considerations

     PTV enables GDPR Article 25 (Privacy by Design) and HIPAA Minimum
     Necessary principles through architectural means:

     Data Minimization  Only validity statements transmitted; no raw
        patient data, model weights, or inference inputs exposed
        externally.

     Purpose Limitation  Sovereign Bound metadata restricts use to
        declared compliance profile (e.g., EU/GDPR vs US/HIPAA).

     Right to Erasure  While proofs themselves persist (audit trail),
        downstream data processing can be terminated via token revocation.

     HIPAA Safe Harbor  De-identification aligns with 45 CFR 164.514(b)
        anonymization techniques [HIPAA-45-CFR-164.514].

  9.  Operational Considerations

  9.1.  Key Lifecycle

     *  TPM EK rotation: every 90 days (MUST)

     *  BFT node key rotation: every 180 days (SHOULD)

     *  Verification key publication: via HTTPS Well-Known URI (/well-
        known/ptv-keys/)



  Damodaran                Expires 2 October 2026                [Page 10]


  Internet-Draft  PTV Protocol for Attested Agent Identity      March 2026


  9.2.  Monitoring

     *  Attestation failure rate SHOULD be logged per system metrics.

     *  Latency SLA: p99.9 under 240ms (alert threshold)

     *  BFT quorum health checks: every 60 seconds (MUST)

  9.3.  Failover

     *  Minimum 3 BFT nodes per jurisdiction (RECOMMENDED)

     *  Fallback: human override

     *  Recovery procedure: documented in incident response playbook

  10.  IANA Considerations

  10.1.  PTV Attestation Method Types Registry

     New registry: "PTV Attestation Method Types" managed by IANA.
     Initial values:

      +==============+==================================================+
      | Value        | Description                                      |
      +==============+==================================================+
      | groth16-2026 | Groth16 zk-SNARK scheme with 2026 parameter sets |
      +--------------+--------------------------------------------------+
      | plonk-2026   | PLONK universal circuits scheme (future-proof    |
      |              | extension)                                       |
      +--------------+--------------------------------------------------+

                     Table 3: PTV Attestation Method Types

  10.2.  MIME Type Full Registration Template
















  Damodaran                Expires 2 October 2026                [Page 11]


  Internet-Draft  PTV Protocol for Attested Agent Identity      March 2026


     Type name:               application
     Subtype name:            ptv-attestation+json
     Required parameters:     version
     Optional parameters:     jurisdiction
     Encoding considerations: UTF-8
     Security considerations: See Section 9
     Interoperability:        See Section 8
     Published specification: This document
     Applications:            AI agent attestation systems
     Fragment identifier:     None
     Restrictions on usage:   None
     Author:                  Anandakrishnan Damodaran
     Change controller:       IETF

  11.  Normative References

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

     [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
                Requirements for Security", June 2005,
                <https://www.rfc-editor.org/info/rfc4086>.

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

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

     [RFC8017]  Moriarty, K. and B. Kaliski, "PKCS #1: RSA Cryptography
                Specifications Version 2.2", November 2016,
                <https://www.rfc-editor.org/info/rfc8017>.

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

     [RFC9334]  Birkholz, H., Thaler, D., and M. Richardson, "Remote
                ATtestation ProcedureS (RATS) Architecture", January 2023,
                <https://www.rfc-editor.org/info/rfc9334>.

     [TPM20SPEC]
                Trusted Computing Group, "Trusted Platform Module Library
                Specification, Level 02 Revision 01.57", September 2019,
                <https://trustedcomputinggroup.org/resource/tpm-library-
                specification/>.



  Damodaran                Expires 2 October 2026                [Page 12]


  Internet-Draft  PTV Protocol for Attested Agent Identity      March 2026


  12.  Informative References

     [GROTH16-PAPER]
                Groth, J., "On the Size of Pairing-Based Non-Interactive
                Arguments", 2016, <https://eprint.iacr.org/2016/260>.

     [HOTSTUFF-PAPER]
                Yin, M., Malkhi, D., and M.K. Reiter, "HotStuff: BFT
                Consensus in the Lens of Blockchain", 2019,
                <https://arxiv.org/abs/1803.05069>.

     [SPIFFE-STD-112]
                SPIFFE Working Group, "SPIFFE Standard ID 112: SPIFFE
                Workload Identity", May 2022,
                <https://github.com/spiffe/spiffe/blob/main/standards/STD-
                112.md>.

     [HIPAA-45-CFR-164.514]
                U.S. Department of Health and Human Services, "Standards
                for Privacy of Individually Identifiable Health
                Information", 2013, <https://www.ecfr.gov/current/title-
                45/subtitle-A/subchapter-C/part-164/subpart-E/section-
                164.514>.

  Appendix A.  Appendix A - Example Flows (Non-Normative)

     Healthcare eligibility check scenario  Demonstrates zero-egress
        architecture where French regulator verifies German hospital CDSS
        output without receiving patient records.

     Critical infrastructure firmware update scenario  Shows how
        substation RTUs verify Control Centre updates using ZK-proofs
        instead of downloading binary payloads.

  Appendix B.  Appendix B - Test Vectors (Non-Normative)

  B.1.  Sample model_hash (SHA-256)

     e3b0c44298fc1c149afbf4c8996fb924ac74ef4ae8e0a28c9a03b3e9d1c6e351b

  B.2.  Sample ATT_REQ (truncated)










  Damodaran                Expires 2 October 2026                [Page 13]


  Internet-Draft  PTV Protocol for Attested Agent Identity      March 2026


     {
     "msg_type": "ATT_REQ",
     "version": "1.0",
     "request_id": "550e8400-e29b-41d4-a716-446655440000",
     "prover_id": "a3f1c8e5b9d2f7a4c6e8b1d3f5a7c9e2b4d6f8a1",
     "timestamp": 1743415200,
     "nonce": "ZGF0YV9leGFtcGxlX25vbmNl",
     "sovereign_bound": {
     "jurisdiction": "EU/DE",
     "region_code": "DE-BY"
     }
     }

  B.3.  Sample Groth16 proof (base64url, 288 bytes)

     eyJhIjpbIjB4MWFlODg3OWJiN2ExNTQ4NjU4OTFhMWRjOGVlYmIwMGIyNTE5MTc2ND...

  B.4.  Expected verification result

     {
     "valid": true,
     "jurisdiction": "EU",
     "latency_ms": 187,
     "model_hash_verified": true,
     "sovereign_bound_ok": true
     }

  Author's Address

     Anandakrishnan Damodaran
     Sovereign AI Stack
     Email: ananda.krishnan@hotmail.com
     URI:   https://github.com/anandkrshnn


















  Damodaran                Expires 2 October 2026                [Page 14]


