Contextual Agent Authorization Mesh (CAAM)

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

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

3.1. Architectural Foundations

CAAM leverages the existing maturity of identity provenance standards while extending them to meet agentic requirements.¶

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

{
  "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.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.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).¶

{
  "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.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:¶

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.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:¶

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:¶

• 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:¶

{
  "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.¶

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

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

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

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

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

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

{
  "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¶

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

7.1. Normative References

[I-D.pioli-agent-discovery]

Pioli, R., "Agent Registration and Discovery Protocol (ARDP)", 2026, <https://datatracker.ietf.org/doc/draft-pioli-agent-discovery/>.

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

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

[RFC8392]

Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.

[RFC8693]

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

[RFC9334]

Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://www.rfc-editor.org/rfc/rfc9334>.

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

7.2. Informative References

[CEDAR]

Amazon Web Services, "Cedar Policy Language", n.d., <https://www.cedarpolicy.com/>.

[HEXA]

"Hexa Policy Orchestrator", n.d., <https://github.com/hexa-org/policy-orchestrator>.

[IPSIE]

OpenID Foundation, "Interoperability Profiling for Secure Identity in the Enterprise", n.d., <https://openid.net/wg/ipsie/>.

[OPA]

"Open Policy Agent", n.d., <https://www.openpolicyagent.org/>.

[RFC9635]

Richer, J., Ed. and F. Imbault, "Grant Negotiation and Authorization Protocol (GNAP)", RFC 9635, DOI 10.17487/RFC9635, October 2024, <https://www.rfc-editor.org/rfc/rfc9635>.

[SPIFFE]

"Secure Production Identity Framework for Everyone", n.d., <https://spiffe.io/>.

[ZANZIBAR]

Pang, R. and R. Lanber, "Zanzibar: Google's Consistent, Global Authorization System", USENIX ATC 2019, 2019.

C.1. draft-barney-caam-00

• Initial submission.¶