Identity, Trust, and Delegated Authority in Autonomous Machine-to-Machine Systems

Full report

On this page

The Transformation of Autonomous Security Architectures

The evolution of computing from human-mediated operations to autonomous machine-to-machine (MATM) systems presents a fundamental fracture in traditional security paradigms. Conventional enterprise security architectures are intrinsically designed to govern fixed boundaries. In these legacy environments, the protected surface is typically data at rest or data in transit, and the corresponding controls—such as Access Control Lists (ACLs), data-loss prevention algorithms, and perimeter inspections—govern the explicit crossings of those static boundaries1. However, the introduction of autonomous software agents entirely dissolves this assumption. When a software agent is empowered to read context, negotiate with other agents, dynamically call remote tools, and modify the durable systems of record on behalf of an enterprise or human user, the operational risk migrates directly into the workflow itself2. This shift reveals the critical inadequacy of Access Control Lists. Since the era of the Multics operating system, ACLs have served as the predominant model for digital authorization, mapping subjects directly to permitted operations on a centralized resource1. In a highly dynamic MATM environment, maintaining an exhaustive, centralized matrix of every potential agent interaction permutation induces a crippling maintenance burden and creates a severe vector for "confused deputy" attacks1. A confused deputy attack occurs when a privileged agent is deceived into misusing its ambient authority by processing malicious, untrusted input—such as an instruction embedded in a parsed document that commands the agent to delete files or exfiltrate data3. Because traditional systems authenticate the agent's identity rather than validating the intent of the specific task, the malicious action is permitted4. To secure autonomous intelligence systems, architectural designs must invert the relationship between resources and users. Rather than relying on a centralized Authorization Server to mediate all relationships and persistently track ACLs, the authority must be pushed to the edge via cryptographic, capability-based delegation1. In this paradigm, agents discover capabilities, communicate, and coordinate useful work utilizing decentralized tokens that encapsulate precise, attenuated permissions6. This research report provides an exhaustive investigation into identity and authorization strategies for autonomous agents, delineating established practices from emerging proposals, and establishing a robust framework for MATM delegation without routine manual approval.

Deconstructing the MATM Trust Spectrum

Architecting a MATM ecosystem requires deconstructing the monolithic concept of "security" into independent, composable primitives. When system designers conflate identity with authorization, they inadvertently create fragile architectures where proving who an agent is automatically grants it the right to determine what it can do.

Workload Identity and Authentication

Identity establishes the namespace and intrinsic properties of an actor, completely independent of its permissions. In modern distributed systems, identity is formalized through frameworks like the Secure Production Identity Framework For Everyone (SPIFFE)8. SPIFFE defines an identity namespace utilizing the SPIFFE ID, formatted as a Uniform Resource Identifier (URI) encompassing a strictly defined trust domain and an optional path component (e.g., spiffe://example.org/billing/agent)9. A trust domain serves as an administratively isolated security boundary, ensuring that identity collisions do not occur across heterogeneous environments11. Authentication is the cryptographic mechanism through which an endpoint proves possession of this identity. The SPIFFE Verifiable Identity Document (SVID) acts as the operational passport, encapsulating the SPIFFE ID within a cryptographically signed document9. Authentication guarantees certainty regarding the origin of a request, but it inherently makes no assertions regarding the privileges associated with that origin.

Authorization and Delegation

Authorization evaluates whether an authenticated identity possesses the necessary rights to execute a specific action on a designated resource. While coarse-grained authorization might simply allow "read access," autonomous MATM systems require high-fidelity constraints. The Internet Engineering Task Force (IETF) standardized OAuth 2.0 Rich Authorization Requests (RAR) in May 2023 under RFC 9396 to address this requirement13. RAR provides a structured JSON mechanism allowing clients to specify detailed authorization requirements, including specific data types, transaction limits, and execution locations13. Delegation extends authorization by allowing a principal to transfer a bounded subset of its authority to another software agent. True delegation must be verifiable offline, chainable across multiple agents, and subject to cryptographic attenuation6. When a primary agent delegates a sub-task to a secondary agent, the secondary agent must present a cryptographic chain of custody demonstrating that its localized authority traces back to the original resource owner without exceeding the explicitly approved scope1.

Reputation and Evidence of Capability

Identity and delegation govern access, but reputation and capability evidence dictate vendor selection during the agent discovery phase. Reputation involves the continuous calculation of trust based on historical interactions. Evidence of capability involves verifiable credentials that prove an agent's operational competence or compliance posture16. Recent Internet-Drafts propose mechanisms for an Authorization Server to attest to a user's public key certificate directly within an OAuth Access Token, allowing Resource Servers to verify application-layer delegation evidence seamlessly15. This ensures that prior to exchanging capabilities, agents can mathematically prove their operational legitimacy.

Established and Proposed Credential Frameworks

Implementing a decentralized capability-based system requires synthesizing multiple credential formats, as no single technology satisfies identity, message integrity, and offline delegation simultaneously. The MATM security landscape encompasses established standards, active drafts, and evolving proposals.

Workload Identity Substrates (SPIFFE/SPIRE)

The SPIFFE standard and its reference implementation, SPIRE, establish the bedrock for workload identity8. SPIFFE relies on local node attestation to deliver short-lived SVIDs to processes dynamically, explicitly avoiding the injection of long-lived, static secrets into configurations10. The X.509-SVID format is the most established practice for securing point-to-point communications18. Designed for establishing mutual TLS (mTLS) channels, an X.509-SVID embeds the SPIFFE ID as a URI type in the Subject Alternative Name (SAN) extension18. The specification strictly dictates that an X.509-SVID must contain exactly one URI SAN to eliminate the authorization logic complexities and auditing challenges associated with multi-identity certificates18. For Layer 7 interactions where mTLS terminates at a load balancer, the JWT-SVID format is utilized20. JWT-SVIDs utilize JSON Web Signature (JWS) Compact Serialization and enforce strict limitations on algorithmic agility20. By explicitly restricting the alg header to approved values (such as RS256 or ES256) and forbidding the none algorithm, the specification effectively neutralizes historical downgrade attacks common in early JOSE implementations20. An experimentally supported proposal within the SPIFFE community is the Workload Identity Token (WIT-SVID)21. Traditional JWT-SVIDs are bearer tokens; if intercepted, they can be replayed. The WIT-SVID proposal introduces a Proof-of-Possession (PoP) model where the token contains a public key, and the corresponding private key is held securely by the workload itself21. This enables cryptographic binding of service calls to their specific sender, though it introduces computational overhead by requiring workloads to generate keys at runtime21.

Symmetric and Asymmetric Capability Tokens

To eliminate centralized bottlenecks during inter-agent delegation, systems utilize capability tokens that embed constraints directly into the credential. Macaroons represent a foundational, symmetric approach to capability tokens, introduced in a 2014 NDSS research paper7. A Macaroon utilizes a construction based on nested, chained HMACs7. When a target service issues a root Macaroon, the holder can derive a restricted credential by appending a "caveat" (for instance, restricting the target path or stipulating a time boundary) and hashing it with the previous signature23. The critical limitation of Macaroons is their reliance on symmetric cryptography; only the target service possessing the root secret can recompute the HMAC chain to verify the token, meaning independent third-party agents cannot validate the credential offline23. Biscuit tokens evolve this paradigm by transitioning to asymmetric, public-key cryptography and integrating an embedded Datalog policy language26. In a Biscuit token, attenuation is achieved by appending Datalog facts and rules. Because Biscuit utilizes public-key cryptography, any agent or service holding the issuer's public key can verify the token's integrity and evaluate the Datalog constraints offline26. The specification is actively maturing, with full support for version 3.0 across multiple language implementations (Rust, Java, Go) and experimental support for features like third-party blocks26. User-Controlled Authorization Networks (UCAN) provide a comprehensive, local-first schema relying on Public Key Infrastructure (PKI) and Decentralized Identifiers (DIDs)1. UCANs encapsulate batched capabilities, hierarchical authority, expiration times (exp), and "not before" assertions (nbf) into a verifiable container6. By supporting Proof Sets and Proof Chains as delineated in the W3C Credentials Community Group ZCAP-LD specification, UCANs allow an unbroken, cryptographically verified chain of custody that scales seamlessly across disconnected MATM networks1.

Short-Lived Tokens and Proof of Possession

In scenarios requiring continuous internet connectivity and centralized adjudication, OAuth 2.0 Token Exchange (RFC 8693\) permits an agent to present an existing token to an Authorization Server to receive a newly minted, downstream token27. To prevent Authorization Servers from silently dropping sender-constraint bindings (such as mTLS bindings) during the exchange, recent IETF drafts propose a cnf (confirmation) response parameter, allowing the client to cryptographically verify the binding without inspecting opaque tokens30. Additionally, OAuth 2.0 Demonstrating Proof-of-Possession (DPoP, RFC 9449\) binds access tokens to a client's private key, ensuring that if a secondary agent intercepts a token, it cannot utilize it without also stealing the corresponding asymmetric key31.

Application-Layer Message Integrity

Protecting the capability token in transit is insufficient if the message payload itself can be manipulated by untrusted intermediaries. Mutual TLS (mTLS) authenticates the connection, but it provides no protection once the TLS connection terminates at a proxy or API gateway33. Published as a Proposed Standard in February 2024, HTTP Message Signatures (RFC 9421\) defines a vendor-neutral protocol for signing arbitrary components of an HTTP exchange33. To construct a signature, an agent selects specific "covered components"—such as derived components (@method, @target-uri, @authority) and specific headers—and builds a canonical signature base string33. This string is signed using the agent's private key, and the output is transmitted in the Signature and Signature-Input headers33. Crucially, RFC 9421 does not sign the payload directly; instead, it relies on RFC 9530 (Digest Fields) to generate a SHA-256 hash of the payload in the Content-Digest header, which is then included in the signature base33. This mathematically binds the specific request payload and routing instructions to the agent's identity, completely preventing signature wrapping and substitution attacks34.

Dynamic Authority Lifecycle Management

Autonomous orchestration demands precise management of how authority narrows across hops, how cryptographic states rotate without disrupting operations, and how systems distinguish authenticated principals from untrusted messages claiming ambient authority.

Bootstrapping and Cross-Organization Trust

True autonomy scales across corporate boundaries, necessitating a mechanism for agents to discover and trust foreign cryptographic roots. The SPIFFE Federation specification solves this by defining a standardized protocol for exposing a "bundle endpoint"11. A SPIFFE bundle is a resource containing the public key material necessary to authenticate credentials from a specific trust domain11. To prevent synchronization failures, the spiffe\_sequence parameter ensures bundle updates are processed in a monotonically increasing order, preventing replay of deprecated key states12. Furthermore, the spiffe\_refresh\_hint governs how aggressively foreign agents poll for updates12. When Domain A rotates its signing keys, it publishes the updated trust bundle 3 to 5 times the refresh hint in advance of utilizing the new keys for SVID issuance11. This ensures that when an agent from Domain A presents a token to an agent in Domain B, Domain B has already asynchronously retrieved and cached the necessary public key to validate it offline11. Similarly, for HTTP Message Signatures, IETF drafts propose standardized Key Directories formatted as JSON Web Key Sets (JWKS) served at well-known URIs, allowing verifiers to dynamically discover active keys communicated via a Signature-Agent HTTP header36.

Cryptographic Attenuation

When tasks are delegated between agents, authority must be strictly narrowed to enforce the principle of least privilege. In MATM systems utilizing UCAN or Biscuit tokens, attenuation is a localized, offline mathematical operation1. If a Data Aggregation Agent possesses a capability token allowing read and write access to a database, and it delegates a sub-task to a specialized Worker Agent, it must narrow the scope. The primary agent executes a deterministic procedure to append new caveats (e.g., restricting operations exclusively to "read", and reducing the token's validity from 24 hours to 15 minutes)2. The token's previous signature is integrated into the calculation of the new signature. Consequently, when the Worker Agent presents the token to the Resource Server, the Resource Server verifies the cryptographic chain of custody, ensuring that the restrictions were legitimately applied by the holder of the parent token1. This forecloses privilege escalation without requiring a network call to the original Authorization Server7.

Distinguishing Authenticated Principals from Untrusted Intent

The fundamental defense against the Confused Deputy problem relies on isolating a principal's identity from the intent of an external message3. Secure MATM frameworks must implement capability-based authorization utilizing strict deny-by-default semantics. The Secure Model Context Protocol (SMCP) explicitly addresses this by confining agent operations within cryptographically signed "Security Scopes"3. A Security Scope contains an explicit array of capabilities defining permitted tool patterns, path allowlists, and specific operational boundaries3. Crucially, an optional deny\_list takes precedence over all other capabilities3. If an agent receives an untrusted prompt injection commanding it to delete local files, the underlying transport gateway evaluates the proposed action against the Security Scope3. Because the agent's capability token does not explicitly authorize file deletion, the gateway drops the request before it ever reaches the execution layer, neutralizing the attack regardless of the agent's authenticated identity3.

Expiry, Revocation, and Status Registries

The ephemeral nature of MATM workflows dictates that capability tokens should default to the shortest possible lifetimes. However, explicit revocation remains a necessity for neutralizing compromised delegates prior to token expiration. Because capability tokens are evaluated offline, standard OAuth introspection endpoints are bypassed. Systems must instead rely on distributed Token Status Lists or revocation registries37. As documented in IETF drafts, when a capability is actively revoked, the system registers the specific token's Content Identifier (CID) in a highly compressed lattice data structure or status list37. Participating Resource Servers continuously synchronize this list39. Revocation is structurally irreversible; if a parent UCAN is found on the revocation list, the validator deterministically rejects it and logically invalidates all downstream derivatives in the delegation chain residing in its local cache38. Furthermore, to tie authority directly to external events, proposed extensions to OAuth RAR introduce a lifecycle\_binding parameter, enabling the validity of an authorization grant to be linked to the state of an automated task41. The moment the task completes, the associated permissions are automatically revoked, collapsing the vulnerability window41.

Analysis of Authorization Strategies

The following table provides a rigorous comparison of the predominant credential and authorization approaches within the MATM ecosystem, detailing the structural tradeoffs and optimal application environments.

Recommended Design: The Delegated Capability Mesh

The following section transitions from objective evidence analysis to the synthesized architectural recommendations specifically requested by the research prompt. To support bounded autonomous work, explicit resource scoping, and deterministic denial without relying on routine manual approval, MATM infrastructures must adopt the Delegated Capability Mesh. This model explicitly separates network transport logic from intent adjudication. The communication infrastructure itself does not perform reasoning; it acts purely as a strict cryptographic enforcement engine that drops requests lacking valid structural proofs. The Delegated Capability Mesh unifies three distinct pillars:

1. Identity: SPIFFE X.509-SVIDs authenticate all underlying point-to-point network connections.

2. Capability: UCAN or Biscuit tokens provide decentralized, asymmetric, and heavily attenuated delegation chains, encoding the explicit intent.

3. Integrity: HTTP Message Signatures (RFC 9421), coupled with Content-Digest (RFC 9530), bind the execution payload securely to the authenticated agent's private key.

In this model, human intervention is isolated exclusively to the genesis of the workflow. An Authorization Server utilizes an OAuth 2.0 Rich Authorization Request (RAR) structured against the OpenID AuthZEN profile to capture the human's maximum defined constraints13. The AS mints the root capability token. From that point forward, agents execute capability discovery, attenuation, and delegation entirely peer-to-peer.

Concrete Multi-Step Delegation Example

Context: A human user authorizes a primary Orchestrator Agent (Agent Alpha) to process a complex financial reconciliation task spanning multiple domains. Agent Alpha determines it requires raw logs from a remote database and delegates this sub-task to a specialized Query Agent (Agent Beta). Step 1: Human Bootstrapping (Root Issuance) The human authenticates to the AS and approves an AuthZEN-profiled RAR requesting access to the corporate\_finance scope for a maximum of 4 hours13. The AS issues a root UCAN to Agent Alpha.

• State Transition: Agent Alpha acquires UCAN\_Root.
• Token Bounds: resource: "finance\_db", actions: \["read", "write"\], exp: T+4h.

Step 2: Offline Attenuation and Peer-to-Peer Delegation Agent Alpha negotiates with Agent Beta. Alpha recognizes that Beta only needs "read" access to the "European" region tables for a span of 10 minutes. Agent Alpha executes a local capability attenuation routine, hashing UCAN\_Root with the new restrictions to create a derived capability token.

• State Transition: UCAN\_Derived \= Attenuate(UCAN\_Root, caveats=\["region=EU", "action=read", "exp=T+10m"\]).
• Agent Alpha transmits UCAN\_Derived to Agent Beta over an mTLS channel authenticated via their respective SPIFFE IDs. No central server is consulted.

Step 3: Agent Execution and Deterministic Denial Agent Beta formats the execution request to the Resource Server (RS). To prevent token theft, Beta signs the HTTP request using its own private key, securing the HTTP method, the target URI, the payload digest, and the UCAN token itself33.

HTTP POST /api/finance\_db/eu\_logs/query HTTP/1.1 Host: db.example.com Content-Type: application/json Content-Digest: sha-256=:X48E9qOoAK...: Authorization: Bearer \<UCAN\_Derived\> Signature-Input: sig1=("@method" "@target-uri" "content-digest" "authorization");created=1725816419;keyid="agentBeta\_pub" Signature: sig1=:base64\_signature\_bytes:

• Interface Representation (RFC 9421 Format):

• Verification: The communication infrastructure at the RS executes a sequence of deterministic verification steps:

1. Calculates the payload hash and matches it to Content-Digest, verifying body integrity33.
2. Verifies the HTTP signature against Agent Beta's public key (found via the Key Directory), proving Beta constructed the exact request33.
3. Evaluates the UCAN\_Derived cryptographic chain, tracing the Datalog/caveats up to the root AS public key, mathematically proving the authority was legitimately delegated and the constraints (EU region, read-only, 10-minute expiry) are met1.
4. Consults the local Token Status List replica to ensure no segment of the UCAN chain has been revoked37.

If any cryptographic check fails, the gateway drops the request with a deterministically generated denial.

Applicability to Diverse MATM Systems

The Delegated Capability Mesh is architecture-agnostic. In drone swarm networks, where nodes experience frequent network partitions, the offline attenuation capability ensures that a lead drone can securely delegate survey tasks to trailing drones without requiring satellite uplink to an AS2. In high-frequency trading networks, the decoupling of the payload integrity (RFC 9421\) from the capability logic ensures that specialized hardware load balancers can rapidly verify signatures without needing to parse complex JSON authorization policies33.

Explicit Human and Organizational Prerequisites

This design eliminates human intervention during routine operation, but relies heavily on upfront organizational engineering:

1. Trust Root Provisioning: Administrators must deploy the underlying PKI (e.g., SPIRE servers) and map the initial Decentralized Identifiers (DIDs) to physical or legal entities to bootstrap trust1.

2. Maximum Bounding Policy Definition: Security teams must define the declarative AuthZEN policies at the Policy Decision Points (PDPs) that map human-readable business rules to the maximum permissible capabilities an AS can issue3.

3. Remediation Logic Orchestration: To manage scenarios where an agent is legitimately denied due to insufficient capabilities, the system must deploy HTTP metadata remediation (authorization\_remediation). This allows the agent to parse the exact delta in required capabilities and construct a precise follow-up request to a human operator, drastically reducing alert fatigue44.

Prioritized Feature Proposals for Implementation

To operationalize the Delegated Capability Mesh, engineering teams must prioritize the development of three core features.

Proposal 1: Cryptographic Capability Attenuation Engine

Problem: Currently, agents frequently share raw bearer tokens (such as standard OAuth JWTs) when delegating tasks. If an agent delegates this static token to a sub-agent, the sub-agent receives the entirety of the primary agent's access, violating the principle of least privilege and creating catastrophic vulnerabilities in the event of sub-agent compromise. Agent-Visible Behavior: When initiating a sub-task, an agent invokes a local SDK method (e.g., attenuate(root\_token, constraints)) to instantly mint a mathematically restricted token locally, without making any network calls to an Authorization Server. Expected Benefit: Strictly bounds the blast radius of downstream agents; provides granular, cryptographic proof of the delegator's intent; completely eliminates the necessity for continuous AS polling during dynamic delegation. Dependencies: Requires the integration of UCAN or Biscuit token specifications and the local deployment of an execution engine capable of evaluating Datalog or nested caveats (e.g., a WebAssembly-based parser)6. Implementation Effort: High. Requires significant refactoring of the Authorization middleware across all Resource Servers to parse, validate, and execute hierarchical capability chains rather than performing simple token introspection queries. Principal Failure Modes: Malformed constraints could unintentionally grant broader access if the parser is designed to "fail open"; the computational overhead of resolving extremely deep, multi-hop delegation chains could induce unacceptable latency spikes at the resource server.

Proposal 2: Application-Layer Message Integrity Envelopes

Problem: Relying exclusively on transport-layer security (mTLS) protects data in transit, but leaves payloads vulnerable once decrypted at intermediate API gateways or proxy meshes. An attacker compromising an intermediary could extract a capability token and substitute a malicious payload. Agent-Visible Behavior: The agent's HTTP client automatically computes a canonical base string of the request line (e.g., @method, @target-uri), specific operational headers, and the payload digest. It signs this sequence with its localized private key, attaching the output via Signature and Signature-Input headers prior to transmission33. Expected Benefit: Guarantees absolute non-repudiation. The Resource Server can mathematically prove that the execution instructions were constructed exclusively by the specific agent possessing the capability token, foreclosing token replay and substitution attacks33. Dependencies: Integration of RFC 9421 and RFC 9530 compliant libraries; deployment of public Key Directories (JWKS) to allow dynamic discovery of agent public keys34. Implementation Effort: Medium. Requires updating edge HTTP interceptors, establishing robust caching mechanisms for nonce tracking to prevent replay attacks, and managing the lifecycle of signing keys33. Principal Failure Modes: Canonicalization fragility, where intermediate benign proxies reorder headers or modify whitespace, causing the signature validation to fail; clock drift between independent agents resulting in premature signature expiration rejections.

Proposal 3: Decentralized Revocation via Status Registries

Problem: Because capability tokens like UCANs are verified entirely offline by the resource server, they bypass standard introspection endpoints. If an agent is compromised, it could theoretically wield its delegated authority maliciously until the token's natural expiration. Agent-Visible Behavior: Upon detecting anomalous behavior, an overseeing agent or monitoring system issues a signed revocation event identifying the token's CID to a distributed registry. Downstream Resource Servers continuously poll and synchronize this lightweight data structure into memory37. Expected Benefit: Enables near-instantaneous invalidation of specific delegation sub-trees without forcing the resource server to perform a database lookup for every individual API call38. Dependencies: Infrastructure capable of hosting highly available status list documents (such as IETF OAuth status lists) and a robust synchronization protocol (e.g., a peer-to-peer gossip network or edge-optimized object storage)39. Implementation Effort: Medium to High. Demands the design of an eventual-consistency replication mechanism that does not overwhelm edge computing nodes with massive revocation data payloads. Principal Failure Modes: Severe network partitions preventing the rapid synchronization of the status list, potentially leading to a "fail-open" scenario where revoked capability tokens are temporarily honored; unbounded growth of the status list eventually exhausting the local memory of edge gateways.

Practical Adoption Sequence and Future Outlook

Transitioning an active MATM architecture to the Delegated Capability Mesh must follow a phased adoption sequence to minimize operational disruption while compounding security guarantees.

1. Phase 1: Substrate Identity and Network Segmentation: The organization must first deploy a framework like SPIRE to issue X.509-SVIDs to all participating nodes and software agents8. By implementing rigorous mTLS across all internal communication paths, the enterprise establishes verifiable network identity and encrypts all transit, satisfying foundational compliance standards such as NIST SP 800-204A18.

2. Phase 2: Message Integrity and Sender Constraints: Introduce application-layer signing. Implement HTTP Message Signatures (RFC 9421\) strictly on highly critical API endpoints to guarantee that payloads and routing headers cannot be manipulated by intermediaries33. Concurrently, begin enforcing Proof-of-Possession mechanisms (such as DPoP) to bind existing bearer tokens to the authenticated sender31.

3. Phase 3: Capability Delegation and Offline Verification: Transition the architecture away from centralized OAuth scopes and toward UCAN or Biscuit capability tokens6. Mandate a core architectural rule: any agent initiating a sub-task must attenuate its capability token prior to transmission2. Deploy Token Status Lists to edge Resource Servers to manage decentralized revocation efficiently37.

4. Phase 4: Federation and Semantic Remediation: Establish SPIFFE Federation to securely bridge trust domains, enabling cross-organizational agent collaboration11. Finally, implement OAuth RAR Error Remediation (authorization\_remediation). When agents encounter denial errors, they can automatically parse the structured metadata, compute the precise authorization deficit, and seamlessly request localized human approval only for the exact delta in capability, thereby preserving security while drastically reducing human alert fatigue44.

Unresolved Questions for Future Implementers

As autonomous agent ecosystems rapidly scale, several structural challenges remain unresolved for future specification authors and implementers:

• Extreme-Scale Revocation Management: How can token status lists maintain microsecond lookup performance when an ecosystem scales to billions of ephemeral micro-tasks per hour? Future implementers must explore highly optimized probabilistic data structures (e.g., compressed Bloom filters) tuned for minimal false positive rates to manage lattice bloat.
• Quantum Resistance in Capability Tokens: Both Biscuit and UCAN rely heavily on standard asymmetric cryptography (e.g., Ed25519)6. A viable transition path to Post-Quantum Cryptography (PQC) algorithms must be designed before agent networks become deeply entrenched, particularly considering the token size bloat associated with PQC signatures.
• Semantic Ambiguity in Natural Language Constraints: When capability constraints rely on natural language interpretations (e.g., an LLM prompt stating "Summarize only non-confidential data"), deterministic cryptographic engines struggle to guarantee adherence. Bridging the gap between strict Datalog execution and probabilistic semantic evaluation remains an open research vector.

Measurable Success Criteria

Future implementers should objectively evaluate the health and security of the deployment against the following empirical criteria:

• Adjudication Latency: Offline authorization checks executed at the Resource Server—including capability chain validation, Datalog parsing, and signature verification—must consistently execute in under 5 milliseconds (p95 percentile), demonstrating successful independence from centralized AS bottlenecks.
• Attenuation Compliance: Routine audits must demonstrate that 100% of capability tokens received by secondary and tertiary sub-agents contain mathematically narrower scopes or shorter lifespans than their originating root tokens.
• Revocation Propagation Speed: The temporal window between a capability revocation event being registered and the most remote edge resource server successfully denying the associated token must remain under 3 seconds globally.
• Human Interruption Reduction: Through the utilization of explicit initial bounding and metadata-driven remediation, the volume of manual approval prompts presented to human operators should decrease by \>85% relative to legacy, non-delegating systems, without exhibiting any corresponding increase in unauthorized access incidents.

Works cited

1. User Controlled Authorization Network (UCAN) Specification, https://ucan.xyz/specification/

2. Macaroons: Cookies with Contextual Caveats for Decentralized, https://www.researchgate.net/publication/269196979\_Macaroons\_Cookies\_with\_Contextual\_Caveats\_for\_Decentralized\_Authorization\_in\_the\_Cloud

3. \[RFC\] Secure Model Context Protocol (SMCP) v1.0 \#689 \- GitHub, https://github.com/orgs/modelcontextprotocol/discussions/689

4. Authorization Propagation in Multi-Agent AI Systems \- arXiv, https://arxiv.org/pdf/2605.05440

5. A Standard Extension for LLM-Based Agent Identity and Authorization, https://www.researchgate.net/publication/396049358\_OpenID\_Connect\_for\_Agents\_OIDC-A\_10\_A\_Standard\_Extension\_for\_LLM-Based\_Agent\_Identity\_and\_Authorization

6. Getting Started with UCAN, https://ucan.xyz/guides/getting-started/

7. Macaroons: Cookies with Contextual Caveats for Decentralized, https://www.ndss-symposium.org/ndss2014/ndss-2014-programme/macaroons-cookies-contextual-caveats-decentralized-authorization-cloud/

8. The SPIFFE Project \- GitHub, https://github.com/spiffe/spiffe

9. spiffe/standards/SPIFFE-ID.md at main \- GitHub, https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE-ID.md

10. spiffe/standards/SPIFFE.md at main \- GitHub, https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE.md

11. spiffe/standards/SPIFFE\_Federation.md at main \- GitHub, https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE\_Federation.md

12. spiffe/standards/SPIFFE\_Trust\_Domain\_and\_Bundle.md at main, https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE\_Trust\_Domain\_and\_Bundle.md

13. RFC 9396 \- OAuth 2.0 Rich Authorization Requests \- IETF Datatracker, https://datatracker.ietf.org/doc/rfc9396/

14. draft-ietf-oauth-rar-03, https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-03

15. draft-chu-oauth-as-attested-user-cert-00 \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-chu-oauth-as-attested-user-cert/

16. Data Integrity 1.0 \- W3C, https://www.w3.org/community/reports/credentials/CG-FINAL-data-integrity-20220722/

17. spiffe/standards/SPIFFE\_Workload\_API.md at main \- GitHub, https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE\_Workload\_API.md

18. spiffe/standards/X509-SVID.md at main \- GitHub, https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md

19. Clarify the "one SPIFFE ID is allowed per certificate" rules \#32 \- GitHub, https://github.com/spiffe/spiffe/issues/32

20. spiffe/standards/JWT-SVID.md at main \- GitHub, https://github.com/spiffe/spiffe/blob/main/standards/JWT-SVID.md

21. Support for WIMSE WITs · Issue \#315 · spiffe/spiffe \- GitHub, https://github.com/spiffe/spiffe/issues/315

22. spiffe/standards/workloadapi.proto at main \- GitHub, https://github.com/spiffe/spiffe/blob/main/standards/workloadapi.proto

23. Macaroons: Cookies with Contextual Caveats for Decentralized, https://www.ndss-symposium.org/wp-content/uploads/2017/09/04\_3\_1.pdf

24. Macaroons: Cookies with Contextual Caveats for Decentralized, https://research.google/pubs/macaroons-cookies-with-contextual-caveats-for-decentralized-authorization-in-the-cloud/

25. Macaroons (computer science) \- Wikipedia, https://en.wikipedia.org/wiki/Macaroons\_(computer\_science)

26. Biscuit authentication/authorization token \- GitHub, https://github.com/biscuit-auth/biscuit

27. RFC 8693 OAuth 2.0 Token Exchange \- Takahiko Kawasaki \- Medium, https://darutk.medium.com/token-exchange-b40814d57a15

28. RFC 8693 \- OAuth 2.0 Token Exchange \- IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc8693

29. RFC 8693 OAuth 2.0 Token Exchange \- Authlete Documentation, https://developers.authlete.com/protocols-and-flows/advanced-flows/oauth-2-0-token-exchange-rfc-8693

30. draft-mcguinness-oauth-token-exchange-cnf-00 \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-mcguinness-oauth-token-exchange-cnf/

31. DPoP Nonce | by Takahiko Kawasaki \- Medium, https://darutk.medium.com/dpop-nonce-9787b9d276d1

32. Demonstrating Proof of Possession (DPoP) \- Thales Docs, https://www.thalesdocs.com/oip/idaas-core/idaas-core-access/oidc/dpop/index.html

33. Understanding HTTP Message Signatures \- Blog Notes, https://blog.vitalvas.com/post/2025/12/12/understanding-http-message-signatures/

34. RFC 9421 HTTP Message Signatures for Webhooks \- InstaWebhook, https://instawebhook.com/blog/rfc-9421-and-the-future-of-webhook-signatures-what-s-actually-changing

35. An implementation of RFC 9421, HTTP Message Signatures \- GitHub, https://github.com/pyauth/http-message-signatures

36. HTTP Message Signatures Directory \- IETF, https://www.ietf.org/archive/id/draft-meunier-http-message-signatures-directory-00.html

37. UCAN Tokens for AI Agents: Scoped Authority Explained | Covia Labs, https://covia.ai/blog/ucan-tokens-scoped-authority-ai-agents

38. User Controlled Authorization Network (UCAN) Specification · GitHub, https://github.com/ucan-wg/spec

39. Verifiable Attenuated Delegation for AI Agent Chains \- IETF, https://www.ietf.org/archive/id/draft-asor-wimse-agent-delegation-chain-01.html

40. Delegation registries — Agentic Surfaces, https://agenticsurfaces.org/library/pattern/delegation-registries/

41. draft-chen-oauth-rar-agent-extensions-00 \- IETF Datatracker, https://datatracker.ietf.org/doc/html/draft-chen-oauth-rar-agent-extensions-00

42. Define administrative and default SVID ordering · Issue \#156 \- GitHub, https://github.com/spiffe/spiffe/issues/156

43. SP 800-204A, Building Secure Microservices-based Applications, https://csrc.nist.gov/pubs/sp/800/204/a/final

44. OAuth 2.0 RAR Metadata and Error Remediation \- IETF Datatracker, https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-metadata-remediation-00

45. AuthZEN Request/Response Profile for OAuth 2.0 Rich ... \- IETF, https://www.ietf.org/archive/id/draft-brossard-oauth-rar-authzen-00.html

46. OAuth 2.0 RAR Metadata and Error Remediation \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-ietf-oauth-rar-metadata-remediation/

47. Building Secure Microservices-based Applications Using Service, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204A.pdf