TBD J. M. Barney Internet-Draft R. Pioli Intended status: Informational D. Watson Expires: 28 August 2026 Independent 24 February 2026 Contextual Agent Authorization Mesh (CAAM) draft-barney-caam-00 Abstract This document specifies the Contextual Agent Authorization Mesh (CAAM), an authorization profile composable with the Agent Registration and Discovery Protocol (ARDP) I-D.pioli-agent-discovery and other discovery mechanisms. CAAM defines the Post-Discovery Authorization Handshake: the runtime authorization layer that governs agent behavior after an agent has been discovered through ARDP but before it is permitted to execute tool calls or delegate authority. CAAM provides a sidecar-based authorization mediator for enforcing Relationship-Based Access Control (ReBAC), purpose-bound delegation, and cryptographically verifiable intent propagation in Human-to-Agent (H2A) and Agent-to-Agent (A2A) flows. It bridges identity provenance frameworks -- the Interoperability Profiling for Secure Identity in the Enterprise (IPSIE) IPSIE and the Secure Production Identity Framework for Everyone (SPIFFE) SPIFFE -- with the ARDP control plane, leveraging OpenID XAA for coarse-grained delegation, a Knowledge Graph for real-time relationship inference, and the Remote ATtestation procedureS (RATS) architecture RFC9334 for cryptographically verifiable attestation of agent execution environments. The Session Context Object (SCO) defined herein is encoded as a JSON Web Token (JWT) RFC7519 or a CBOR Web Token (CWT) RFC8392, and carries a new "ctx" (Contextual Assertion) claim that binds the agent's delegated authority to a specific purpose, session, and trust chain. 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/. Barney, et al. Expires 28 August 2026 [Page 1] Internet-Draft CAAM February 2026 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 August 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Relationship to Existing Standards . . . . . . . . . . . 5 1.2. The Post-Discovery Authorization Handshake . . . . . . . 5 1.3. The Multi-Hop Intent Binding Problem . . . . . . . . . . 6 1.3.1. Standardization Gap Analysis . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Architectural Foundations . . . . . . . . . . . . . . . . 8 3.1.1. SPIFFE/SPIRE as the Workload Identity Root . . . . . 9 3.1.2. IPSIE as the Human Provenance Layer . . . . . . . . . 9 3.1.3. ARDP and the Discovery-Authorization Nexus . . . . . 9 3.1.4. RFC 9334 (RATS) Alignment . . . . . . . . . . . . . . 9 3.2. The CAAM Sidecar Model . . . . . . . . . . . . . . . . . 10 3.2.1. Intercepting the Outbound Tool Calls . . . . . . . . 10 3.2.2. Impersonation vs. Delegation . . . . . . . . . . . . 10 3.2.3. The Ghost Token Pattern . . . . . . . . . . . . . . . 11 3.3. The Session Context Object (SCO) . . . . . . . . . . . . 11 3.3.1. The "ctx" Claim . . . . . . . . . . . . . . . . . . . 11 3.3.2. Intent-Signature Mechanism . . . . . . . . . . . . . 13 3.4. Policy Substrate: Knowledge Graphs and ReBAC . . . . . . 14 3.4.1. Relationship Ingestion . . . . . . . . . . . . . . . 14 3.4.2. Common Ancestor Constraint . . . . . . . . . . . . . 14 3.4.3. Zanzibar Model . . . . . . . . . . . . . . . . . . . 14 3.5. Protocol Integration . . . . . . . . . . . . . . . . . . 14 3.5.1. OpenID XAA Binding . . . . . . . . . . . . . . . . . 14 Barney, et al. Expires 28 August 2026 [Page 2] Internet-Draft CAAM February 2026 3.5.2. OpenID IPSIE Binding and Shared Signals . . . . . . . 15 3.5.3. Post-Discovery CAAM Handshake . . . . . . . . . . . . 15 3.5.4. Capability Fuzzing (Narrowed Persona) . . . . . . . . 16 3.5.5. Protocol Phases . . . . . . . . . . . . . . . . . . . 17 3.6. Contextual Risk Scoring (CRS) . . . . . . . . . . . . . . 17 3.7. Policy Orchestration . . . . . . . . . . . . . . . . . . 18 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 4.1. Token Theft and Exfiltration . . . . . . . . . . . . . . 18 4.2. Context Spoofing . . . . . . . . . . . . . . . . . . . . 19 4.3. Proof-of-Possession Binding . . . . . . . . . . . . . . . 20 4.4. Prompt Injection as Privilege Escalation . . . . . . . . 21 4.5. Multi-Hop Identity Dilution . . . . . . . . . . . . . . . 21 4.6. Confused Deputy Prevention . . . . . . . . . . . . . . . 22 4.7. Data-in-Use Protection (Future Work) . . . . . . . . . . 23 4.8. Policy and Knowledge Graph Integrity . . . . . . . . . . 23 4.9. Agent Supply Chain Security . . . . . . . . . . . . . . . 23 4.10. Formal Threat Model . . . . . . . . . . . . . . . . . . . 24 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25 5.1. Inference Isolation . . . . . . . . . . . . . . . . . . . 25 5.2. Minimal Disclosure . . . . . . . . . . . . . . . . . . . 26 5.2.1. Coarse-Grained Context by Default . . . . . . . . . . 26 5.2.2. Additional Disclosure Constraints . . . . . . . . . . 27 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 6.1. JSON Web Token Claims Registration . . . . . . . . . . . 27 6.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 27 6.2. OAuth Parameters Registration . . . . . . . . . . . . . . 28 6.3. OAuth Token Introspection Response . . . . . . . . . . . 29 6.4. CAAM Agent Discovery Metadata Registry . . . . . . . . . 29 6.4.1. Registration Policy . . . . . . . . . . . . . . . . . 29 6.4.2. Initial Registry Contents . . . . . . . . . . . . . . 29 6.4.3. ARDP Registry Extensions . . . . . . . . . . . . . . 30 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.1. Normative References . . . . . . . . . . . . . . . . . . 30 7.2. Informative References . . . . . . . . . . . . . . . . . 31 Appendix A. Appendix A. Mathematical Models for Inference Isolation . . . . . . . . . . . . . . . . . . . . . . . . 32 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 32 Appendix C. Document History . . . . . . . . . . . . . . . . . . 32 C.1. draft-barney-caam-00 . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Barney, et al. Expires 28 August 2026 [Page 3] Internet-Draft CAAM February 2026 1. Introduction The evolution of enterprise infrastructure toward autonomous and semi-autonomous agentic systems has introduced a fundamental gap in identity and access management. Traditional security architectures, designed for static workloads and direct human-to-service interactions, are insufficient for managing the non-deterministic, ephemeral, and multi-hop nature of Large Language Model (LLM) agents. Current security models address identity at two distinct layers: the human user (via OpenID Connect and IPSIE IPSIE) and the machine workload (via SPIFFE SPIFFE). Autonomous agents occupy a hybrid space -- a software workload that possesses its own identity but operates with the delegated authority of a human user or another agent. This hybridity creates a gap where traditional Role-Based Access Control (RBAC) fails to account for the ephemeral and purpose- driven nature of agentic tasks. +====================+===============+=========+===============+ | Security Dimension | Workload | Human | Agent | +====================+===============+=========+===============+ | Identity Type | SVID | User ID | Composite | +--------------------+---------------+---------+---------------+ | Lifespan | Long-lived | Session | Ephemeral | +--------------------+---------------+---------+---------------+ | Decision Logic | Deterministic | Human | Probabilistic | +--------------------+---------------+---------+---------------+ | Trust Anchor | Attestor | IdP | Discovery+Ctx | +--------------------+---------------+---------+---------------+ | Authorization | Static | Role | Contextual | +--------------------+---------------+---------+---------------+ Table 1 As agents move from simple request-response patterns to independent reasoning and tool invocation, the risk of "identity dilution" and "authorization loops" grows. Without a dedicated mesh to manage these interactions, organizations face a choice between over- privileging agents -- expanding the blast radius of potential compromises -- or restricting them to functional uselessness. CAAM resolves this tension by enforcing policy at the most granular level of the agent's internal reasoning loop. Barney, et al. Expires 28 August 2026 [Page 4] Internet-Draft CAAM February 2026 1.1. Relationship to Existing Standards CAAM is not intended as a replacement for existing identity, authorization, or attestation protocols. It functions as an orchestration profile -- a connective layer that composes outputs from multiple mature standards into a single, coherent authorization decision tailored to autonomous agent ecosystems. CAAM occupies three complementary roles: * GNAP Extension for Non-Deterministic Clients: The Grant Negotiation and Authorization Protocol (GNAP) RFC9635 assumes a client capable of participating in structured negotiation flows. Autonomous agents are non-deterministic clients whose resource requirements emerge dynamically during multi-step reasoning. CAAM extends the GNAP model by introducing the Session Context Object (SCO) as a purpose-bound grant envelope that constrains the agent's evolving resource requests to the boundaries of the original human intent. * Policy Enforcement Point for RATS: The RATS architecture RFC9334 defines the roles of Attester, Verifier, and Relying Party but does not prescribe where in an application's request path the Attestation Result SHOULD be consumed or how it SHOULD influence fine-grained authorization decisions. The CAAM sidecar serves as a dedicated Policy Enforcement Point (PEP) that ingests RATS Attestation Results and combines them with identity provenance and data sensitivity signals to produce the Contextual Risk Score (CRS) defined in contextual-risk-scoring. * Trust Framework for Multi-Hop Delegation: OAuth 2.1 and Token Exchange RFC8693 provide mechanisms for single-hop delegation and impersonation. They do not natively address the compound trust problem arising in N-hop agentic chains (User -> Agent A -> Agent B -> Agent C), where each intermediate agent introduces a new trust boundary. CAAM provides Scope Attenuation, Depth-Limited Tokens, and Intent-Binding to ensure that delegated authority degrades gracefully rather than accumulating across hops. 1.2. The Post-Discovery Authorization Handshake CAAM provides the Post-Discovery Authorization Handshake for I- D.pioli-agent-discovery. The ARDP control plane enables an orchestrating client to discover an agent's endpoint, capabilities, and network address. However, ARDP does not prescribe the authorization protocol that governs the agent's behavior once a session is established. Barney, et al. Expires 28 August 2026 [Page 5] Internet-Draft CAAM February 2026 CAAM fills this gap. After an ARDP RESOLVE operation returns an agent's endpoint, the CAAM sidecar mediates a mutual attestation handshake between the client and the discovered agent before any tool call is permitted. This handshake establishes: 1. Mutual identity verification via SPIFFE SVIDs and RATS Attestation Evidence. 2. A purpose-bound Session Context Object (SCO) that constrains the agent's authority to the specific task. 3. A JIT Scoped Token (via the Ghost Token Pattern) that replaces any long-lived credential with a short-lived, nonce-bound, single-use token. Without CAAM, an ARDP-discovered agent could be invoked with a static bearer token that carries no purpose binding, no environmental attestation, and no delegation-depth limit -- the failure mode observed in real-world incidents where agents used static bearer tokens without purpose binding. 1.3. The Multi-Hop Intent Binding Problem The core standardization gap that CAAM addresses is Multi-Hop Intent Binding: the problem of proving, at each hop in a delegation chain, that the current agent's request remains within the semantic bounds of the original user's intent -- without over-privileging the entire chain. Existing standards address adjacent concerns but leave this problem unresolved: * OAuth XAA handles coarse-grained identity delegation across application boundaries. It establishes who is delegating what scope to which application. However, XAA does not track whether a sub-delegated agent three hops downstream is still operating within the purpose for which the original grant was issued. * RATS RFC9334 provides cryptographic assurance of the execution environment's integrity. It establishes where the agent is running and whether that environment is trustworthy. However, RATS Evidence contains no semantic information about the agent's current task or whether that task aligns with the original user's intent. * CAEP/SSE (Shared Signals and Events) enables reactive session- level signals (e.g., "user logged out," "device compromised"). These signals operate at the granularity of sessions and are Barney, et al. Expires 28 August 2026 [Page 6] Internet-Draft CAAM February 2026 propagated asynchronously. They do not provide the synchronous, per-request intent verification required to gate individual tool calls within a multi-hop agentic flow. CAAM bridges this gap by binding each request in the delegation chain to a cryptographically signed Intent-Signature derived from the original SCO, verified at every hop by the CAAM sidecar before a JIT Scoped Token is synthesized. 1.3.1. Standardization Gap Analysis The following table identifies the authorization dimensions relevant to autonomous agent ecosystems and maps the coverage provided by existing standards against the extensions introduced by CAAM. +=============+============+=============+=========+=============+ | Dimension | OAuth/GNAP | RATS | CAEP | CAAM | +=============+============+=============+=========+=============+ | Delegation | 1-hop | N/A | N/A | N-hop+Scope | | | | | | Attenuation | +-------------+------------+-------------+---------+-------------+ | Env Trust | N/A | HW/SW | N/A | CRS input | +-------------+------------+-------------+---------+-------------+ | Risk | N/A | N/A | Async | Sync | | Signals | | | | narrowing | +-------------+------------+-------------+---------+-------------+ | Intent | Static | Env-only | None | Per-request | +-------------+------------+-------------+---------+-------------+ | Credentials | Bearer | N/A | N/A | Ghost Token | +-------------+------------+-------------+---------+-------------+ | Inference | N/A | N/A | N/A | Firewall | +-------------+------------+-------------+---------+-------------+ | Granularity | Grant | Attestation | Session | Request | +-------------+------------+-------------+---------+-------------+ | Decision | Scope | Pass/fail | Event | CRS tiers | +-------------+------------+-------------+---------+-------------+ Table 2 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. Contextual Mesh: A decentralized, sidecar-based authorization layer Barney, et al. Expires 28 August 2026 [Page 7] Internet-Draft CAAM February 2026 that enforces purpose-bound and context-aware access controls across a network of autonomous agents. Agent Principal: The composite identity of an agent, incorporating its hardware-attested workload identity (SPIFFE ID) and its delegated human user context (IPSIE claims). Inference Boundary: A documented and machine-enforceable specification that defines the permissible and prohibited conclusions an agent MAY draw from the combination of authorized data sources. Session Context Object (SCO): A cryptographically signed, transient data structure encoded as a JWT RFC7519 or CWT RFC8392 that encapsulates the intent, purpose, and provenance of an agentic interaction. Tool-Call Interception: The process by which an authorization sidecar monitors and regulates the outbound network/API request calls made by an agent. steps of an LLM agent to prevent policy violations. Narrowed Persona: The reduced capability set advertised by an agent after the Resolver applies contextual filtering based on participant relationships. Ghost Token: A credential management pattern where the raw delegation token is never exposed to the agent; instead, the mesh synthesizes a short-lived, purpose-scoped replacement at the moment of use. Contextual Risk Score (CRS): A real-valued score S in the range [0, 1] assigned to every request within the mesh, encoding the combined risk of provenance, environment trust, and data sensitivity. Intent-Signature: A cryptographic binding between the original user's purpose (as encoded in the SCO) and each subsequent request in a delegation chain, implemented as a Chained JWS RFC7515. 3. Protocol Overview 3.1. Architectural Foundations CAAM leverages the existing maturity of identity provenance standards while extending them to meet agentic requirements. Barney, et al. Expires 28 August 2026 [Page 8] Internet-Draft CAAM February 2026 3.1.1. SPIFFE/SPIRE as the Workload Identity Root The Secure Production Identity Framework for Everyone (SPIFFE) SPIFFE provides a platform-agnostic standard for identifying software workloads. Every agent instance in a CAAM-compliant deployment MUST be registered with a SPIRE server and issued a SPIFFE Verifiable Identity Document (SVID), typically in the form of an X.509 certificate. This SVID provides the agent with a non-repudiable identity that is automatically rotated and cryptographically bound to the execution environment. This machine-level identity is the first layer of the CAAM trust model. 3.1.2. IPSIE as the Human Provenance Layer While SPIFFE identifies the workload, the IPSIE profiles IPSIE identify the delegating human. When a human user initiates a task requiring agent assistance, their IPSIE-compliant identity token serves as the original source of authority. CAAM uses this provenance to bind the agent's workload identity to the human's session identity, creating a composite principal. 3.1.3. ARDP and the Discovery-Authorization Nexus The Agent Registration and Discovery Protocol (ARDP) I-D.pioli-agent- discovery establishes a control plane for agents to advertise capabilities and network endpoints. CAAM extends ARDP by introducing "AuthZ-at-Discovery," where the security capabilities and policy compliance of an agent are verified before a session is established. Implementations that support CAAM MUST advertise the following metadata in the ARDP registry: the agent's SPIFFE trust domain, supported RATS Evidence types, Inference Boundary hash, and policy manifest URI. 3.1.4. RFC 9334 (RATS) Alignment The CAAM Mesh adopts the RATS architecture RFC9334. Within the mesh, the following roles are defined: * Attester: The Agent or Sub-Agent providing Evidence. Every agent in a CAAM-compliant deployment MUST be capable of producing RATS Evidence that can be independently verified. Evidence includes runtime state, TPM 2.0 platform quotes, and signed container image digests. Barney, et al. Expires 28 August 2026 [Page 9] Internet-Draft CAAM February 2026 * Verifier: The CAAM Sidecar component that processes Evidence against Endorsements from the SPIRE trust domain. The Verifier produces an Attestation Result that encodes the trustworthiness of the agent's current execution environment. * Relying Party: The Resource Server that consumes the Attestation Result to authorize the tool call. The Relying Party MUST NOT process raw Evidence; it relies on the Verifier's signed Attestation Result. 3.2. The CAAM Sidecar Model The CAAM sidecar is the core enforcement mechanism. It is a lightweight proxy that runs alongside the agent workload, intercepting all internal and external communications. 3.2.1. Intercepting the Outbound Tool Calls The tool-call loop is the fundamental interaction cycle of an autonomous agent: 1. Thought: The LLM generates a plan or tool call. 2. Action: The agent executes the tool call. 3. Observation: The agent receives results and reasons further. The CAAM sidecar MUST intercept this loop at the transition between Thought and Action. By acting as a semantic gateway, the sidecar analyzes the intent of the tool call before it reaches the network. 3.2.2. Impersonation vs. Delegation CAAM utilizes Token Exchange RFC8693 to manage relationships in multi-hop chains. It distinguishes between Impersonation (agent acts as the user) and Delegation (agent acts on behalf of the user while maintaining its own identity). In the CAAM delegation model, the resulting access token MUST include an act (actor) claim that captures the entire lineage: Barney, et al. Expires 28 August 2026 [Page 10] Internet-Draft CAAM February 2026 +=============+==================+===================+ | Step | Token Components | Identity State | +=============+==================+===================+ | User starts | IPSIE Token | sub: User | +-------------+------------------+-------------------+ | A calls B | A SVID + Token | sub: User, act: A | +-------------+------------------+-------------------+ | B calls RS | B SVID + Prev | act: B { act: A } | +-------------+------------------+-------------------+ Table 3 To maintain least privilege, CAAM mandates Scope Attenuation: each subsequent token in the chain MUST have an equal or smaller scope than its predecessor. Implementations MUST NOT permit scope expansion during delegation. 3.2.3. The Ghost Token Pattern While OAuth XAA handles coarse delegation between applications, CAAM introduces the Ghost Token Pattern to prevent raw credential exposure: 1. Grant: The User provides a long-lived XAA grant to the Lead Agent, representing the ceiling of the agent's authority. 2. Shadowing: The Lead Agent MUST NOT possess the raw XAA token. The token resides exclusively in the CAAM Vault. The agent holds only an opaque reference. 3. Synthesis: Upon a tool request, the Mesh synthesizes a JIT Scoped Token that merges the XAA permission ceiling with the current RATS Attestation Evidence and the active SCO. This token MUST be short-lived (less than 60 seconds TTL), bound to a cryptographic nonce, scoped to the exact tool call, and non-replayable. 3.3. The Session Context Object (SCO) The Session Context Object (SCO) is the central data structure of the CAAM protocol. It MUST be encoded as a JWT RFC7519 for HTTP-based transports or as a CWT RFC8392 for constrained environments. 3.3.1. The "ctx" Claim This document defines a new JWT/CWT claim: ctx (Contextual Assertion): A JSON object (or equivalent CBOR map) Barney, et al. Expires 28 August 2026 [Page 11] Internet-Draft CAAM February 2026 that carries the contextual metadata required for CAAM authorization decisions. The "ctx" claim is registered per iana- considerations. The "ctx" claim MUST contain the following members: * "purpose": A string describing the human-readable intent of the agentic task. This value is set at origination and MUST NOT be modified by intermediate agents. * "scope_ceiling": An array of OAuth scope strings representing the maximum authority derived from the original XAA grant. * "max_hops": An integer indicating the remaining delegation depth. This value MUST be decremented by 1 at each delegation hop. When "max_hops" reaches 0, further delegation MUST be denied. * "zookie": A consistency token (as defined by the Zanzibar model ZANZIBAR) ensuring that relationship queries reflect the most recent state of the Knowledge Graph. * "rats_result": A reference to the Verifier's Attestation Result for the current agent, encoded as a URI or an embedded Evidence structure per RFC9334. * "crs": The current Contextual Risk Score, a decimal value in the range [0, 1]. The SCO MUST be signed by the originating Identity Provider at creation. At each delegation hop, the delegating agent's CAAM sidecar MUST append an act claim and sign the extended SCO with its SPIFFE SVID key, forming a Chained JWS RFC7515. The following is a non-normative example of an SCO JWT payload: Barney, et al. Expires 28 August 2026 [Page 12] Internet-Draft CAAM February 2026 { "iss": "https://idp.corp.internal", "sub": "user:jonathan@corp.com", "aud": "agent:finance-bot@corp.internal", "iat": 1740355200, "exp": 1740358800, "act": { "sub": "spiffe://corp.internal/agent/fb" }, "ctx": { "purpose": "Q4 revenue audit", "scope_ceiling": [ "finance:read", "crm:read" ], "max_hops": 3, "zookie": "zk_v1_998877", "rats_result": "https://verifier.corp.internal/abc", "crs": 0.22 } } 3.3.2. Intent-Signature Mechanism To solve the Multi-Hop Intent Binding problem, CAAM uses the Intent- Signature: a Chained JWS RFC7515 binding the original user's purpose to each subsequent request. 1. Origination: The CAAM mesh generates an SCO containing the "purpose", "scope_ceiling", and "max_hops" claims. The SCO is signed by the originating Identity Provider. 2. Propagation: At each hop, the delegating agent's sidecar appends its own "act" claim and a "sub_purpose" narrowing the task scope. The sidecar signs the extended SCO with its SPIFFE SVID key, producing a Chained JWS. 3. Verification: Before synthesizing a JIT Scoped Token, the receiving sidecar MUST verify the entire signature chain. Verification confirms that: * Each signature is valid against the signer's SPIFFE SVID. * The "sub_purpose" at the current hop MUST be validated against the permitted scope boundaries using deterministic policy evaluation (e.g., OPA/Cedar tag matching). Barney, et al. Expires 28 August 2026 [Page 13] Internet-Draft CAAM February 2026 * The requested scope does not exceed the "scope_ceiling" after Scope Attenuation. * The "max_hops" counter is non-negative. * The current CRS is within the acceptable remediation tier. 4. Gating: If any verification step fails, the sidecar MUST deny the tool call and MAY trigger a HITL escalation per the CRS remediation tiers. 3.4. Policy Substrate: Knowledge Graphs and ReBAC To avoid manual policy sprawl, CAAM mandates a Policy Inference Plane that treats the enterprise Knowledge Graph as the source of truth for relationship-based access decisions. 3.4.1. Relationship Ingestion The mesh MUST ingest relationship triples from existing IAM data (via SCIM) and real-time collaboration signals. These relationships form the edges of the Knowledge Graph and MUST be updated continuously. 3.4.2. Common Ancestor Constraint For multi-participant sessions, the Resolver MUST satisfy the Common Ancestor Constraint: all participants in a session MUST share a relationship path through the Knowledge Graph to the data silo being accessed. If any participant lacks this path, the agent's capability set MUST be narrowed accordingly. 3.4.3. Zanzibar Model Implementation of the Zanzibar model ZANZIBAR (e.g., SpiceDB) is RECOMMENDED. This allows the N-way intersection check to be performed using consistency tokens (e.g., Zanzibar-style 'zookies') to ensure causal consistency during policy evaluation. 3.5. Protocol Integration CAAM operates as a secondary control plane between the ARDP discovery layer I-D.pioli-agent-discovery and the execution protocol (e.g., MCP, HTTP, or gRPC). 3.5.1. OpenID XAA Binding The initial delegation between the Human and the Agent occurs via OpenID XAA: Barney, et al. Expires 28 August 2026 [Page 14] Internet-Draft CAAM February 2026 * The User grants the agent a scope (e.g., "client_data:read"). * This XAA grant is treated as a root node in the Knowledge Graph, providing the agent the potential to access data. The potential is narrowed by real-time context. * The raw XAA token MUST be stored in the CAAM Vault and MUST NOT be exposed to the agent directly. 3.5.2. OpenID IPSIE Binding and Shared Signals CAAM utilizes IPSIE IPSIE to manage the Agentic Session: * The session_id in the ARDP RESOLVE call MUST map to an IPSIE session identifier. * The Resolver MUST act as a Shared Signals Framework (SSF) receiver. If an SSF event indicates a change in session risk or participant list, the Resolver MUST immediately narrow any agent capabilities that no longer satisfy the Knowledge Graph intersection. 3.5.3. Post-Discovery CAAM Handshake After a client successfully discovers an agent via the ARDP RESOLVE method, it initiates a separate, subsequent handshake to establish the cryptographic context required for contextual authorization. This is performed via an HTTP POST to the discovered agent's /caam/ authorize endpoint: Barney, et al. Expires 28 August 2026 [Page 15] Internet-Draft CAAM February 2026 { "method": "POST", "endpoint": "/caam/authorize", "aid": "agent:finance-bot@corp.internal", "context": { "session_id": "ipsie-session-2026-v1", "xaa_ref": "vault:opaque-ref-001", "participants": [ { "format": "email", "email": "jonathan@corp.com" }, { "format": "email", "email": "guest@client2.com" } ], "consistency_token": "zk_v1_998877", "rats_evidence": { "attester_id": "spiffe://corp.internal/agent/fb", "evidence_type": "tpm2.0", "manifest_hash": "sha256:ab12cd34" } } } 3.5.4. Capability Fuzzing (Narrowed Persona) Upon RESOLVE, the Resolver performs contextual capability filtering in two phases: Discovery-Time Narrowing: 1. Execute a Knowledge Graph traversal to determine whether all participants share a relationship with the target data silos. 2. If a participant lacks access to a data silo, the Resolver MUST remove tools associated with that silo from the agent's capability advertisement. 3. The agent is discovered with a Narrowed Persona. Session-Time Enforcement: 1. The sidecar MUST enforce the same filtering on every tool call via outbound request interception. Barney, et al. Expires 28 August 2026 [Page 16] Internet-Draft CAAM February 2026 2. If an SSF event changes the participant list mid-session, the sidecar MUST re-execute the Knowledge Graph intersection and further narrow (MUST NOT expand) the agent's capabilities. 3.5.5. Protocol Phases The CAAM protocol proceeds through four phases: 1. Discovery Phase: The client searches for an agent via ARDP. The Resolver returns the agent's endpoint along with its CAAM Capability Block (SPIFFE ID, supported policy languages, Inference Boundary hash). 2. Negotiation Phase: The client and the agent's sidecar perform mutual attestation. The client provides its identity proof and the SCO. The sidecar verifies the SCO against IPSIE risk signals and RATS Evidence. 3. Establishment Phase: Upon successful negotiation, a Contextual Session is established. The sidecar issues a JIT Scoped Token via the Ghost Token Pattern. 4. Enforcement Phase: The sidecar intercepts the tool call and performs real-time validation of every tool call against the SCO, Inference Boundary, and CRS threshold. 3.6. Contextual Risk Scoring (CRS) Every request within the mesh MUST be assigned a Contextual Risk Score (CRS), S in the range [0, 1], calculated by the Verifier. S = w_1 * P + w_2 * E + w_3 * D Where P is Provenance, E is EnvTrust, D is DataSensitivity, w_1 + w_2 + w_3 = 1, and weights are configurable per deployment. The factors are: * Provenance: The strength and freshness of the identity chain, hop count from the original user, SVID validity, and SCO integrity. * EnvTrust: Trustworthiness of the execution environment per RATS Attestation Evidence -- TPM status, manifest integrity, geographic compliance. * DataSensitivity: Classification of the target resource (public, internal, confidential, regulated PII). Remediation Tiers: Barney, et al. Expires 28 August 2026 [Page 17] Internet-Draft CAAM February 2026 +================+==========+========================+ | CRS Range | Level | Action | +================+==========+========================+ | S < 0.3 | Nominal | JIT Token execution | +----------------+----------+------------------------+ | 0.3 <= S < 0.7 | Elevated | Step-Up (MFA) REQUIRED | +----------------+----------+------------------------+ | S >= 0.7 | Critical | HITL REQUIRED | +----------------+----------+------------------------+ Table 4 The CRS MUST be recalculated on every tool call. A spike in CRS mid- session (e.g., from an SSF risk event) MUST trigger immediate re- evaluation and potential session downgrade. 3.7. Policy Orchestration CAAM translates high-level intent into machine-enforceable policies via HEXA HEXA and IDQL: 1. Intent Capture: An administrator defines intent in IDQL. 2. Translation: The HEXA orchestrator translates IDQL to target- specific format (Rego for OPA OPA, Cedar CEDAR). 3. Distribution: Policy bundles are pushed to sidecars. 4. Enforcement: The sidecar evaluates tool calls against bundles, using SCO metadata for context. Implementations MAY support both OPA and Cedar simultaneously. 4. Security Considerations This section analyzes the threat landscape specific to autonomous agent ecosystems and describes how CAAM mitigates each identified threat. The analysis follows a defense-in-depth model where multiple independent controls reinforce each other. 4.1. Token Theft and Exfiltration An attacker who gains access to an agent's runtime environment (e.g., via container escape or memory dump) may attempt to exfiltrate tokens for use outside the legitimate agent context. CAAM employs four independent defenses: Barney, et al. Expires 28 August 2026 [Page 18] Internet-Draft CAAM February 2026 1. Ghost Token Pattern: The raw long-lived XAA delegation token never enters the agent's address space. It resides exclusively in the CAAM Vault. An attacker who compromises the agent runtime will find only opaque vault references, not actionable credentials. 2. JIT Token Ephemerality: The JIT Scoped Token synthesized for each tool call MUST have a maximum TTL of 60 seconds and MUST be bound to a single-use cryptographic nonce. After the first presentation, the Relying Party MUST record the nonce in a replay cache and reject any subsequent presentation. 3. Proof-of-Possession via DPoP: Every JIT Scoped Token MUST be sender-constrained using the Demonstrating Proof-of-Possession (DPoP) mechanism defined in RFC9449. The token includes a "jkt" (JWK Thumbprint) confirmation claim that binds it to the agent's SPIFFE SVID private key. At each tool call, the agent MUST present a DPoP proof JWT signed with the corresponding private key. A stolen token is unusable without the private key, which MUST be stored in a hardware-backed keystore (TPM 2.0 or Cloud KMS) and MUST NOT be exportable. 4. Environment Binding: The token embeds a hash of the RATS Attestation Result that was current at synthesis time. An attacker presenting the token from a different environment will fail the attestation verification, and the token MUST be rejected. These defenses are conjunctive. Even if an attacker overcomes one layer (e.g., extracts a JIT token before it expires), the remaining layers (DPoP binding, environment binding, nonce exhaustion) independently prevent misuse. 4.2. Context Spoofing Context spoofing occurs when an agent or its operator falsifies environmental signals to obtain a more permissive authorization decision. For example, an agent operating on a public network could claim to be executing within a corporate-office context to bypass geofencing policies. CAAM mitigates context spoofing through the following requirements: Barney, et al. Expires 28 August 2026 [Page 19] Internet-Draft CAAM February 2026 * Self-Asserted Context Prohibition: The CAAM Verifier MUST NOT accept self-asserted context claims from the agent. All environmental context (location, network posture, platform integrity) MUST be derived from independently verifiable sources: RATS Attestation Evidence RFC9334 from a hardware-rooted Attester, or corroborating signals from the SSF receiver. * Attestation Evidence Validation: The Verifier MUST validate RATS Evidence against manufacturer Endorsements and the SPIRE trust domain's Reference Values. Evidence that cannot be traced to a trusted Endorser MUST be rejected, and the CRS MUST be set to the Critical tier (S >= 0.7), triggering mandatory HITL escalation. * Coarse-Grained Context Defaults: To reduce the attack surface for context spoofing, context signals MUST be expressed at the coarsest granularity sufficient for the authorization decision. Implementations MUST use categorical labels (e.g., "corporate", "in-transit", "public") rather than precise measurements (e.g., GPS coordinates) unless the requested scope explicitly demands higher precision. This reduces the number of forgeable dimensions available to an attacker. * Context Freshness: The Verifier MUST reject Attestation Evidence older than the deployment-configured freshness threshold. Stale evidence MAY indicate that an attacker captured a legitimate attestation from a trusted environment and is replaying it from an untrusted one. 4.3. Proof-of-Possession Binding Bearer tokens are insufficient for agentic authorization because they can be used by any party that obtains them. CAAM requires that all JIT Scoped Tokens be sender-constrained. The CAAM sidecar MUST implement the DPoP mechanism RFC9449 as follows: 1. Key Generation: During ARDP registration, each agent's CAAM sidecar generates an asymmetric key pair. The private key MUST be stored in a non-exportable hardware-backed keystore (TPM 2.0, HSM, or Cloud KMS). The public key is published as part of the agent's ARDP Capability Block. 2. Token Binding: When the CAAM Vault synthesizes a JIT Scoped Token, it includes a "cnf" (confirmation) claim containing the "jkt" (JWK Thumbprint) of the agent's DPoP key: Barney, et al. Expires 28 August 2026 [Page 20] Internet-Draft CAAM February 2026 { "cnf": { "jkt": "sha256:0ZcOCORZNYy-..." } } 1. Proof Presentation: On every tool call, the agent MUST present a DPoP proof JWT alongside the JIT Scoped Token. The proof JWT is signed with the agent's private key and includes the HTTP method, target URI, and a fresh "jti" to prevent replay. 2. Verification: The Relying Party MUST verify that the DPoP proof JWT was signed by the key whose thumbprint matches the "jkt" in the token's "cnf" claim. If the proof is missing, expired, or signed by a different key, the token MUST be rejected. This binding ensures that a stolen JIT token cannot be used by an attacker who does not possess the agent's hardware-protected private key. 4.4. Prompt Injection as Privilege Escalation Prompt injection attacks are a primary threat to autonomous systems. CAAM treats prompt injection as a Semantic Elevation of Privilege attack. The CAAM sidecar MUST remain isolated from the agent's reasoning space (Out-of-Band Policy Enforcement). Even if an agent's internal state is compromised via prompt injection and it attempts an unauthorized action, the sidecar intercepts the resulting tool call. Because the sidecar's decision logic is deterministic and based on the externally verified SCO, it MUST block the action regardless of the agent's internal belief state. 4.5. Multi-Hop Identity Dilution In an N-hop chain (User -> Agent A -> Agent B -> Agent C), each hop introduces a new trust boundary. Traditional OAuth 2.0 tokens, if not managed with Scope Attenuation, can allow an agent at the end of the chain to inherit the full permissions of the original user without explicit intent. CAAM mitigates this by requiring that every token exchange include a "purpose" claim matching the original intent. The sidecar MUST verify that each sub-task was authorized in the original SCO. Combined with Scope Attenuation and Depth-Limited Tokens ("max_hops"), authority MUST degrade gracefully across hops rather than accumulating. Barney, et al. Expires 28 August 2026 [Page 21] Internet-Draft CAAM February 2026 4.6. Confused Deputy Prevention The Confused Deputy attack in agentic systems occurs when a malicious or compromised Agent A passes a crafted intent to a higher-privileged Agent B, tricking B into performing an action that A is not authorized to request. A related attack is token replay, where a captured JIT token is presented in a different environment or session context. CAAM prevents both attacks through Contextual Binding -- the cryptographic coupling of every JIT Scoped Token to the specific SCO, environment attestation, DPoP key, and nonce from which it was derived: * Environment Binding: The JIT token embeds a hash of the RATS Attestation Result that was current at synthesis time. If an attacker replays the token from a different environment, the Relying Party's Attestation Result will not match the embedded hash, and the token MUST be rejected. * Session Binding: The JIT token includes the SCO's "jti" (JWT ID) and "session_id". A token synthesized for Session X MUST NOT be accepted in Session Y. The sidecar MUST validate that the presented token's session binding matches the active Contextual Session. * Nonce Binding: Each JIT token is bound to a single-use cryptographic nonce. After the first use, the nonce is recorded in a replay cache. Any subsequent presentation of the same nonce MUST be rejected. * Sender Binding: The JIT token is bound to the agent's DPoP key via the "cnf"/"jkt" claim per dpop-binding. Even if Agent A obtains a token intended for Agent B, A cannot produce a valid DPoP proof because A does not possess B's private key. * Intent Binding: The JIT token carries the "purpose" and "sub_purpose" from the SCO. Agent B's sidecar MUST verify that the requested action falls within the stated purpose before executing. A crafted intent from Agent A that requests an out-of- scope action will fail this check even if Agent B has the technical capability to perform it. These five bindings are conjunctive: all MUST hold for a JIT token to be accepted. The failure of any single binding invalidates the token. Barney, et al. Expires 28 August 2026 [Page 22] Internet-Draft CAAM February 2026 4.7. Data-in-Use Protection (Future Work) While CAAM provides robust controls for data-at-rest and data-in- transit via access policies, the next frontier is protecting data-in- use during processing by the agent's LLM or inference engine. As technology matures, agent workloads MAY be executed within Confidential Computing environments (e.g., secure enclaves such as Intel SGX or AMD SEV). Executing the agent within a Trusted Execution Environment (TEE) protects the "Observation" and reasoning phases from inspection or tampering by a compromised host OS or hypervisor. This provides cryptographic assurance against active data leakage and some forms of prompt injection at the execution layer itself. Because deploying large, GPU-accelerated LLM workloads within secure enclaves is currently technically difficult, this is identified as an optional, future capability rather than a strict requirement for -00 implementations. 4.8. Policy and Knowledge Graph Integrity The security of the CAAM mesh relies entirely on the correctness of the authorization policy (e.g., OPA or Cedar) and the accuracy of the Knowledge Graph. Implementations MUST adopt a Zero Trust approach to policy lifecycle management. This approach SHOULD include: * Signed Policy Bundles: All policy updates MUST be cryptographically signed and verified by the sidecar before enforcement. * Verifiable Audit Trails: All mutations to the Knowledge Graph MUST be appended to a tamper- evident log. * Policy-as-Code Pipelines: Changes to the ruleset MUST pass through automated CI/CD pipelines with mandatory security reviews and conflict-detection tests to prevent the introduction of overly permissive rules. 4.9. Agent Supply Chain Security While RATS secures the agent's runtime environment, a comprehensive Zero Trust model MUST also scrutinize the agent's software provenance. Barney, et al. Expires 28 August 2026 [Page 23] Internet-Draft CAAM February 2026 The CAAM framework SHOULD be extended to verify the software supply chain of discovered agents. Before initiating the Post-Discovery Handshake, the sidecar MAY require the agent (or the ARDP Registrar) to provide a signed Software Bill of Materials (SBOM). The sidecar can then verify that the agent's components, including the specific LLM model weights and inference dependencies, contain no known critical vulnerabilities before allowing execution. 4.10. Formal Threat Model The following threats are specific to multi-agent orchestration. For each threat, the table identifies the attack vector, the primary CAAM mitigation, and the relevant section of this document. Barney, et al. Expires 28 August 2026 [Page 24] Internet-Draft CAAM February 2026 +===========+=============+================+========================+ |Threat |Vector | Mitigation | Ref | +===========+=============+================+========================+ |Token Theft|Runtime | DPoP+Vault+60s | token-theft | | |exfil | | | +-----------+-------------+----------------+------------------------+ |Context |Fake env | RATS+coarse | context-spoofing | |Spoof | | ctx | | +-----------+-------------+----------------+------------------------+ |Confused |Intent A->B | 5-way binding | confused-deputy | |Deputy | | | | +-----------+-------------+----------------+------------------------+ |Signal |Fake TEE/geo | TPM Evidence | context-spoofing | |Spoof | | | | +-----------+-------------+----------------+------------------------+ |Deleg Loop |Circular | max_hops+cycle | sco-definition | | |chain | | | +-----------+-------------+----------------+------------------------+ |Token |Captured JIT | Nonce+DPoP | dpop-binding | |Replay | | | | +-----------+-------------+----------------+------------------------+ |Infer |Cross-source | Firewall+DP | minimal-disclosure | |Bypass | | | | +-----------+-------------+----------------+------------------------+ |Prompt |Manipulated | OOB enforce | N/A | |Inject |LLM | | | +-----------+-------------+----------------+------------------------+ |Data-in-Use|Host OS/ | TEE (Future/ | data-in-use-protection | |Exfil |Hyper | Opt) | | +-----------+-------------+----------------+------------------------+ |Policy |Malicious | Signed Bundles | policy-integrity | |Tampering |Rules | | | +-----------+-------------+----------------+------------------------+ |Vulnerable |Compromised | Signed SBOM | supply-chain-security | |Agent |Dep | | | +-----------+-------------+----------------+------------------------+ Table 5 5. Privacy Considerations 5.1. Inference Isolation A unique challenge in agentic security is Fuzzy Search Leakage: an agent with authorized access to multiple datasets may combine them in its internal memory to draw unauthorized inferences. Barney, et al. Expires 28 August 2026 [Page 25] Internet-Draft CAAM February 2026 CAAM implements a Contextual Firewall that enforces isolation within the agent's reasoning context. If an agent retrieves data from Source A, the sidecar MUST restrict access to Source B for the duration of that sub-task if the combination is flagged as a high- risk inference vector in the Inference Boundary. 5.2. Minimal Disclosure Context Providers -- entities that supply environmental, behavioral, or relational signals to the CAAM mesh -- MUST adhere to the principle of Minimal Disclosure. 5.2.1. Coarse-Grained Context by Default All context signals MUST be expressed at the coarsest granularity sufficient for the authorization decision by default. The following table illustrates the REQUIRED default granularities: +==========+===========================+===============+ | Signal | Coarse (Default) | Fine (Opt-in) | +==========+===========================+===============+ | Location | "corporate" / "public" | Country code | +----------+---------------------------+---------------+ | Network | "trusted" / "untrusted" | CIDR block | +----------+---------------------------+---------------+ | Time | "business-hours" / "off" | ISO 8601 | +----------+---------------------------+---------------+ | Platform | "attested" / "unattested" | PCR values | +----------+---------------------------+---------------+ Table 6 A Context Provider MUST NOT disclose fine-grained context unless both of the following conditions are met: 1. The requested OAuth scope explicitly requires the finer granularity (e.g., a geofencing scope that specifies country- level). 2. The current CRS is in the Nominal tier (S < 0.3). At Elevated or Critical CRS, the Verifier MUST reject fine-grained context requests and fall back to coarse defaults to reduce the information surface. Barney, et al. Expires 28 August 2026 [Page 26] Internet-Draft CAAM February 2026 5.2.2. Additional Disclosure Constraints * The SCO's "ctx" claim MUST NOT carry raw sensor data, biometric measurements, or personally identifiable information (PII) unless the requested scope explicitly requires it and the CRS permits it. * Implementations SHOULD support selective disclosure mechanisms (e.g., SD-JWT) to enable verifiers to request only the claims they require from the SCO. * When RATS Evidence is included in the SCO, the Verifier SHOULD produce an Attestation Result that abstracts the raw Evidence into a trust score or categorical assessment, ensuring that detailed platform measurements are not propagated beyond the Verifier. * The CAAM mesh MUST NOT log or persist the full contents of the "ctx" claim beyond the lifetime of the Contextual Session. Implementations SHOULD retain only the CRS value and remediation tier for audit purposes. The principle of Minimal Disclosure ensures that the CAAM mesh does not itself become a vector for privacy leakage by aggregating and propagating more context than is necessary for each authorization decision. 6. IANA Considerations This section requests registration of claims, parameters, and a new registry with IANA. 6.1. JSON Web Token Claims Registration This specification defines one new claim for registration in the "JSON Web Token Claims" registry established by Section 10.1 of RFC7519. 6.1.1. Registry Contents Claim Name: ctx Claim Description: CAAM Contextual Assertion. A JSON object containing purpose, scope ceiling, delegation depth, consistency token, attestation result reference, and contextual risk score for agentic authorization decisions. Change Controller: IETF Specification Document(s): sco-definition of this document Barney, et al. Expires 28 August 2026 [Page 27] Internet-Draft CAAM February 2026 Claim Value Type: JSON object The "ctx" claim is used within the Session Context Object (SCO) defined in sco-definition. Its value is a JSON object with the following members: * "purpose" (string, REQUIRED): Human-readable intent of the agentic task. MUST NOT be modified by intermediate agents. * "scope_ceiling" (array of strings, REQUIRED): Maximum OAuth scope derived from the original delegation grant. * "max_hops" (integer, REQUIRED): Remaining delegation depth. Decremented by 1 at each hop. * "zookie" (string, OPTIONAL): Consistency token for Knowledge Graph queries. * "rats_result" (string, OPTIONAL): URI reference to the Verifier's Attestation Result per RFC9334. * "crs" (number, REQUIRED): Contextual Risk Score in the range [0, 1]. The following is a non-normative example of the "ctx" claim value: { "purpose": "Q4 revenue audit", "scope_ceiling": [ "finance:read", "crm:read" ], "max_hops": 3, "zookie": "zk_v1_998877", "rats_result": "https://verifier.corp.internal/abc", "crs": 0.22 } 6.2. OAuth Parameters Registration IANA is requested to register the following entry in the "OAuth Parameters" registry established by RFC 6749: Parameter Name: caam Parameter Usage Location: authorization request, token request Barney, et al. Expires 28 August 2026 [Page 28] Internet-Draft CAAM February 2026 Change Controller: IETF Specification Document(s): This document The "caam" parameter carries a reference to the Session Context Object that MUST be validated by the authorization server before issuing tokens in a CAAM-compliant deployment. 6.3. OAuth Token Introspection Response IANA is requested to register the following entry in the "OAuth Token Introspection Response" registry: Response Parameter: ctx Change Controller: IETF Specification Document(s): sco-definition of this document When a CAAM-compliant authorization server responds to an introspection request for a JIT Scoped Token, it SHOULD include the "ctx" claim to enable the Relying Party to perform contextual validation. 6.4. CAAM Agent Discovery Metadata Registry IANA is requested to create a new registry titled "CAAM Agent Discovery Security Metadata" under the "CAAM" registry group. 6.4.1. Registration Policy New entries require Specification Required per RFC 8126. 6.4.2. Initial Registry Contents +=====================+==================+=============+ | Attribute | Description | Req | +=====================+==================+=============+ | caam_v1_supported | CAAM support | REQUIRED | +---------------------+------------------+-------------+ | sc_object_hash | SCO hash | OPTIONAL | +---------------------+------------------+-------------+ | inf_boundary_v1 | Inference limits | RECOMMENDED | +---------------------+------------------+-------------+ | authz_policy_uri | Policy URI | REQUIRED | +---------------------+------------------+-------------+ | spiffe_trust_domain | Trust domain | REQUIRED | +---------------------+------------------+-------------+ Barney, et al. Expires 28 August 2026 [Page 29] Internet-Draft CAAM February 2026 | rats_evidence_type | Evidence type | RECOMMENDED | +---------------------+------------------+-------------+ | crs_threshold | Max CRS w/o MFA | OPTIONAL | +---------------------+------------------+-------------+ | max_delegation_hops | Max depth | RECOMMENDED | +---------------------+------------------+-------------+ | dpop_jwk_uri | DPoP public key | REQUIRED | +---------------------+------------------+-------------+ Table 7 6.4.3. ARDP Registry Extensions Additionally, this document requests the following new attributes for the ARDP registry defined by I-D.pioli-agent-discovery: * Policy Compliance Hash: A cryptographic hash of the agent's active policy set, allowing clients to verify governance. * Inference Boundary Declaration: A formal specification of the agent's semantic limits. * Trust Anchor Reference: A pointer to the authority responsible for the agent's identity and behavioral attestation. 7. References 7.1. Normative References [I-D.pioli-agent-discovery] Pioli, R., "Agent Registration and Discovery Protocol (ARDP)", 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . Barney, et al. Expires 28 August 2026 [Page 30] Internet-Draft CAAM February 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . [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, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . [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, . 7.2. Informative References [CEDAR] Amazon Web Services, "Cedar Policy Language", n.d., . [HEXA] "Hexa Policy Orchestrator", n.d., . [IPSIE] OpenID Foundation, "Interoperability Profiling for Secure Identity in the Enterprise", n.d., . [OPA] "Open Policy Agent", n.d., . [RFC9635] Richer, J., Ed. and F. Imbault, "Grant Negotiation and Authorization Protocol (GNAP)", RFC 9635, DOI 10.17487/RFC9635, October 2024, . [SPIFFE] "Secure Production Identity Framework for Everyone", n.d., . [ZANZIBAR] Pang, R. and R. Lanber, "Zanzibar: Google's Consistent, Global Authorization System", USENIX ATC 2019, 2019. Barney, et al. Expires 28 August 2026 [Page 31] Internet-Draft CAAM February 2026 Appendix A. Appendix A. Mathematical Models for Inference Isolation Let X be the agent's internal state, S_1 and S_2 be two data sources, and B be the inference boundary defined by policy. The sidecar ensures that for any inference I drawn by the agent: P(I | S_1, S_2, X) = P(I | Auth(S_1, S_2), X) Where the Auth function represents the set of permissible inferences under boundary B. If the combination is unauthorized, the sidecar applies a privacy-preserving transformation T such that the mutual information within the scratchpad is minimized: I(T(S_1); T(S_2)) <= epsilon Where epsilon is the privacy budget defined by enterprise policy. Appendix B. Acknowledgments The authors thank the IETF community and the contributors to the Agent Registration and Discovery Protocol for foundational work that informed this specification. Appendix C. Document History C.1. draft-barney-caam-00 * Initial submission. Authors' Addresses Jonathan M. Barney Independent United States of America Email: jonathan.barney@gmail.com URI: https://github.com/jmbarney5/Contextual-Agent-Authorization- Mesh Roberto Pioli Independent Italy Email: roberto.pioli@gmail.com URI: https://github.com/roberto-pioli/agent-registration-discovery Barney, et al. Expires 28 August 2026 [Page 32] Internet-Draft CAAM February 2026 Darron Watson Independent United States of America Email: drwatson0874@gmail.com Barney, et al. Expires 28 August 2026 [Page 33]