Source-linked AI summary
Crypto-bound identity-verified capability tokens for coordinating distributed AI agents: A proposal
Srikumar Subramanian, Shubhashis Sengupta
TL;DR
Transactional agents face prompt-injection exposure that can compromise credentials and constraints. The paper proposes decentralized identity and attenuating capability tokens, with a secure module keeping credentials outside the LLM context. It presents this as a scalable approach to managing agent access, while noting that the proposal cannot cover the full breadth of implementation-dependent attacks.
Problem
Prompt injection and other attacks on agents can expose credentials or alter constraints, compromising transactions.
Source: THREAT MODEL · p. 5Method
The proposal combines decentralized identity with cryptographically bound capability tokens whose delegation chains can be checked for scope attenuation.
Source: PROPOSAL OUTLINE · p. 2, THE COLUMN VIEW: CAPABILITY TOKENS · p. 3Results
The paper presents identity-verified tokens with constraints that only attenuate across delegations as a scalable approach to managing access for agents acting on users’ behalf.
Source: CONCLUSION · p. 8Takeaways & Limitations
A secure software module holding credentials can keep private keys outside LLM context windows, making credential exfiltration through those windows impossible by construction.
Source: THE COLUMN VIEW: CAPABILITY TOKENS · p. 3The proposal cannot generally cover the full breadth of attacks on protected assets because implementations may vary.
Source: THREAT MODEL · p. 5
Abstract
from arXiv · showhide
The prospect of fully autonomous transactional agents did not appear on the horizon until the advent of high capability language models. With such models, the operational benefits of adaptive task orchestration and independent (but constrained) decision making are tantalizing for enterprises and individuals alike. However, each such agent carries with it a serious attack surface in the form of prompt injection which can compromise any soft "guard rails" that may have been placed in context. The consequences of these attacks include credential ex-filtration which, if left unmitigated, renders the whole category of such agents unusable due to breach of trust. Furthermore, expecting a growth of autonomous agents, a security framework for them would require a form of decentralization to scale. Drawing on the proposed OAuth Agent Authorization Profile and the W3C DID and VC standards, we propose a framework based on the principles of capability based security with decentralized agent identity whereby agents access services based on tokens that are cryptographically bound to the agent's and issuer's identities and specify their scope. Services can validate that the delegation chain only involves scope attenuation before acting on any given token. We show that such a layer that lives outside the language model's context window in a secure module can enable agents to act within enforceable security boundaries.
INTRODUCTION
The introduction frames agents as acting for humans across service providers while preserving privacy about users’ goals. It motivates capability tokens over access-control lists for open systems with ephemeral agents.
INTRODUCTION
- Agents are defined as programs acting on behalf of humans, directly or transitively.Services may not know a user's final goal, and withholding that intent is presented as preferable for privacy.Source: INTRODUCTION · p. 1
- Withholding users’ full intent from service providers is presented as a privacy benefit of using agents.The text notes that providers knowing intent could bias transactions or create future risks.Source: INTRODUCTION · p. 1
- Capability tokens are favored over ACLs for open systems with potentially ephemeral agents.The paper anticipates prolific and potentially ephemeral agent use.Source: INTRODUCTION · p. 1
RELATED WORK
Related work spans agent identity and authorization proposals using decentralized identity, verifiable credentials, and capability models. The paper positions its proposal among standards efforts and industry protocols.
RELATED WORK
- The OAuth Agent Profile draft describes agent authorizations as signed JWT capability tokens with constraints and grant-trail information.DID and VC proposals are also cited as ways to enable agent identity and.Source: RELATED WORK · p. 1
- BBS+ credential subsets support selective information sharing and unlinkable verifiable presentations.The W3C AI agent protocol draft addresses agent handshakes.Source: RELATED WORK · p. 2
- Other cited proposals address verifiable agent naming, federated identity management, and OAuth-based agent authorization,,.AWS, Microsoft, Google, and DigiCert are also noted as proposing agent identity or authorization approaches,,,.Source: RELATED WORK · p. 2
PROPOSAL OUTLINE
The proposal combines W3C DID and VC standards with a capability-token model whose delegations are strictly limited and attenuated. It outlines a holiday-planning scenario and discusses architecture, message exchanges, and token revocation.
PROPOSAL OUTLINE
- The proposed protocol combines W3C DID and VC standards with OAuth-draft-like capability tokens and strictly attenuated, limited delegation.The paper argues centralized agent identity management cannot be expected to scale.Source: PROPOSAL OUTLINE · p. 2
- The paper uses a holiday-planning scenario involving specialized agents to illustrate the protocol.The planned sections describe the architecture and message exchanges in that scenario.Source: PROPOSAL OUTLINE · p. 2
- The outline includes discussion of open design questions about token revocation.It first compares capabilities with ACLs for AI agents.Source: PROPOSAL OUTLINE · p. 2
IDENTITIES AND ACCESS CONTROL
The section treats agent access as requiring both reliable identity and resource-specific authority. It contrasts per-resource ACLs with capabilities, which the paper presents as easier to scale and delegate in open systems.
Identities
- An agent’s simplest identity is a public-private key pair whose association with the agent is attested by a trusted party’s digital signature.The text notes that letting a service validate this association without calling a trusted party is non-trivial.Source: Identities · p. 2
- A DID document is a JSON structure encoding identity information, while trust in its directory partly transfers to the identity-to-agent association.The agent demonstrates control by possessing the private keys associated with the identifier.Source: Identities · p. 2
Access control
- Figure 1 contrasts ACLs organized by resource rows with capabilities organized by agent columns.The paper says the capability view is easier to scale, generalize, and delegate for open systems with potentially ephemeral agents.Source: Access control · p. 2, Figure 1 · p. 3
THE COLUMN VIEW: CAPABILITY TOKENS
Capability tokens let agents present signed, constrained grants that services can validate independently, including through delegated chains. Keeping credentials in a secure module can keep private keys outside the LLM context window.
THE COLUMN VIEW: CAPABILITY TOKENS
- A capability token is a signed JSON structure specifying the agent, grantor, target resource, and constraints on access.Services can validate the token and its constraints before acting; the bearer may also need to prove control of the named identity.Source: THE COLUMN VIEW: CAPABILITY TOKENS · p. 3
- Agents can prove control of a token-bound identity through a challenge-response signature, and must be reachable at secure URI endpoints.The verifier checks a random-string signature against the agent’s public key.Source: THE COLUMN VIEW: CAPABILITY TOKENS · p. 3
- Grant constraints can specify transaction purpose, budgets, read/write permissions, and delegation, while services independently validate identities and whether requests conform.Delegated grants form a chain that services check for attenuation rather than amplification of constraints.Source: THE COLUMN VIEW: CAPABILITY TOKENS · p. 3
- A secure software module holding credentials and keys can keep private keys out of LLM context windows and provide only encrypted, signed results through its interface.The proposal says this can make context-window credential exfiltration impossible by construction, potentially with hardware-backed security.Source: THE COLUMN VIEW: CAPABILITY TOKENS · p. 3
- Capability checks can gate tools as well as web services; file access, for example, can be restricted to a directory and its subdirectories.Tools must themselves use capability-aware system facilities.Source: Figure 2 · p. 3
- Whether a delegation satisfies attenuation constraints is domain-specific.Source: THE COLUMN VIEW: CAPABILITY TOKENS · p. 3
ILLUSTRATED EXAMPLE
The holiday-planning example divides a user’s trip among specialized agents coordinated by Atlas. Delegated permissions start with limited booking holds and change to spending authority only after user approval.
ILLUSTRATED EXAMPLE
- The user gives Atlas trip details and a USD 5000 budget; Atlas delegates flight searches and holds to Skyway with a reduced USD 1500 budget.Skyway presents suitable flights to Atlas for the user to choose from.Source: ILLUSTRATED EXAMPLE · p. 4
- Atlas assigns hotel, restaurant, and local-transport bookings to specialized agents, then presents their holds together for user approval.Source: ILLUSTRATED EXAMPLE · p. 4
- Before approval, agents may hold rooms or seats but cannot pay; after approval, Atlas revokes hold tokens and issues spending tokens with precise amounts.Source: ILLUSTRATED EXAMPLE · p. 4
- The user can abort by revoking Atlas’s capability, and booking services can deny requests when grants are revoked or delegation fails to attenuate constraints.Source: ILLUSTRATED EXAMPLE · p. 4
THREAT MODEL
The threat model focuses on protecting credentials and constrained transactions from prompt injection, token misuse, and other attacks. Its assumptions include trusted core services and identity control without a central issuer.
THREAT MODEL
- The proposal assumes humans and agents can prove control of DIDs without a central issuer, uses signed token chains without revocations, and keeps validity periods short.It also assumes the user trusts the core services accessed by agents.Source: THREAT MODEL · p. 5
- The proposal cannot cover the full breadth of attacks on identity, signing, and presentation keys because implementations vary; LLMs must not be able to guess token-signing secrets.Source: THREAT MODEL · p. 5
- The main attack surface considered is what enters LLM context windows, because secret exfiltration and constraint modification can compromise transaction security.The user’s token issuance and revocation service is also an attack surface, especially when accessed over the internet.Source: THREAT MODEL · p. 5
- Threats include stolen or replayed tokens, false DID claims, modified tokens or presentations, prompt injection, privilege alteration, and issuer denial.Attackers may also use profiling to learn information that could later support identity theft.Source: THREAT MODEL · p. 5
THE CREDENTIAL WALLET
A credential wallet reduces the risk of prompt-triggered credential theft by preventing agents from retrieving raw signed credentials. Its policies and implementation controls mitigate, but do not eliminate, the risk.
THE CREDENTIAL WALLET
- Long-lived capability tokens raise credential-exfiltration risk under prompt attacks, while the wallet pattern prevents agents from retrieving raw signed credentials and generating their own presentations.Source: THE CREDENTIAL WALLET · p. 5
- Wallet policies and careful implementation can substantially mitigate residual risks, but do not eliminate them.Source: THE CREDENTIAL WALLET · p. 5
- Recommended wallet controls include typed IPC in a separate process, a wallet-held HMAC secret, identical denial messages, and BBS-2023 proofs for unlinkability.Source: THE CREDENTIAL WALLET · p. 5
REVOKING CAPABILITY TOKENS
Revocation trades offline validation for short-notice invalidation, while alternative designs add latency or cryptographic complexity. The section outlines endpoint checks, short-lived tokens, parent-chain validation, and cryptographic accumulators as options.
REVOKING CAPABILITY TOKENS
- Offline-only validation makes token revocation extremely hard or even impossible; checking a validation endpoint enables short-notice revocation but adds network latency.The proposal considers that latency acceptable in most cases given the ubiquity of network access.Source: REVOKING CAPABILITY TOKENS · p. 5
- Short-lived tokens can become invalid after a revocation prevents refresh, but refreshing adds latency and works best when transactions finish quickly.The passage gives five minutes as an example token lifetime.Source: REVOKING CAPABILITY TOKENS · p. 6
- Parent-token references let a service validate the grant chain and support revocation at any subtree, with latency dependent on delegation depth.Source: REVOKING CAPABILITY TOKENS · p. 6
- A cryptographic accumulator lets validators check revocation using included witnesses and an epoch, but requires complex cryptography to manage.Source: REVOKING CAPABILITY TOKENS · p. 6
FLOW OF EVENTS
The flow uses a user-controlled wallet to bootstrap credentials and verifiers, present task-specific credentials to services, and manage capability tokens through booking. After user approval, hold tokens are replaced with short-lived booking tokens; payment execution remains the provider’s responsibility.
FLOW OF EVENTS
- At initialization, the user-controlled wallet prepares verifiers and credentials; agents can instruct it to communicate with parties but cannot exchange data with it directly.Source: FLOW OF EVENTS · p. 6, Figure 5 · p. 6
- For flight booking, the wallet presents membership and budget credentials to the flight verifier using BBS+ ZKPs, while agents handle discovery and travel requirements.Source: FLOW OF EVENTS · p. 7, Figure 6 · p. 7
- Hotel verification is delinked from flight verification and can present credentials establishing whether the stay is corporate or personal and who reimburses it.Source: FLOW OF EVENTS · p. 7, Figure 7 · p. 7
- After the user approves the confirmed trip resources, the initial hold tokens are revoked and replaced with short-lived book tokens.Source: FLOW OF EVENTS · p. 7, Figure 8 · p. 7
- Token creation, exchange, and revocation form a cryptographically verifiable audit trail, while final payment execution must be implemented by payment providers.The trail records decisions leading to payment; multiple agents can produce multiple linear-time threads.Source: FLOW OF EVENTS · pp. 7–8, Figure 9 · p. 8
- Agent discovery is outside the proposal’s scope; the text identifies malicious-agent injection into discovery as a potential attack surface.A discovery agent could filter agents by abilities using indexed API specifications, avoiding repeated LLM processing.Source: FLOW OF EVENTS · p. 8
CONCLUSION
The conclusion presents identity-verified, cryptographically bound capability tokens with attenuating constraints as a scalable way to manage ad hoc agents’ access. It points to DID, VC, OAuth-style authorization, and selective BBS-2023 credential sharing as parts of the approach.
CONCLUSION
- Identity-verified tokens with embedded constraints that only attenuate through delegation offer a scalable approach to managing ad hoc agents’ resource access.Source: CONCLUSION · p. 8
- The W3C DID and VC standards and the OAuth agent authorization draft provide a standards path for these techniques.Source: CONCLUSION · p. 8
- BBS-2023 can improve privacy by allowing selective sharing of credentials according to the task.Source: CONCLUSION · p. 8
- The conclusion calls for agent architectures to provide guarantees about actions taken on users’ behalf.Source: CONCLUSION · p. 8