Architecting Autonomous Agent Delegation: Identity, Authority, and Cryptographic Attenuation

Full report

On this page

The deployment of autonomous computational agents operating on behalf of human principals or organizational entities introduces profound challenges to traditional access control and identity management architectures. When an autonomous process is endowed with the capacity to initiate API calls, execute financial transactions, and hire subordinate agents, relying on static bearer tokens or ambient authority invariably exposes the ecosystem to critical vulnerabilities. The classic confused deputy problem, in which a privileged program is tricked by a less-privileged caller into misusing its authority, has re-emerged as a high-severity threat pattern in agentic deployments where credential delegation amplifies the impact of prompt injection1. To safely authorize an independent agent to perform work while retaining enforceable control, system architecture must abandon monolithic identity concepts in favor of highly granular, cryptographically verifiable, and strictly attenuated delegation chains. This analysis details the operational requirements for agentic authorization. It disaggregates the fundamental components of agent identity, compares leading delegation protocols across the cryptographic and ledger spectrums, and formalizes the requirements for monotonically attenuated capability grants. Furthermore, it clearly delineates stateless cryptographic authorization from stateful financial accounting and ledger reconciliation, providing an exhaustive framework for robust agent governance.

Disaggregating Identity and Authority in Autonomous Systems

Traditional authentication systems frequently conflate the human user, the software client, the cryptographic key, and the granted authority into a single session token. In autonomous agent topologies, this conflation breaks down fundamentally. Agents are non-deterministic, highly cloneable, and capable of operating asynchronously across multiple trust domains3. To establish enforceable control, the architecture must separate identity and authority into six distinct, independently verifiable layers. The public identity constitutes the globally resolvable identifier by which an entity is known to external counterparties3. This may manifest as a Decentralized Identifier (DID), an Ethereum Name Service (ENS) record, an X.509 Subject Alternative Name, or a SPIFFE Verifiable Identity Document (SVID) within a microservices architecture3. The public identity serves as the anchor for reputation, discovery, and routing. It allows relying parties to query the entity's standing or retrieve its public key material, but the identifier itself does not inherently prove possession or authorize action. Key possession represents the cryptographic proof that a specific runtime environment controls the private key associated with a public identity. This is demonstrated through digital signatures over challenges, payloads, or session handshakes, such as mutual TLS or JSON Web Signatures (JWS)3. Importantly, key possession is bound to the infrastructure or the hardware enclave, such as a Trusted Execution Environment, rather than the organizational owner4. Because an exfiltrated key proves possession to a verifier just as effectively as a legitimate key, robust systems require continuous rotation protocols that can deprecate a compromised key without destroying the overarching public identity or severing established trust relationships6. The operator identity refers to the ultimate legal or human principal responsible for the agent's actions, liabilities, and funding. A critical security invariant in agentic systems is understanding that separate registrations do not constitute proof of separate operators. The failure to distinguish between a registered agent incarnation and its controlling operator exposes the ecosystem to severe Sybil risks, wherein a single malicious actor can cheaply instantiate thousands of separate agent identities—each with unique keys and public identifiers—to manipulate governance, bypass rate limits, or fabricate reputation8. High-assurance networks must utilize Sybil-resistance mechanisms, such as staked bonds, verifiable credential proofs, or centralized Know Your Customer (KYC) compliance, to bind multiple agent incarnations back to a single operator identity10. The registration incarnation is the specific runtime instance or deployment of an agent. An operator might deploy a central procurement agent, but the underlying code may exist as multiple containerized instances scaling horizontally across a cluster. Each incarnation possesses its own ephemeral session keys and workload identity, often managed via orchestration tools like SPIRE3. The distinction between the operator and the registration incarnation allows a principal to revoke a single malfunctioning pod or container without revoking the overarching authority granted to the global agent identity12. Task authority dictates the precise boundaries of what the agent is permitted to execute logically. Unlike traditional access control lists that map permissions to an identity statically, task authority is dynamic, contextual, and securely bound to a specific mission or run13. This authority is carried in a cryptographically verifiable token that travels alongside the request14. Task authority defines the allowed actions, the target resources, and the acceptable counterparties, answering the question of whether the agent has the right to initiate a specific API or Model Context Protocol (MCP) call16. Payment authority is strictly decoupled from task authority. While task authority determines if an agent is allowed to execute a logical operation, payment authority determines whether the agent has access to the financial liquidity or metered quotas required to settle the resulting transaction17. Payment authority involves interactions with smart contract accounts, escrow ledgers, or fiat payment gateways, utilizing mechanisms such as spending limits, continuous allowances, or pre-funded sub-accounts18. An agent may possess the task authority to request a costly computation but lack the payment authority to clear the subsequent invoice.

Comparative Analysis of Delegation and Agent-Authorization Protocols

To facilitate the secure transfer of task and payment authority from an operator to an agent, and subsequently from an agent to a sub-agent, the industry has developed several distinct delegation protocols. These approaches range from symmetric bearer tokens to asymmetric capability chains and modular smart contracts, each exhibiting unique architectural trade-offs. Macaroons represent the foundational architecture for decentralized, offline capability attenuation20. They rely on symmetric cryptography, specifically chained Hash-based Message Authentication Codes (HMACs), to bind contextual caveats to a bearer token22. An authorization server issues a root Macaroon using a secret key. When the holder wishes to delegate this token, they append a new caveat, such as restricting the target resource or adding a strict expiration, and compute a new HMAC over the previous signature and the new caveat24. The primary advantage of Macaroons is their extreme computational efficiency and native support for monotonic attenuation without requiring a network round-trip to the issuer25. However, their reliance on a shared symmetric secret means that any entity capable of verifying the Macaroon is mathematically capable of forging one6. This characteristic renders Macaroons unsuitable for open, multi-domain agentic ecosystems where agents must prove their authority to untrusted third-party services that do not hold the root secret27. The Biscuit token format resolves the symmetric limitations of Macaroons by utilizing Ed25519 public-key cryptography and embedding authorization logic via Datalog, a declarative logic programming language14. A Biscuit token is constructed as an append-only sequence of cryptographic blocks14. The root issuer creates the initial block defining the baseline authority and facts29. A delegating agent can append subsequent blocks containing new Datalog checks, ensuring offline derivation14. Because Biscuits use asymmetric cryptography, any relying party possessing the public key can verify the entire delegation chain offline29. Furthermore, the Datalog engine evaluates all blocks collectively, guaranteeing that an appended block can only restrict, never expand, the authority granted in prior blocks6. This makes Biscuit an ideal primitive for multi-hop agent-to-agent delegation14. User-Controlled Authorization Networks (UCAN) provide a capability-based authorization system built entirely on Decentralized Identifiers and JSON Web Tokens (JWTs)14. In the UCAN model, delegation is represented by nesting JWTs, where a child token includes its parent token in a specific claim to form a verifiable lineage back to the root identity28. While UCAN benefits from widespread JWT library support, it suffers from significant token bloat6. A delegation chain of five hops results in a deeply nested, excessively large payload that can easily exceed standard HTTP header limits. Additionally, UCAN policies generally rely on flat string scopes rather than the expressive logic available in systems utilizing Datalog6. The enterprise standard for delegation relies heavily on the OAuth 2.0 framework, specifically Token Exchange (RFC 8693\) and Rich Authorization Requests (RFC 9396). RFC 8693 allows a client to exchange an existing token for a new one, carrying the context of the delegation in the actor and subject claims33. RFC 9396 allows clients to request fine-grained, structured JSON permissions, such as specific spending limits or transactional boundaries, via structured payload parameters15. While these OAuth approaches integrate seamlessly with existing enterprise identity providers, they inherently resist offline delegation. To execute a multi-hop delegation, each step typically requires contacting the central Authorization Server to execute a token exchange17. This creates a single point of failure and injects substantial latency overhead into high-velocity agentic workflows. Emerging drafts, such as the Secure Agent Delegation Protocol (SADP), attempt to solve this by defining hash-linked delegation chains over JWTs that enforce attenuation offline, thereby marrying the ubiquity of JSON Object Signing and Encryption with the offline capabilities of Biscuits36. The Grant Negotiation and Authorization Protocol (GNAP), standardized as RFC 9635, represents a paradigm shift from OAuth 2.0 by designing consent, identity, and access negotiation as a unified, interactive flow38. GNAP is particularly suited for autonomous agents because it separates the software client from the user identity more cleanly than OAuth, allowing an agent to negotiate its requested scopes, key bindings, and interaction modes directly with an Authorization Server before involving the human operator39. Nevertheless, similar to baseline OAuth, GNAP operates primarily as a centralized negotiation protocol rather than a format for offline, peer-to-peer capability propagation. For agentic tasks involving direct financial value and metered APIs, specialized payment protocols bridge the gap between capability tokens and ledgers. The L402 protocol combines the Lightning Network with the HTTP 402 Payment Required status code, creating a system for pay-per-request access utilizing Macaroons41. When a server requests payment, it generates a Lightning invoice and returns it alongside a Macaroon. Upon payment, the client receives a cryptographic preimage, which, combined with the Macaroon, serves as the credential unlocking the resource41. This enables agents to purchase subtasks across domain boundaries instantly and securely. At the smart contract layer, the Ethereum ecosystem provides highly structured on-chain delegation primitives that dictate how agents manage liquidity. ERC-7579 defines a standard for modular smart accounts, establishing consistent interfaces for validators, executors, and hooks18. Through this standard, an operator can install a session key validator alongside a spending limit hook. The validator limits which cryptographic key can sign operations, while the hook runs before and after transaction execution to enforce cumulative outflow limits, fundamentally preventing an agent from draining the account18. ERC-7715 bridges the off-chain application layer to these on-chain modules by introducing a standardized remote procedure call method that allows an agent to request a bounded scope from a user's wallet, producing a permission context that the agent can utilize without prompting the user for per-transaction signatures44. EIP-7702 extends smart account functionality to standard Externally Owned Accounts. It allows an account to temporarily delegate its execution logic to a smart contract by signing an authorization list46. This allows a human operator to endow their standard wallet with session keys, transaction batching, and sponsored gas mechanics temporarily, without migrating their assets to a new smart contract48. However, EIP-7702 introduces severe systemic risks. Because the account can invoke multiple calls per transaction, legacy protections relying on transaction origin checks are completely bypassed47. Furthermore, if a user is subjected to a phishing attack and signs a malicious delegation indicator, the attacker gains effectively permanent control over the account's execution flow until the delegation is actively revoked48.

Cryptographically Enforced Delegation Chains

To ensure that autonomous agents cannot exceed their intended parameters, misdirect tools due to prompt injection, or initiate unauthorized financial liabilities, the authorization architecture must utilize mathematically enforceable delegation chains. A fundamental security invariant in agentic systems is the concept of monotonic attenuation. Every child grant generated in a chain must be strictly narrower—or at most equal to—its parent grant6. An agent must never possess the logical capability to approve its own budget increase, escalate its access privileges, or alter the target constraints defined by the operator6. A secure capability grant must encapsulate an exhaustive set of constraints operating as a signed assertion. The grant is bound first to the actor, representing the cryptographic identity of the specific agent runtime authorized to wield the grant. By binding the grant to the actor's key through proof-of-possession mechanics, the architecture ensures that an intercepted token cannot be utilized by an adversary via a token passthrough attack15. Next, the grant identifies the principal, indicating the entity issuing the grant; in a multi-hop chain, the principal of the child grant must perfectly match the actor of the parent grant36. The grant must also contain a task or run identifier, tying the authority to a specific orchestration episode and preventing the cross-run reuse of authority12. The permitted actions form a highly scoped array of explicit operations the agent may perform, mapping directly to the capabilities of the Model Context Protocol or target APIs37. These actions are constrained by counterparties or capabilities, functioning as a strict allowlist of external endpoints, smart contract addresses, or downstream agent identities the actor is permitted to interact with. The use of wildcards must be expressly prohibited at this layer to mitigate Server-Side Request Forgery and generalized confused deputy attacks16. A hard cryptographic expiry defines the absolute temporal limit of the authority, while a cumulative spending ceiling indicates the maximum financial value the agent may authorize or transfer across the entire lifespan of the grant15. The enforcement of monotonic attenuation relies heavily on structural validation by the relying party. In systems like the Secure Agent Delegation Protocol, the chain is constructed such that each new grant is hashed alongside the exact signature of its parent to generate a parent grant hash36. This hash-linking explicitly commits the child to one specific signed parent instance, preventing splicing attacks where a malicious actor attempts to graft a valid child grant onto a different, broader parent grant containing identical fields36. When a verifier evaluates the chain, it must independently confirm that every numerical constraint, such as spending limits and maximum delegation depth, has decreased or remained static, and that no new actions or counterparties have been added to the arrays36. In logic-based protocols, this evaluation is native. If the initial block defines a budget ceiling of one thousand units, and the subsequent block defines a ceiling of two hundred units, the Datalog engine evaluates the logical intersection of all facts. If the agent attempts an expenditure of five hundred units, the second block evaluates to false, rendering the entire cryptographic token invalid14. Because the cryptographic signature over the token prevents the removal of prior blocks, the agent remains mathematically constrained by the most restrictive set of caveats present in the chain25.

Distinguishing Authorization from Financial Accounting

A pervasive architectural anti-pattern in distributed agent design is the conflation of cryptographic authorization with actual ledger accounting. Authorization logic—the evaluation of Datalog queries, JSON Web Token signatures, or OAuth scopes—answers a purely qualitative question regarding whether an agent currently possesses the legal right to request an expenditure. However, authorization tokens are fundamentally stateless relative to execution outcomes. They cannot reliably answer the quantitative question of whether the agent has already exhausted its budget across concurrent, asynchronous operations distributed across a network. If an operator grants an agent a token with a maximum spending ceiling, the agent might simultaneously dispatch multiple asynchronous sub-tasks to different service providers, each utilizing a copy of the exact same valid token. If the service providers rely solely on the token's internal cryptographic claims, all providers will independently authorize the transaction, resulting in a massive double-spend vulnerability53. To mitigate this, the architecture must strictly separate the authorization verifier from the accounting reconciliation ledger. The capability token acts exclusively as an entry ticket; the actual enforcement of the cumulative spending ceiling requires a centralized or consensus-driven state machine engineered for high-throughput concurrency, such as TigerBeetle or similarly specialized financial databases55. Agentic financial operations must therefore be executed using a rigorous Two-Phase Commit or Saga-based distributed transaction protocol55. In the first phase, designated as the reservation or prepare phase, the agent presents its authorization token and a request to execute a subtask. The relying party contacts the accounting ledger. The ledger verifies the cryptographic token, evaluates the requested amount against the tracked remaining budget for that specific task identifier, and places a strict hold or temporary lease on those funds, reducing the available uncommitted balance59. In the second phase, corresponding to execution and settlement, the agent executes the task. If the provider accepts the quote and successfully completes the work, the ledger finalizes the transaction, converting the reserved funds into accrued fees and clearing the transfer to the payment provider59. Crucially, if the quote is stale, the provider fails to deliver, or the network times out during execution, the ledger executes a deterministic compensating transaction. This aborts the operation, releases the reservation, and returns the funds to the available budget pool, ensuring that failed operations do not permanently penalize the agent's spending ceiling58. This strict demarcation ensures that outstanding reservations, accepted quotes, and accrued fees correctly impact the remaining authority dynamically without requiring the continual re-issuance of the stateless authorization token. Furthermore, payment-provider approval—the actual movement of fiat or cryptocurrency over external rails—occurs strictly downstream of the accounting reconciliation63. A payment may fail due to network congestion or liquidity constraints even if the agent possesses the cryptographically valid authority and the ledger successfully established the reservation. Therefore, the system must support asynchronous refunds and state rollbacks driven by reconciliation jobs reading from the ledger's immutable audit trail58.

The Grant and Authority Lifecycle

The management of agent authority represents a continuous lifecycle requiring robust state transition mechanics. The formal lifecycle of an agentic grant encompasses initial setup, concurrent execution, rotation, re-registration, and ultimately, expiration or emergency revocation. The lifecycle begins with setup and issuance. The human principal or orchestrating system authenticates to an Identity Provider or Smart Contract, defining the operational parameters, authorized counterparties, and the cumulative spending ceiling. The principal's system mints the root grant and transmits it to the primary agent6. Following issuance, the agent enters the phase of concurrent commitments and active work. The agent receives tasks and spawns multiple execution threads to handle sub-components of the workload. For each thread, the agent generates a strictly narrower child grant, reducing the scope and budget to match the specific subtask36. The sub-agent or tool connector initiates the two-phase commit reservation process against the accounting ledger, locking in the required liquidity before executing the API call59. To formalize agreements between independent agents, frameworks like the PACT (Propose, Agree, Complete, Trust) protocol generate a Verifiable Task Contract, binding the exact task specifications to the cryptographic authority before any value is transferred66. Upon successful delivery, a Succession Receipt is minted, proving the legitimate transfer of authority and obligation from one agent to another, providing a cryptographically sound audit trail68. Because agent keys may be ephemeral or face continuous exposure risks in hostile environments, agents must frequently rotate key material. In decentralized identity systems, key rotation is executed by publishing a new valid key to the agent's decentralized identifier document or an identity registry, accompanied by overlapping validity windows to prevent downtime6. A re-registration updates the public registry to reflect the new cryptographic bindings but does not alter the historical cryptographic validity of previously settled capability chains, ensuring that completed work remains verifiable7. Grants naturally conclude through expiry and exhaustion. Temporal expiry occurs when the strict cryptographic timestamp embedded in the token passes, rendering the signature invalid for future operations18. Financial exhaustion occurs when the accounting ledger records that the cumulative spending ceiling has been reached18. Once expired or exhausted, the ledger categorically rejects all new reservation attempts, though it is architected to gracefully clear pending settlement commitments that were legitimately reserved prior to the expiration event. In scenarios where an agent behaves maliciously or is compromised—such as falling victim to a prompt injection attack that turns it into a confused deputy—the operator must execute an emergency shutdown. Because offline, decentralized tokens cannot be forcibly recalled from the network, the architecture must implement a highly efficient revocation mechanism. This is optimally achieved using the W3C Bitstring Status List standard71. The operator toggles a specific bit corresponding to the grant's unique index in a highly compressed, centrally hosted or ledger-anchored bitstring71. When any relying party or gateway receives the token, they fetch or reference the lightweight bitstring; if the bit is flagged, the grant is immediately rejected. Crucially, revoking a parent grant inherently cascades through the hierarchy, mathematically invalidating the entire subtree of downstream delegation chains and halting all subordinate agent activity instantly7.

Authority Matrix

The following matrix delineates the distinct properties, mechanisms, and strict constraints associated with each functional layer of the agent identity and authorization stack.

Operational Scenarios

The theoretical architecture manifests securely in practical deployment through the separation of identity layers, the enforcement of monotonic attenuation, and the utilization of ledger-backed accounting. In the scenario of a human-owned worker, a financial analyst functioning as the operator identity wishes to deploy a data-scraping agent to purchase market reports from premium APIs over a dedicated twenty-four-hour period. The operator utilizes an EIP-7702 transaction to temporarily delegate their standard Externally Owned Account to a smart contract implementation featuring an ERC-7579 spending limit hook46. Concurrently, the operator generates an Attenuating Authorization Token that strictly limits the agent to read-only operations directed solely at a predefined array of vendor domains37. The agent operates autonomously, authenticating with its own ephemeral session keys mapped to its workload identity. It never possesses the human's root credentials, and its maximum financial damage is mathematically capped by the on-chain hook, regardless of whether the agent experiences a hallucination or logic failure. In a scenario involving an agent purchasing a subtask, an autonomous logistics agent determines it lacks the regional weather data necessary to calculate shipping routes and decides to hire an independent weather-forecasting agent. This interaction utilizes the PACT framework66. The logistics agent acts as the principal for this specific delegation. It mints a child Biscuit token, transferring a highly attenuated subset of its own authority: restricting the action exclusively to a weather query, reducing the maximum delegation depth counter, and allocating a strict budget drawn from its own ledger reservation6. The two agents co-sign a Verifiable Task Contract67. The weather agent executes the query, delivers the data, and presents the child token to the accounting ledger. The ledger reconciles the charge using a two-phase commit, settling the payment and generating an immutable Succession Receipt that proves the transfer of authority and obligation without requiring human intervention68. Consider a scenario where authority is revoked during active work. During a complex code refactoring task, a software engineering agent encounters a poisoned dataset containing a malicious prompt injection. The injection attempts a confused deputy attack, instructing the agent to exfiltrate proprietary source code to an unapproved external server2. The system's anomaly detection engine identifies the anomalous outbound request and triggers an emergency shutdown. The monitoring system updates the W3C Bitstring Status List, flipping the revocation bit corresponding to the agent's root task authority72. Simultaneously, the agent has an outstanding, perfectly valid compute reservation locked in the ledger for a legitimate compiling subtask. Because the authorization token is now invalid due to the bitstring update, the cloud provider's attempt to settle the charge during the execution phase fails the token validation check. The accounting ledger automatically aborts the transaction, releasing the reservation back to the operator's central budget, preventing financial loss despite the active attack.

Security Testing and Invariant Validation

To ensure the resilience of the agent authorization architecture, implementations must be subjected to a rigorous validation framework targeting the specific seams between stateless cryptography and stateful accounting ledgers. A test for concurrent budget use evaluates the double-spend protection mechanism. An agent is issued a capability token with a fixed ceiling. The test orchestrates ten concurrent threads, each simultaneously requesting a maximum-value transaction from the provider using the exact same token. The architecture passes if the first thread succeeds in securing a reservation, while the remaining nine threads fail instantly at the accounting ledger due to insufficient uncommitted funds, proving the efficacy of the two-phase commit model against distributed double-spending53. A test for stale approvals evaluates temporal bounds and ledger state reclamation. An agent receives a quote for a subtask that is cryptographically valid for sixty seconds. The agent artificially delays execution and attempts to commit the transaction at the sixty-five-second mark. The architecture passes if the payment gateway rejects the execution phase, and the accounting ledger subsequently recognizes the failure, executes a compensating transaction, and refunds the reservation to the agent's available balance to prevent permanent locking of liquidity63. A test for replay after recovery targets idempotency. An agent submits a perfectly valid operation, but the receiving server crashes immediately after processing it, prior to issuing an acknowledgment. Upon recovery, the agent attempts to resubmit the exact same token and payload. The architecture passes if the receiver’s idempotency controls, utilizing uniquely hashed action parameters tied to a specific nonce, successfully identify the duplication, safely returning the cached success state without initiating a secondary ledger deduction54. A test for cross-run reuse verifies contextual boundaries. An agent completes a successful data extraction run under a specific run identifier. Subsequently, a malicious process extracts the JWT token from the log files and attempts to use it to initiate a new extraction under a different run identifier. The architecture passes if the target API rejects the request, demonstrating that the cryptographic token is strictly bound to the original context constraint, effectively preventing contextual lateral movement. Finally, a test for the attempted inheritance of old authority validates the integrity of the hash-linked delegation chain. An operator delegates a grant to a primary agent, which then creates a child grant for a sub-agent. Later, the operator revokes the primary agent's grant. The sub-agent subsequently attempts to craft a new sub-grant for a tertiary agent, pointing to the original, unmodified fields of the primary agent's pre-revocation state. The architecture passes if the validation fails immediately; the parent grant hash requires the tertiary agent's token to securely commit to the exact signature of the sub-agent36. When the verifier traverses the chain back to the root, the status list check successfully identifies the primary agent's revocation, causing the entire downstream inheritance chain to fail securely7.

Works cited

1. The Confused Deputy Problem in AI Agents: Why MCP and Tool, https://cyber0946.tistory.com/152

2. Confused Deputy Attacks on Autonomous AI Agents, https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-agent-confused-deputy-prompt-injection/

3. Executive Summary \- arXiv, https://arxiv.org/html/2604.23280v1

4. draft-ietf-wimse-workload-identity-bcp-01 \- Best Current Practice for, https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-identity-bcp/01/

5. draft-drake-agent-identity-problem-statement-00 \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-drake-agent-identity-problem-statement/

6. Agent Identity Protocol for Verifiable Delegation Across MCP and A2A, https://arxiv.org/html/2603.24775v1

7. NostrAgent: A Decentralized Identity and Delegation Architecture for, https://arxiv.org/html/2609.22944v1

8. What Is Sybil Risk? Definition & Examples, https://nhimg.org/glossary/sybil-risk/

9. CanDID: Can-Do Decentralized Identity with Legacy Compatibility, https://berkeley-defi.github.io/assets/material/CanDID.pdf

10. Topology \- Yutha, https://yutha.ai/concepts/topology/

11. Blockchain-Based Solution for Privacy-Preserving SIM Card ... \- MDPI, https://www.mdpi.com/2624-800X/6/1/30

12. Authenticating Non-Human Reasoners: Why Agents Are Not Service, https://clawrxiv.org/papers/2026.00022

13. Client Context and ID-JAG for Mission-Bound OAuth, https://notes.karlmcguinness.com/notes/client-context-and-id-jag-for-mission-bound-oauth/

14. Agent Identity Protocol for Verifiable Delegation Across MCP and A2A, https://arxiv.org/pdf/2603.24775

15. OAuth for Agents — Delegated Purchase Authority, Spending Limits, https://aitidalwave.com/agentmall\_spoke\_oauth

16. Understanding Model Context Protocol Security (MCP) in 2026 | Wiz, https://www.wiz.io/academy/ai-security/model-context-protocol-security

17. Agent Token Exchange With RFC 8693 \- JP Casabianca, https://jpcasabianca.com/journal/agent-token-exchange-rfc-8693/

18. ERC-7579: The Modular Smart Account Standard, Explained | Support, https://eco.com/support/en/articles/11890018-erc-7579-the-modular-smart-account-standard-explained

19. Smart Wallet Security Best Practices for 2026 \- Openfort, https://www.openfort.io/blog/smart-wallet-security-best-practices

20. Cryptographic Security of Macaroon Authorization Credentials, https://cs.nyu.edu/media/publications/TR2013-962.pdf

21. Macaroons: Cookies with Contextual Caveats for Decentralized, https://research.google.com/pubs/pub41892.html?source=post\_page---------------------------

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

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

24. Experiments with codecaps and macaroons in NDN.JS, https://named-data.net/wp-content/uploads/2016/11/ndncomm2014\_pdelasherasquiros.pdf

25. Capability-Based Delegation of Privileges in Multi-Agent Systems, https://arxiv.org/html/2609.06500v1

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

27. biscuit-based identity and authorization I'm working on https://www, https://news.ycombinator.com/item?id=45421614

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

29. Specifications \- Eclipse Biscuit, https://doc.biscuitsec.org/reference/specifications.html

30. Rust implementation of the Biscuit authorization token · GitHub, https://github.com/eclipse-biscuit/biscuit-rust

31. HDP v0.1 Specification, IETF draft-02, Human Delegation ... \- Helixar, https://helixar.ai/about/labs/hdp/

32. draft-atakora-wimse-sadp-delegation-01 \- Capability-Bound, https://datatracker.ietf.org/doc/draft-atakora-wimse-sadp-delegation/

33. AI agents and the multi-hop delegation problem \- WorkOS, https://workos.com/blog/oauth-multi-hop-delegation-ai-agents

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

35. Security Deep Dive — API Keys, JWT, OAuth Scopes, MCP Threats, https://aitidalwave.com/agentmall\_spoke\_security

36. draft-atakora-wimse-sadp-delegation-01 \- IETF Datatracker, https://datatracker.ietf.org/doc/html/draft-atakora-wimse-sadp-delegation-01

37. draft-niyikiza-oauth-attenuating-agent-tokens-00 \- IETF Datatracker, https://datatracker.ietf.org/doc/html/draft-niyikiza-oauth-attenuating-agent-tokens-00

38. Authorization Receipts for High-Risk Agent Actions \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-schrock-ep-authorization-receipts/13/

39. Full specification · OCP 0.4 · Open Continuity Protocol, https://opencontinuity.org/specification/0.4/full/

40. Identity, Authorization, and Trust in Agentic LLM Systems: A Survey, https://www.researchgate.net/publication/401447176\_Identity\_Authorization\_and\_Trust\_in\_Agentic\_LLM\_Systems\_A\_Survey\_of\_the\_Agent-as-Principal\_Security\_Paradigm

41. Introduction to L402: Lightning-Powered Payment Protocol for AI, https://www.nervos.org/knowledge-base/introduction\_to\_l402

42. PASETO, Macaroons, Opaque Tokens, and Server-Side Sessions, https://rmrf.tips/en/posts/jwt-alternatives/

43. AI Agent Payments with L402 Protocol \- KuCoin, https://www.kucoin.com/news/articles/ai-agent-payment-paradigm-how-lightning-labs-l402-protocol-reshapes-bitcoin-lightning-network-ecosystem

44. ERC-7715 Explained: Wallet Permissions, Sessions, and ... \- Eco, https://eco.com/support/en/articles/11953354-erc-7715-explained-wallet-permissions-sessions-and-subscriptions

45. What Is ERC-7715? Smart Wallet Permissions Explained | Support, https://eco.com/support/en/articles/10714103-what-is-erc-7715-smart-wallet-permissions-explained

46. EIP-7702 \- Binance, https://www.binance.com/en/academy/glossary/eip-7702

47. EIP-7702: Set Code for EOAs, https://eip.tools/eip/7702

48. EIP-7702 Explained: Account Abstraction for EOAs | Support \- Eco, https://eco.com/support/en/articles/14796249-eip-7702-explained-account-abstraction-for-eoas

49. account-abstraction — Infrastructure | CryptoSkills, https://cryptoskills.dev/skills/account-abstraction

50. EIP-7702 and MEV in 2026: Smart Accounts as Target and Shield, https://hoge.gg/eip-7702-mev-front-running-smart-accounts-2026/

51. We tried to save a wallet from an EIP-7702 drain. Even the Rabby, https://avaprotocol.org/blog/eip-7702-rescue-gasaccount-swept

52. The Proof Pair — an open working spec for provable delegation · v0, https://the-aios.org/proof-pair

53. Concurrency « Shahzad Bhatti, https://weblog.plexobject.com/archives/category/concurrency

54. 10 Essential AI Prompts to Empower Your Financial Services Tech, https://kartaca.com/en/10-essential-ai-prompts-to-empower-your-financial-services-tech-team/

55. TigerBeetle: High-Performance Financial Database for OLTP, https://alexandrubagu.github.io/blog/tigerbeetle-financial-database.html

56. TigerBeetle, https://tigerbeetle.com/

57. Transactions in a Microservice World \- WSO2, https://wso2.com/whitepapers/transactions-in-a-microservice-world/

58. The Problem with Distributed Transactions | System Design, https://algomaster.io/learn/system-design/distributed-transactions-problems

59. Build a Bridge | Minka Docs, https://docs.minka.io/ledger/connecting-systems/build-a-bridge/

60. OpenAI Software Engineer Interview Prep Guide \- PracHub, https://prachub.com/interview-prep/W2CPK-aYUZeu

61. google/cybernetic-agent-governance-engine \- GitHub, https://github.com/google/cybernetic-agent-governance-engine

62. Robust, Scalable and Efficient System for Confidential Token, https://blogs.oracle.com/blockchain/robust-scalable-and-efficient-system-for-confidential-tokenized-transactions-oracles-breakthrough-on-hyperledger-fabric

63. We Replaced One Database Transaction With Five Microservices, https://medium.com/javarevisited/we-replaced-one-database-transaction-with-five-microservices-then-we-had-to-redesign-consistency-5449c3c50ad7

64. Glossary of Terms \- Finery Markets, https://finerymarkets.com/glossary/

65. Real-Time Payment Processing \- Ververica, https://www.ververica.com/banking/real-time-payments

66. PACT, the Missing Layer 4 of the Agentic Web \- Laxmikant Sharma, https://laxsharma.com/writing/when-agents-hire-agents-pact/

67. PACT: Co-Signed Task Contracts, Delivery and Verdict Records, https://datatracker.ietf.org/doc/draft-laxsharma-pact/02/

68. Succession Receipts: Portable Signed Evidence of Authority ... \- IETF, https://www.ietf.org/archive/id/draft-sabey-succession-receipts-05.html

69. draft-sabey-succession-receipts-05 \- IETF Datatracker, https://datatracker.ietf.org/doc/html/draft-sabey-succession-receipts-05

70. What is ERC-8004? The Ethereum Standard Enabling Trustless AI, https://eco.com/support/en/articles/13221214-what-is-erc-8004-the-ethereum-standard-enabling-trustless-ai-agents

71. Transparent Identity Verification Approach Using MPC and Efficient, https://arxiv.org/html/2609.14195v1

72. W3C VC 2.0 Is Now a Standard \- What Developers Need to Know, https://blockeden.xyz/forum/t/w3c-vc-2-0-is-now-a-standard-what-developers-need-to-know/335

73. NostrAgent: A Decentralized Identity and Delegation Architecture for, https://arxiv.org/pdf/2609.22944