arXiv:2604.24920v1 [cs.CR] 27 Apr 2026
SUDP: Secret-Use Delegation Protocol for Agentic Systems
Xiaohang Yu Imperial College London Science Intelligence [email protected]
Hejia Geng University of Oxford Science Intelligence
William Knottenbelt∗ Imperial College London
Abstract Agentic systems increasingly act with user secrets for APIs, messaging platforms, and cloud services. Today’s bearer-secret interfaces implement authorization by exposure: enabling action often means placing a reusable secret, or a reusable artifact derived from it, within a model-steerable boundary, so a transient prompt-injection or tool-side compromise becomes durable account compromise. Existing defenses cover adjacent pieces such as secret storage, scoped delegation, sender-constrained tokens, and runtime monitoring, but leave the combined agentic obligation without a common specification: an untrusted autonomous requester should be able to cause a user-authorized secret-backed operation without exposing reusable authority to the requester. We formalize this problem as Agent Secret Use (ASU). From ASU we derive a security-property taxonomy that separates the problem’s structural obligations from the realization-level robustness conditions any concrete construction must establish, enabling principled comparison of existing agentic-secret defenses against a problem-grounded specification. We propose the Secret-Use Delegation Protocol (SUDP), a three-role protocol realizing ASU: a requester proposes a canonical operation; the user authorizes it with a fresh authenticator-backed grant; and a custodian redeems the grant once to perform the bounded use, so reusable authority never crosses the requester boundary. We specialize SUDP for agentic deployments: agents propose operations; they do not retrieve secrets. Under explicit assumptions, we show that SUDP satisfies the ASU requirements: authorization is verifiable, operation-bound, and single-use. SUDP also provides storage confidentiality and wrapping-epoch key isolation under stated sealing and erasure assumptions; plaintext-level forward secrecy of the underlying secret additionally requires the environment to rotate and revoke it.
1
Introduction
Tool-augmented language-model agents now routinely perform actions on behalf of users: calling model and platform APIs, sending messages, orchestrating cloud services, and authenticating to third-party tools [Schick et al., 2023, Mialon et al., 2023, Yao et al., 2023, OpenAI, 2023, Anthropic, 2024]. Every such action is backed by a secret (an API key, an OAuth bundle, a signing key) that grants long-lived authority over external services. The prevailing engineering practice is to store these secrets in environment variables, in server-encrypted databases, or in centralized secret managers such as HashiCorp Vault or AWS Secrets Manager [HashiCorp, 2024a, Amazon Web Services, 2024], and to hand them to the agent runtime for ad-hoc use. This is increasingly unsafe. Agentic workflows exhibit a structural security tension. The agent is useful because it can advance secret-backed operations; it is risky because anything crossing the agent boundary may be exposed ∗
Corresponding author.
Preprint.
Secret-Use Delegation Protocol (SUDP)
Requester R agent runtime
proposes o holds no secret
propose
Operation o exact action canonicalized before approval
Custodian T
Authorizer U review
user + authenticator
Grant G
issue
bound to o authorized by U single-use
reviews o signs β = H(r ∥ H(o))
redeems grants, holds Σ
submit
execute(o; s)
Environment E
secret s
external API / service
sealed in Σ
execute(o; s) not SUDP-speaking
redeem G for one use of s on o unwrap → act → zeroize
result only
Figure 1: Schematic of SUDP. Three protocol roles—Requester R, Authorizer U , Custodian T — together with the environment E (outside the protocol). The operation o and the grant G are the protocol’s authorization artifacts: R proposes o; U reviews o and issues G, whose signature binds H(o) and freshness r; T redeems G once and uses the secret s sealed in state Σ to execute o at E. Only the result returns to R, and reusable authority never crosses the requester boundary. Protocol flow, key hierarchy, and authorization-artifact structure are detailed in §5. through prompt injection, indirect instructions, model disclosure, logging, or runtime compromise [Greshake et al., 2023, Liu et al., 2024, OWASP Foundation, 2024]. Recent safety benchmarks measure the scale empirically: agents commonly follow injected commands, miss tool-hijacking attacks, and leak cross-tool privacy in the rough 40–76% range depending on the threat model [Zhan et al., 2024, Zhang et al., 2024, Debenedetti et al., 2024, Zhou et al., 2025, Qiao et al., 2025]. Once a reusable secret is exposed to the agent, a transient safety failure becomes durable account compromise. The old question is how to encrypt a secret at rest, and that question is mature. The new question for agentic systems is different: how can an agent be authorized to cause a secret-backed operation without ever being exposed to reusable authority over the secret? Today’s bearer-secret model bundles them: to let the agent act, the system places reusable authority inside the agent runtime— authorization by exposure. Agents make that bundling structurally unsafe, because anything inside the agent’s execution context is reachable by prompt injection, model disclosure, and runtime compromise. Existing approaches address neighboring dimensions of this problem—capabilitybased authority [Dennis and Van Horn, 1966, Miller, 2006], scoped delegation tokens [Hardt, 2012, Birgisson et al., 2014], sender-constrained bearers [Fett et al., 2023], user-mediated authenticators with derivable material [Balfanz et al., 2021, FIDO Alliance, 2024], and standardized cryptographic plumbing for sealing and recipient-protected delivery [Krawczyk and Eronen, 2010, Dworkin, 2012, Schaad and Housley, 2002, Housley et al., 2009, Barnes et al., 2022, Rescorla, 2018]—but do not provide a common problem-level specification for authorization without exposing reusable authority to the requester. We compose these elements into a unified protocol whose unit of delegation is one authorized operation, not the secret itself, with end-to-end protocol-level security properties. Contributions. (i) Agent Secret Use as a problem class (§3). We give a vocabulary-fragmented field a common lens: a single problem statement together with an outcome-based security-property taxonomy under which security claims for secret-mediation systems, delegation-token systems, and TEE-backed runtimes become checkable judgments against named properties. (ii) The SUDP protocol (§5). SUDP makes secret safety a cryptographic invariant rather than deployment discipline: every Phase III execution is covered by a fresh user-signed grant cryptographically bound to a specific canonical operation, and reusable authority never crosses the requester boundary. Anti-substitution, operation binding, and replay resistance hold by construction, not by code review. (iii) Specializing the secret-use interface to agentic systems (§6–9). The central change is operation proposal, not secret retrieval: R is the model-steerable execution boundary; tool calls compile into canonical operation descriptors that the user reviews; and an approved use is a bounded, custodianexecuted action rather than a transferable secret. Even a fully prompt-injected agent can at most propose a user-witnessed operation, never obtain reusable authority. We instantiate the protocol with standard cryptographic components (no new cryptographic assumption) and analyze it under a single 2
main theorem (SUDP solves the Agent Secret Use problem) parameterized by explicit assumptions, with five supporting propositions covering authorization integrity, requester non-exposure, recipientprotected export, and forward secrecy at both wrapping-epoch and authority-level granularity.
2
Related Work
We situate SUDP against the four bodies of work most relevant to Agent Secret Use: cryptographic and systems background, prior agentic delegation protocols, orthogonal runtime defenses, and the empirical benchmarks that motivate protocol-level control. Axis-level comparison with specific systems is deferred to §4. Secret management, authorization, and transaction authentication. Capability-based access control frames authority as unforgeable, scoped references [Dennis and Van Horn, 1966, Miller, 2006]; the (act, bind, valid) decomposition of o behaves as a capability but is authorized rather than created by U and redeemed exactly once. OAuth 2.0 bearer tokens [Hardt, 2012, Jones and Hardt, 2012] make possession permission within scope, motivating the secret-confidentiality side of Agent Secret Use; DPoP [Fett et al., 2023] sender-constrains bearer artifacts to a holder key, but if the proof-of-possession key sits with the requester, the requester remains trusted with reusable authority and the Agent-Secret-Use boundary is unchanged. OAuth Rich Authorization Requests [Lodderstedt et al., 2023] and GNAP [Richer, 2024] express fine-grained, software-mediated delegation, but place authorization at an authorization server rather than carving out a requester boundary that must not hold reusable authority. The MCP authorization specification [Anthropic and MCP Working Group, 2025] provides valuable OAuth-style authorization machinery for agent contexts, but by itself does not enforce the ASU boundary that reusable authority never enters the requester’s trust domain. Macaroons [Birgisson et al., 2014] attenuate authority via caveats but again pass possession-bearing artifacts through the requester. SUDP’s per-operation binding and single-use redemption remove this residual reusability. WebAuthn [Balfanz et al., 2021] and its PRF extension [FIDO Alliance, 2024] provide phishing-resistant user authentication and authenticator-bound derivation, which SUDP uses as the protocol-level primitive behind Phase II. Secret managers and KMS services [HashiCorp, 2024a, Amazon Web Services, 2024] provide mature storage, access control, and rotation, but assume a privileged backend that can authorize or reconstruct access; SUDP complements them at the authorization layer by making user-mediated, operation-bound use and recipient-protected extraction first-class. Agentic delegation and authorization protocols. A recent line of work extends web-identity constructs to agent principals. Authenticated Delegation [South et al., 2025] extends OAuth/OIDC with agent credentials bound to a verified human delegator; SAGA [Syros et al., 2025] providermediates inter-agent communication via access-control tokens derived from provider-held one-time keys; Agentic JWT [Goswami, 2025] binds each agent action to a workflow-step assertion and an agent checksum enforced by a per-process shim; HDP [Dalugoda, 2026] targets cross-hop provenance via an Ed25519-signed delegation chain. OIDC-A [OpenID Foundation, 2025] and the MCP authorization specification [Anthropic and MCP Working Group, 2025] introduce agent identity and scoped access tokens. Each targets a different subset of the ASU axes and places the trust boundary differently from SUDP; the formal comparison is in §4. Runtime defenses, monitors, and sandboxes. A large body of work hardens the agent itself or contains the consequences of misbehavior: instruction–data separation and prompt-engineering defenses [Chen et al., 2024a,b, Hines et al., 2024], capability-tracking interpreters [Debenedetti et al., 2025], per-tool policy engines [Shi et al., 2025, Wang et al., 2025, Tsai and Bagdasarian, 2025, Liu et al., 2026], verify-before-commit mitigations [Lin et al., 2026], deployable guardrail stacks [Chennabasappa et al., 2025], and execution-sandbox architectures [Ruan et al., 2023, Wu et al., 2025, Zhou et al., 2025]. These reason about what the agent is doing or contain where it does it. SUDP is orthogonal: it constrains what a secret can be used for at the boundary where the secret lives, so even an agent fully subverted past every behavioral guardrail still cannot exceed the user-signed scope bound to H(o), and the two approaches compose cleanly. Benchmarks as empirical motivation. A rapidly growing body of benchmarks quantifies agent failure under prompt injection, tool misuse, and privacy-leak pressure [Zhan et al., 2024, Debenedetti 3
et al., 2024, Zhang et al., 2025, Zhou et al., 2025, Vijayvargiya et al., 2026, Qiao et al., 2025, El Yagoubi et al., 2026]. Across these suites, attack success on secret-adjacent tasks clusters in the 24–75% range, and privacy-leak rates in multi-tool or multi-agent pipelines routinely exceed 60%. Systematizations of LLM-agent threats [Deng et al., 2026, Li et al., 2026, Ying et al., 2026] identify the Execution stage—capability-constrained secret use—as an open gap in the layered defense stack. These numbers motivate protocol-level secret-use control; empirical evaluation of deployed SUDP systems on these benchmarks is left for follow-up work.
3
Agent Secret Use
LLM agents acting on users’ behalf increasingly perform actions that require the user’s long-term credentials, yet are themselves not trustworthy to hold those credentials: untrusted inputs can steer a model’s behavior into exfiltrating any credential the agent holds. Several partial solutions to this already exist in engineering practice (credential-proxy deployments [HashiCorp, 2024b, Anthropic, 2026]; emerging agent-authorization specifications [Anthropic and MCP Working Group, 2025, South et al., 2025]), but existing systems do not isolate the agent-specific security problem as a standalone abstraction. We give the formalization here: the Agent Secret Use problem. Two structural assumptions frame Agent Secret Use and separate it from two neighboring paradigms: trustedclient authorization systems, which grant authority to code or services assumed to be inside the trusted boundary, such as OAuth 2.0 client credentials [Hardt, 2012]; and transaction-authentication systems, which bind user presence or approval to a specific action but require the environment or its authentication layer to participate in the consent protocol (e.g., PSD2 SCA and WebAuthn UV [Balfanz et al., 2021]). 3.1
The Problem
Agent Secret Use arises when an autonomous system must cause a user-authorized operation to happen without itself becoming trusted with the authority that enables that operation. Actors.
We model Agent Secret Use using three abstract actors:
• U : the user, owner of the authority under which an operation is to be performed. • R: the autonomous requester, acting on U ’s behalf but structurally untrusted with U ’s authority. • E: the environment, an external execution target such as an API, service, or remote system. Structural assumptions. • (A1) Authority-gated execution. E executes o only when presented with authority-bearing material accepted at E on behalf of U . • (A2) Untrusted autonomous initiation. R, rather than U , initiates o, but R lies outside the trusted boundary for any reusable material that would let it exercise U ’s authority at E. The core tension. The party that must trigger the operation is precisely the party that must not be exposed to the secret enabling it. For bearer-style interfaces such as API keys and OAuth 2.0 bearer tokens, possession is permission at E’s boundary: whoever presents the accepted artifact can exercise the corresponding authority [Jones and Hardt, 2012]. Signing keys are not bearer artifacts in the same sense, but have an analogous effect: possession of the key enables generation of artifacts accepted by E as U ’s authority. Under the unmediated native interface, (A1) and (A2) force a bad choice: either R cannot trigger o, or R must be exposed to authority-bearing material it cannot be trusted to hold. Figure 2 makes this tension visual and shows why any solution must create a path through which R can request use without receiving reusable authority. Agent Secret Use captures this structural conflict independently of the credential format or external interface through which E authorizes execution. We now state the problem independently of any particular mechanism. Primitive view. Agent Secret Use is a controlled-use problem for authority-bearing secrets. The goal is not merely to hide a credential at rest, nor merely to authenticate a client, but to separate two capabilities that native credential interfaces normally bundle: the capability to request a use of authority-bearing material, and the capability to possess reusable authority over that material. 4
(a) Native interfaces: authorization by exposure
(b) Agent Secret Use: authorization without exposing reusable authority
Setting. The user holds a reusable secret; the requester must cause an operation; the environment accepts only secret-backed calls.
ASU decouples authorization from exposure: R proposes an operation, U authorizes it, and a mediator spends the secret internally so that reusable authority is never exposed to R.
Path 1. transfer the secret s to the requester
User authorizer holds the secret
transfer s ✗
Requester
execute w/ s
agent runtime receives the secret
✗ reusable secret s reaches the requester
authorize operation
Environment
User
external service accepts secret-backed calls
authorizer authorizes the operation
execute w/ s
✓ functionally works
Mediator propose operation
Path 2. keep the secret s out of the requester boundary
Environment external service accepts secret-backed calls
consumes the secret internally
Requester agent runtime proposes the operation
User
✗
authorizer holds the secret
Requester agent runtime no secret
execute w/o s ✗
Environment external service accepts secret-backed calls
The requester never receives reusable secret s ✓ secret s never left the authorizer
✓ authorized use
✗ native execution fails
✓ operation-specific
✓ no reusable authority to the requester
Figure 2: Agent Secret Use as a structural problem. (a) Native secret-backed interfaces implement authorization by exposure: handing s to R functionally works but lets reusable authority reach R; keeping s outside R preserves confidentiality but the native call is rejected by E. (b) ASU decouples authorization from exposure: R proposes the operation, U authorizes it, and a mediator spends s internally so that reusable authority is never exposed to R.
Definition 1 (Authority-bearing material). Fix a user U and an environment E. Material s is authority-bearing for U at E if possession of s, or possession of material that can produce artifacts accepted by E, enables operations at E under U ’s authority. Such material is reusable if it can authorize more than a single already-consumed use, or can be transferred to another party who can exercise the same authority without a fresh authorization event by U . Definition 2 (Agent Secret Use setting). An Agent Secret Use setting consists of: • a user U , who owns authority at an environment E; • an autonomous requester R, which may initiate or propose operations on U ’s behalf; • an environment E, whose native interface accepts authority-bearing material on behalf of U ; • a space of authority-relevant operations OE ; and • reusable authority-bearing material s accepted at E on behalf of U . Each o ∈ OE denotes a secret-backed operation whose execution at E may require s, or an artifact derived from s, as authority. The requester R lies outside the trust boundary for any reusable material that would let it exercise U ’s authority at E, but R must still be able to request that some o ∈ OE be executed under U ’s authority. Definition 3 (Agent Secret Use problem). The Agent Secret Use (ASU) problem asks how an untrusted autonomous requester R can cause operations in OE to be executed at E under U ’s authority, without exposing reusable authority accepted at E to R. A mechanism solves the ASU problem if, under its stated adversarial and deployment assumptions, every execution induced through the mechanism satisfies: (a) Authorized-use soundness. Any successful execution induced through the mechanism is covered by an authorization event attributable to U under the mechanism’s stated identity and trust assumptions. (b) Operation non-transferability. An authorization for an operation o ∈ OE cannot be used through the mechanism to induce execution of a semantically distinct operation o′ ̸≡E o, except within the usage bounds explicitly authorized by U . (c) Use boundedness. An authorization can be consumed only within its stated freshness, expiry, multiplicity, and replay bounds; in the single-use case, a consumed authorization cannot be redeemed again for the same operation. 5
(d) Requester non-exposure. The requester’s view reveals neither s nor any reusable authoritybearing material or transferable artifact that would let R exercise the same authority at E without a fresh authorization event by U . Adversarial model. Agent Secret Use locates the minimal adversarial boundary at R. The adversary may fully control R and observe any state visible to R, including its memory, logs, and persistent storage. It may replay or repurpose prior authorization artifacts unless prevented by operation binding and freshness, and may observe, delay, or tamper with communication outside authenticated channels. The Agent-Secret-Use problem does not assume any particular intermediary, storage service, hardware root, or enforcement architecture; components introduced by a concrete solution have their own compromise assumptions, which belong to that realization rather than to the minimal Agent-Secret-Use model. Scope and exclusions. Agent Secret Use is a problem about safe use of existing authority by an untrusted autonomous delegate, not about how that authority is provisioned or whether the requested operation is semantically appropriate. We therefore treat credential provisioning upstream of U , application-level semantics of o at E, and behavioral policy enforcement as orthogonal. We also exclude full compromise of U ’s authenticator, side-channel or hardware attacks outside the intended trust boundary, and availability, denial-of-service resistance, or liveness, which are system-level concerns. 3.2
Relation to Prior Paradigms
Agent Secret Use isolates a specific agentic collision: an autonomous requester that initiates operations on the user’s behalf must stay outside the boundary that holds reusable authority for those operations. This is a confused-deputy setting [Hardy, 1988] with an added confidentiality constraint—the deputy must not be exposed to the reusable authority it could be induced to misuse. Prior paradigms answer the same problem by placing the authority-holding boundary at different points: policy-gated access to stored secrets (Vault, KMS); holders of delegated tokens or capabilities [Jones and Hardt, 2012, Birgisson et al., 2014]; hardware boundaries around signing keys or enclave-confined code (HSM, secure enclave, TEE-backed runtimes); or trusted user-facing clients in a relying-party ceremony (banking 2FA, Secure Payment Confirmation [W3C Web Payments Working Group, 2024]). Agent Secret Use does not prescribe a location; it fixes a negative boundary condition—R must stay outside any boundary that contains reusable authority accepted at E—and leaves placement to the realization. Axis-level positioning is given in §4. Closest analogue: transaction authentication. Transaction-authentication systems—PSD2 dynamic linking, banking 2FA, and Secure Payment Confirmation or WebAuthn transactionconfirmation-style ceremonies built atop authenticator-backed signing primitives such as WebAuthn UV [Balfanz et al., 2021]—are the closest neighboring paradigm because they bind user approval to a specific operation through a relying-party ceremony. They are typically organized around a trusted user-facing client or a cooperating relying party. Agent Secret Use instead focuses on the agentic requester boundary: the autonomous requester may initiate, but must not receive reusable authority at E. Agent Secret Use requires both operation-bound authorization and secret confidentiality against the requester; how these are realized is left to specific mechanisms. 3.3
A Security-Property Taxonomy
Existing work on LLM-agent security spans diverse defense families (behavioral monitors, policy DSLs, taint-tracking interpreters, execution sandboxes, secret-mediation systems, TEE-backed runtimes, and delegation-token protocols; §2), each with its own vocabulary for threat model and guarantees. Comparison across these families is consequently ad hoc: each paper defines its own security goals, and a reader has no common lens through which to assess whether one defense subsumes, extends, or composes with another. We therefore propose a security-property taxonomy for Agent Secret Use: a set of properties derived directly from Definition 3 together with realization-level robustness conditions any concrete construction must establish, organized following the classical confidentiality/integrity distinction [McCumber, 1991, Saltzer and Schroeder, 1975]. Authorized-use soundness gives AV; operation non-transferability gives OB; use boundedness gives 6
RR; requester non-exposure gives CRC. The robustness conditions—CSB, CMC, RFS—evaluate any secret-holding or enforcement component a concrete mechanism introduces. Evaluation boundary. The axes differ in where they are evaluated. CRC, AV, OB, and RR are evaluated at the requester / use-authorization boundary fixed by Definition 3: the requester may be fully compromised, yet cannot obtain reusable authority or cause unbounded, unrooted, or transferable use. CSB, CMC, and RFS evaluate the robustness of the secret-holding or enforcement component introduced by a concrete realization—persistent-state compromise, runtime-memory compromise, and rotation-era compromise, respectively. They are comparison axes for realizations, not additional assumptions of the minimal Agent-Secret-Use problem; Agent Secret Use does not prescribe a compromise model for the intermediating component, and the taxonomy provides a uniform grid along which realizations can be compared regardless of which compromise models they make. Methodology: outcome-based, not mechanism-based. Each axis is named by the adversarial capability or failure mode it rules out [Krawczyk, 2005, Cohn-Gordon et al., 2016, Jarecki et al., 2018], not by the mechanism a defense uses to achieve it; many mechanisms can instantiate the same security outcome, so what distinguishes defenses is the boundary they guarantee. For exposition we group the axes along the classical confidentiality/integrity distinction: §3.3.1 covers CRC, CSB, CMC, and RFS—the axes protecting reusable authority-bearing material; §3.3.2 covers AV, OB, and RR—the axes protecting per-use authorization artifacts. We use “integrity” here to cover tamper-resistance, origin authenticity, and audit evidence for authorization artifacts, reflecting how digital-signature primitives jointly deliver these under standard key-management and identity-binding assumptions. 3.3.1
Secret Confidentiality
• CRC: Confidentiality under Requester Compromise. Even an adversary with full control of the requester (its process, memory, shim libraries, and any key material it can derive in-process) cannot read the plaintext secret. This axis tests whether the secret ever crosses into the requester’s trust domain. • CSB: Confidentiality under Storage Breach. For mechanisms that store secret material outside R, an adversary who obtains the full persistent state of the secret-holding component (disk images, backups, files, and any unlock material stored with that component) cannot recover plaintext without material or service assumptions outside the compromised persistent state—for example, an authenticator-bound PRF, a hardware-rooted seal, a threshold share held by a separate party, or an online unlock service. Encryption whose unlock key resides entirely within the same compromised persistent state does not satisfy CSB. This is the agent-secret analogue of OPAQUE’s server-compromise resistance [Jarecki et al., 2018]. • CMC: Confidentiality under Runtime-Memory Compromise. For mechanisms that process secret material outside R, an adversary with read access to the host or OS memory of the secrethandling component cannot recover plaintext, within the stated isolation boundary of the protecting mechanism and excluding side-channel attacks against that boundary. Hardware-rooted TEEs may satisfy CMC within their documented threat model [Costan and Devadas, 2016]; software-only schemes relying solely on OS process isolation generally do not. • RFS: Rotation Forward Secrecy. Compromise of current secret-handling state cannot recover plaintext secret material from prior rotation epochs, provided prior epoch keys have been destroyed and prior authority-bearing secrets have been rotated or revoked at E; and compromise of retired epoch state cannot recover secret material introduced in later epochs. RFS is meaningful only when rotation advances the authority-bearing secret version, not merely the wrapping key: rotating only wrapping material while reusing the same underlying secret leaves E-side authority unchanged across epochs and is therefore epoch-key isolation rather than authority-level forward secrecy. An analogue of Signal-style forward secrecy [Cohn-Gordon et al., 2016] applied to the secret-rotation timeline rather than to session keys. Out of scope. Exposure paths outside these modeled boundaries—client or authenticator compromise, logs and telemetry, IPC, crash dumps, supply-chain code injection, side channels, and out-of-band copying—are deployment concerns orthogonal to the axes and are not enumerated here. 7
3.3.2
Authorization Integrity
• AV: Authorization Verifiability. A verifier can check that the authorization artifact is rooted in U ’s authority under the mechanism’s stated identity and key-management assumptions: the artifact carries a signature, assertion, or equivalent cryptographic witness whose trust chain terminates at U or at an authority acting under an explicit trust model for U . Artifacts produced directly by an authenticator controlled by U for the specific operation provide stronger direct-user-witness evidence than artifacts rooted only in an identity provider or authorization server’s assertion about U . Under standard key-custody and identity-binding assumptions, AV supports third-party-verifiable audit evidence. • OB: Operation Binding. An authorization for an operation o cannot be redeemed through the mechanism to induce execution of any semantically distinct o′ ̸≡E o: substitution or repurposing to a distinct operation is rejected by the verifier. The mechanism guarantees this for the authorityrelevant fields it represents in o; fields outside that representation fall outside OB and must be controlled separately. Scope-based authorization that covers many semantically distinct operations within the scope does not satisfy OB; a manually narrow scope does not by itself satisfy OB unless the mechanism enforces per-operation binding (typically via a cryptographic commitment to the canonical operation, but other binding architectures qualify). • RR: Replay Resistance. A captured or previously redeemed authorization artifact cannot be redeemed again for the same operation or protocol instance: the protocol enforces single-use via explicit consumption (a freshness token, a redemption record, or equivalent state). Short-TTL bearer tokens do not satisfy RR: within the window, the same artifact is reusable against the same operation.
4
Positioning SUDP in the Landscape
We apply the taxonomy of §3.3 to position SUDP among representative systems for agent secret use. An additional deployability axis: Framework Independence (FI). Beyond the seven security axes of §3.3, we introduce one additional evaluation dimension that is not itself a security property but matters for practical adoption. A defense is framework-independent (FI-positive) if its specification is adoptable by any LLM-agent runtime without requiring a specific agent SDK, planner, tool scheduler, or TEE-backed execution architecture. FI is kept outside the security-property axes because it is an adoption property rather than a security outcome; separating it prevents conflating “can this defense be used?” with “does this defense provide security X?”. We surface FI here, at the positioning stage, because its usefulness is exactly cross-system comparison. Scope of the comparison. Table 1 restricts attention to systems that make secret-confidentiality or authorization claims. Behavioral monitors [Chennabasappa et al., 2025, Luo et al., 2025], policy DSLs [Shi et al., 2025, Wang et al., 2025, Tsai and Bagdasarian, 2025], taint-tracking interpreters [Debenedetti et al., 2025], and execution sandboxes [Wu et al., 2025] operate at orthogonal layers (prompt / tool-call / data-flow / cross-app isolation) and are not captured by our axes; they compose with SUDP rather than compete, as discussed at the end of this section. Reading the table. Scope. The table evaluates each system against the Agent-Secret-Use security properties of §3.3 under the semantics of Definition 3; a × indicates “does not satisfy this property under our definition,” not “the system lacks security value.” Many cited systems are well-designed answers to neighboring problems (token scoping, agent identity, authorization expression, runtime isolation) that simply place their trust boundaries elsewhere. Axes. Secret Confidentiality: CRC (Requester), CSB (Storage Breach), CMC (Runtime-Memory Compromise), RFS (Rotation Forward Secrecy). Authorization Integrity: AV (Verifiability), OB (Operation Binding), RR (Replay Resistance). Deployability: FI (Framework Independence; not a security axis). Symbols. ✓ = the cited work explicitly satisfies the axis under the strict definition of §3.3. △ = the cited work makes a related claim that addresses the same surface but falls short of the strict definition (a documented near-miss with a specific reason—not partial credit). × = the public specification does not establish this property under the strict ASU semantics of §3.3. Ratings reflect the strongest guarantee explicitly specified by the cited work or its documented deployment modes, not hypothetical extensions. 8
Table 1: Positioning along the seven security axes of §3.3 plus the deployability axis FI. Symbol semantics, axis abbreviations, and row-specific rationale follow. Secret Confidentiality
Authorization Integrity Deploy.
CRC CSB CMC RFS AV OB
RR
FI
Bearer-token baseline MCP Authorization (2025-06-18) [Anthropic and MCP Working Group, 2025]
× ×
× ×
× ×
× ×
× ×
× ×
× ×
✓ ✓
HashiCorp Vault Agent [HashiCorp, 2024b] Aegis [Warren, 2025] Claude Agent SDK proxy [Anthropic, 2026] IronClaw [NEAR AI, 2026]
△ ✓ △ ✓
△ △ × ✓
× × × ✓
× × × ×
△ × × ×
× × × ×
× × × ×
✓ ✓ ✓ ×
Authenticated Delegation [South et al., 2025] SAGA [Syros et al., 2025] OIDC-A [OpenID Foundation, 2025] HDP [Dalugoda, 2026] Agentic JWT [Goswami, 2025]
× × × × ×
× × × × ×
× × × × ×
× × × × ×
△ ✓ △ ✓ △
× △ × × △
× × × △ △
✓ △ ✓ ✓ ✓
SUDP (this paper)
✓
✓
×
✓
✓
✓
✓
✓
Row notes and △ rationale. Bearer-token baseline: the prevalent agent-framework pattern in which API keys or OAuth bearer tokens are passed to the agent runtime for direct use; representative deployments include LangChain [LangChain, 2024], AutoGen [Wu et al., 2023], CrewAI [CrewAI, 2024], and the OpenAI Agents SDK [OpenAI, 2024]. The row characterizes this general architecture rather than ranking the cited frameworks. IronClaw: rated under its TEE-backed managed deployment mode; the self-host mode does not satisfy CMC. SUDP: RFS holds at the authority level only when the deployment honours the rotation invariant of §5.8, including rotation/revocation of authority-bearing secrets at E. The 13 △ ratings cluster into five near-miss patterns: (i) mode-dependent confidentiality satisfied only in specific deployment modes; (ii) scope-bound rather than per-operation authorization (binding to an agent or workflow step rather than the operation descriptor); (iii) TTL- or sessionbound rather than single-use replay resistance; (iv) IdP-asserted-about-U rather than user-witnessed authorization (rooted in an authorization-server assertion rather than an authenticator witness U produces for the specific operation); (v) architecturally service-bound (a deployed coordination service rather than framework-independent mediation).
Landscape pattern. The table exposes three neighboring clusters that place the trusted boundary differently. Secret-mediation systems—Vault Agent [HashiCorp, 2024b], Aegis [Warren, 2025], Claude Agent SDK proxy [Anthropic, 2026], IronClaw [NEAR AI, 2026]—concentrate on keeping reusable authority outside the requester and cover the Secret Confidentiality family to varying degrees, but do not issue operation-bound user-rooted authorization artifacts. Delegation-token and agentauthorization systems—Authenticated Delegation [South et al., 2025], SAGA [Syros et al., 2025], OIDC-A [OpenID Foundation, 2025], HDP [Dalugoda, 2026], Agentic JWT [Goswami, 2025]— concentrate on authorization, scoping, and provenance on top of OAuth/OIDC-style infrastructure; they touch parts of AV, OB, and RR but leave reusable authority inside the requester boundary. TEE and confidential-computing systems, of which IronClaw’s TEE-backed managed deployment is the intable representative, address host-memory confidentiality and can additionally supply code-integrity attestation [Costan and Devadas, 2016], at the cost of a specific execution substrate rather than framework-independent mediation. The three clusters cover different surfaces.
SUDP’s position and composition. SUDP combines requester, storage, and rotation-era secret confidentiality (CRC, CSB, RFS) with verifiable, operation-bound, replay-resistant authorization (AV, OB, RR), and is FI-positive. It does not satisfy CMC, which requires hardware-rooted memory protection, and does not itself claim code-integrity attestation, multi-hop delegation provenance, behavioral-policy correctness, taint tracking, or sandbox isolation. These guarantees are complementary rather than substitutive: a deployment may run SUDP inside a TEE (closing CMC via hardware-rooted memory encryption while retaining SUDP’s per-action authorization), behind a runtime-monitor or policy-DSL guardrail, alongside taint tracking or sandboxed tool execution, or chain SUDP’s single-hop user gesture into a multi-hop delegation protocol for cross-administrativedomain reach. 9
5
The Secret-Use Delegation Protocol
SUDP is a protocol-level answer to capability-constrained secret use. The unit of delegation is the use of a secret for one specific authorized operation o, not the secret itself: the requester is delegated the right to cause an authorized use, the custodian is delegated the right to perform that single use, and reusable authority never crosses the requester boundary. This section first fixes SUDP’s roles, trust assumptions, and execution patterns (§5.1), then defines SUDP as an abstract protocol over generic cryptographic interfaces (§5.2–5.7) together with the rotation and rewrap discipline that delivers per-credential forward secrecy (§5.8). The agentic-system interface induced by the protocol is given in §6; the standards-based cryptographic instantiation in §7; architectural design choices in §8. 5.1
Roles, Trust Assumptions, and Execution Patterns
SUDP realizes the secret-use interface required by Agent Secret Use (§3.1) by introducing one new protocol role: a custodian T that holds reusable authority as sealed state Σ, issues freshness, verifies user-rooted operation-bound grants, redeems them once, and performs the authorized secret-backed action. The custodian is the role through which SUDP implements the secret-use interface; it is not the interface itself. The custodian is a protocol role, not necessarily a deployment component: realizations include a local proxy, a hosted proxy, an OS-level credential mediator, an HSM- or TEE-backed service, or, in cooperative settings, the environment itself. The agentic specialization of the interface—how R becomes the model-steerable execution boundary, how tool calls compile into operations, and what guarantees survive a fully compromised agent—is the subject of §6. SUDP entities. SUDP refines Agent Secret Use’s user U into the protocol authorizer and its autonomous delegate R into the protocol requester, and introduces a single new protocol role, the custodian T : • U : the authorizer, governing whether a secret-backed operation may proceed. • R: the requester, initiating an operation request, typically an agent. • T : the custodian, holding the sealed state Σ, validating authorization, redeeming operation-bound grants, and using protected authority material to perform the secret-backed operation; distinct from U. The external environment E is inherited from Agent Secret Use as the execution target; it is not a SUDP-speaking party and is not assumed to participate in the protocol beyond accepting its existing credential interface. The sealed state Σ is data managed by T , not a protocol-speaking party of its own. SUDP-specific trust assumptions. Beyond the problem-level assumption of user-controlled authorization (§3.1), SUDP’s architectural choices introduce two additional assumptions. Restricted trust in the custodian: T is trusted only to validate authorization, redeem grants, and transiently consume secret material during valid consumption; the requester is not trusted with secret access. Sealed persistent state: Σ is sealed such that the persistent state alone is insufficient for standalone recovery, and any authorized extraction leaves T only in recipient-protected form. Two execution patterns. The protocol supports two execution patterns of the same abstraction. In delegated execution, R and U are distinct (an agent initiates an operation and the user later authorizes it), so the authorization flow crosses parties. In direct execution, R = U , and the authorization flow collapses. The motivating agentic case is delegated execution; direct execution is a special case when initiation and authorization are co-located. 5.2
Protected State and Key Hierarchy
SUDP uses the standard envelope-encryption pattern with an explicit two-stage derivation on the user side that makes the role boundary visible in the key hierarchy itself (Figure 3). The protected state M (the contents of Σ the protocol secures) is sealed once under a state-encryption key K; K is in turn wrapped separately under each authorizer credential’s wrapping key Wc . This separation is deliberate: rotating K does not require interacting with every credential (each Wc simply rewraps 10
User-held credential Transit Custodian-held sealed state
Ac : skc , PRF key
user-owned credential
yc ← PRFc (ηc )
credential-scoped PRF output
uc ← KDF(yc ; ⊥, DSuser ∥ cid c )
derivation transit (U → T )
Wc ← KDF(uc ; ηc , DSwrap ∥ cid c ∥ ver )
b c ← Wrap (K) K Wc
C ← EncK (M )
user secret / non-extractable
per-credential wrapping key
wrapped state key
encrypted protected state
transit (confidential)
persistent sealed state
Figure 3: SUDP key hierarchy, organized in three trust zones. User-held credential material (blue) originates inside the authenticator Ac and never leaves it; transit (gray) is the single derivation value uc that crosses the U → T channel under confidentiality; custodian-held sealed state (red) is the persistent wrapping/encryption chain. The two-stage split yc → uc → Wc is what makes this zoning realizable: only uc crosses the boundary, and Wc is reconstructed only inside the custodian T . b c is the new K), and registering a new credential does not require re-encrypting M (only a new K appended). Formally, C ← EncK (M ), M ← DecK (C), and for each eligible authorization path i, b i ← WrapW (K), K i
b i ). K ← UnwrapWi (K
b i }; {Wi } defines the recoverability structure The persistent cryptographic state consists of C and {K of K. By construction, the requester never receives K, any Wi , or any value from which either can be efficiently derived. 5.3
Authorized Operation and Grant
Rather than authorizing decryption in the abstract, SUDP authorizes a specific secret-backed operation together with its redemption binding and validity conditions. A well-formed authorization object encodes three aspects: (i) authorization semantics: what is approved; (ii) redemption binding: who may redeem and, if extracting, who receives; and (iii) validity constraints: how long the authorization is valid and how it resists replay and substitution. Each component corresponds to a distinct security obligation: the semantics must be reviewable at U , the binding must resist substitution, and the validity must resist replay. Freshness is supplied by the Phase II freshness token r (§5.6) rather than carried inside o; o commits to r implicitly through the Phase II binding. Definition 4 (Authorized operation). An authorized operation is a canonical protocol tuple o := (act, bind, valid), where act := (type, target, scope), bind := (redeemer, recipient), and valid := (expiry). Here type specifies the semantic class of the secret-backed action (e.g., use, export, write, rotate, enroll, revoke); target identifies the protected object; scope carries canonicalized operation-specific constraints; redeemer identifies the party entitled to redeem; recipient identifies the intended recipient of any extracting delivery; and expiry bounds validity. Freshness is enforced separately, via the single-use token r issued at Phase II.1 and consumed at Phase II.3. 11
Definition 5 (Grant). A grant is the protocol artifact representing successful user authorization of an authorized operation o. A grant commits to o, carries the authorization evidence required for later validation, and serves as the input to redemption. A valid grant does not transfer secret ownership; it confers a scoped secret-use capability for o, subject to the redemption binding and validity conditions encoded in o. Throughout SUDP we reserve specific terms: grant G is the user-authorized artifact sent to T ; redeemed grant ρ is G’s custodian-internal post-validation form; “authorization artifact” is the generic taxonomy term covering both. Under this abstraction, o specifies what is approved while G represents that such approval has been issued in a form that can later be redeemed and consumed. The distinction, borrowed from OAuth’s separation of authorization (the act) from grant (the artifact), is security-critical: SUDP binds both to the same β commitment in Phase II, so the authorization semantics and the redeemable artifact cannot be substituted for one another. Descriptor completeness. SUDP realizes operation non-transferability (Definition 3(b)) for the authority-relevant fields encoded in o. Every field that can affect the authority exercised at E must therefore be represented in o.act.scope, o.bind, or o.valid. For HTTP/API-style operations this typically includes the method, endpoint, path parameters, target resource, recipient or account identifiers, amount or value where applicable, audience or domain, replay or idempotency domain, and a hash or canonical representation of the request body when one is sent. Fields omitted from o are outside SUDP’s operation-binding guarantee and must be controlled by deployment mechanisms outside the protocol. Trusted rendering. The user’s authorization gesture in Phase II.2 applies to a trusted rendering of o, not to an agent-supplied natural-language summary. Render(o) must be deterministic, complete with respect to the authority-relevant fields represented in o, and produced inside U ’s trusted client. Cryptographic operation binding prevents post-approval substitution of o; it does not prevent a malicious requester from proposing a dangerous-but-correctly-encoded o, nor does it protect against a rendering failure that hides security-relevant fields from U . Cryptographic operation binding and the integrity of Render compose: neither alone yields meaningful AV/OB guarantees. Execution mapping. After Phase II.3 admits a grant for o, the native action performed at E by T (or by the enforcement point an extracting profile delivers to) must be a deterministic function of the accepted descriptor o, the protected material released inside T , and any non-secret payload that o commits. R must not be able to supply additional authority-relevant fields after redemption; otherwise R could obtain U ’s approval on a benign o and then attach an undisclosed endpoint, recipient, body, or amount during Phase III, defeating operation non-transferability without forging σ ⋆ . Profiles that need R-supplied content (e.g., a request body) commit it through o.act.scope (a body hash or canonical body), so substitution at Phase III breaks the binding the same way substitution between II.2 and II.3 does. 5.4
Abstract Cryptographic Primitives
We fix primitive interfaces here; concrete algorithm choices appear in §7. H is a collision-resistant hash; KDF(ikm; salt, info) has HKDF-style extract-then-expand semantics with explicit domain separation in info; (Enc, Dec), with c ← Enck (m; ad ), is IND-CCA AEAD with associated-data authentication; (Sig, Vrfy) is EUF-CMA secure; (Encap, Decap) is IND-CCA2 secure; CSPRNG is a cryptographically secure randomness source. (Wrap, Unwrap) is a key-wrap interface specialized to key material, E ← WrapW (K), whose wrapping context is bound through the derivation of W rather than through a separate Wrap parameter: because W itself is produced by a domain-separated KDF keyed to the credential, salt, and version (§5.2), any attempt to unwrap under a W derived from different context material fails by construction, and the interface accommodates both associateddata-free wrap constructions (such as AES-KW/KWP) and AEAD-as-wrap profiles that additionally authenticate the same domain-separation labels. Each user-side credential c is modeled as a tamper-resistant module Ac with non-extractable internal keys. Under a user-verification gesture, Ac exposes two primitives: σ ← Sigsk c (µ) over an externally supplied challenge µ, and y ← PRFc (s) under a credential-internal key that never leaves the module. Enrollment releases public material (cid c , pk c ). Every info or ad argument throughout the protocol 12
carries a stable domain-separation label DS⋆ ; labels are pairwise disjoint across contexts, and no label is ever reused. Canonical serialization. H(o) presumes a deterministic encoding of the structured value o that is also identical at U and T . A concrete profile must fix this serialization (for instance, a canonical CBOR or RFC 8785 JCS encoding of the (act, bind, valid) fields) and enforce it at both endpoints. Ambiguity in the encoding can defeat operation binding without violating collision resistance of H: two semantically distinct descriptors may serialize to the same bytes (so that an adversary substitutes o′ ̸= o with the same H-input), or the same descriptor may serialize differently at U and T (so that U authorizes an operation whose canonical form at T differs from the one Render presented at gesture time). Both failures collapse OB regardless of H’s strength. The specific serialization is a profile parameter, not a protocol choice. Pairwise communication runs over a pre-established authenticated channel; transport is assumed, not re-specified. Confidentiality is required on the U → T leg (which carries u⋆ ) and on the final response leg (which may carry the delivery artifact π or a use-result ρout ). Integrity is required on every leg. The R → U hand-off (Phase II.1) carries only public material (o, r, {(cid c , ηc )}) and does not require confidentiality; its only protection need is against denial-of-service tampering, which is detected at redemption through the signature on β. 5.5
Phase I: Setup
Setup initializes the persistent cryptographic state required by the remaining phases. Its structural outcome is that, after the setup phase completes and transient values are erased, no persistent state held by any single party contains both K and any wrapping key Wc , and every enrolled credential is on an independent authorization path to K. The requester R is not involved. I.1 Credential enrollment. The authorizer registers one or more authenticator credentials with T . Each credential creation generates Ac ’s internal PRF key and signing key (neither of which ever leaves the module) and releases a credential identifier cid c together with the public verification key pk c : (cid c , pk c ) ← Enroll(Ac ). T records the registration map Reg := {cid c 7→ pk c }c∈Creds , which Phase II.3 will use to verify authorization evidence. I.2 Protected-state sealing. T generates a fresh state-encryption key and seals the initial protected state: $ K ← CSPRNG, C ← EncK (M0 ; DSstate ∥ ver ). For each enrolled credential c, U and T jointly derive a credential-specific wrapping key through a single user-verified invocation of Ac . The authenticator evaluates its PRF under a freshly sampled salt ηc to produce yc ; U then derives an intermediate value uc and transmits it to T , which derives bc: the wrapping key Wc and produces the wrapped entry K $
ηc ← CSPRNG, yc ← PRFc (ηc ), uc ← KDF(yc ; ⊥, DSuser ∥ cid c ), Wc ← KDF(uc ; ηc , DSwrap ∥ cid c ∥ ver ), b c ← WrapW (K). K c
The two-stage derivation yc → uc → Wc marks the U → T role boundary: uc is the only derivation value crossing the channel, Wc is reconstructed only inside T , and the authenticator-internal PRF key is never exposed. Because domain-separation info binds cid c at both KDF stages, derivations for distinct credentials remain independent even when the same authenticator hosts several of them. I.3 Freshness state. T initializes a bounded single-use pool S of freshness tokens (r, τr ). Each token is issued and consumed exactly once in Phase II and has short lifetime τr (on the order of minutes), which bounds the set of outstanding authorizations. 13
I.4 Output.
Phase I leaves the persistent state b c )}c∈Creds , Reg, ver . Σ0 := C, {(cid c , ηc , K
Two invariants close the phase. Persistent-state separation: after transient values from I.2 are zeroized, no persistent state held by any party contains both K and any Wc ; U carries no persistent key material, and Σ0 alone is insufficient for plaintext recovery of M0 . Uniform recoverability: every enrolled credential c can reach K via one gesture on Ac together with Σ0 alone. 5.6
Phase II: Authorization Grant Protocol
The grant phase converts an authorization decision into a single-use protocol artifact that commits cryptographically to the specific operation being approved (Figure 4). SUDP distinguishes the grant G that U emits—whose signature commits to a binding β over the specific operation—from the redeemed grant ρ that T produces after verifying G’s signature against β. Only G carries cryptographic evidence; ρ is T ’s post-validation record of that evidence having been accepted. II.1 Grant request. R initiates by submitting the operation it wants authorized. It assembles o = (act, bind, valid), fixing bind.redeemer = T and, for extracting operations, bind.recipient to the intended recipient’s public key, and submits o to T over the authenticated channel. T issues a fresh $
freshness token r ← CSPRNG, stores (r, τr ) in S, and returns (r, {(cid c , ηc )}c∈Creds ) to R. The (cid c , ηc ) entries are public material: cid c is a credential identifier, ηc is the current per-credential PRF salt, and both are needed by U to invoke the correct authenticator. R then forwards (o, r, {(cid c , ηc )}) to U over an out-of-band channel: a deep link, a QR code, or a user-agent hand-off. This channel’s confidentiality is not required: o is not sensitive, and any tampering will be detected at redemption because the subsequent signature commits to o itself (II.4). In direct execution (R = U ) this hand-off collapses, and U obtains r from T in the same session. II.2 User authorization. U renders o inside its trusted boundary and decides whether to approve. On approval, U selects an acting credential c⋆ ∈ Creds and, in the same user-verified ceremony with Ac⋆ , produces a signature over β and a PRF-derived value for ηc⋆ . Render(o) and the descriptor-completeness obligation it presupposes are stated as protocol requirements in §5.3 (Trusted rendering, Descriptor completeness), and β below is the cryptographic commitment that binds the gesture to those requirements. Channel-bound assertion. U computes the binding β := H(DSbind ∥ r ∥ H(o)), passes β to Ac⋆ as the signing challenge, and obtains σ ⋆ ← Sigsk c⋆ (β). The binding β commits to the session (via r), the domain-separated context label, and the operation (via H(o)): any change to o between II.2 and II.3 causes the β ′ recomputed at redemption to diverge from the β signed into σ ⋆ . Derived authorizer material. The same user gesture evaluates Ac⋆ ’s PRF to produce u⋆ , the client-side intermediate of the wrapping-key derivation for c⋆ : u⋆ ← KDF(PRFc⋆ (ηc⋆ ); ⊥, DSuser ∥ cid c⋆ ). For rotation-class operations (§5.7), U additionally samples a fresh next-salt ηcnext ⋆ , places it inside o.act.scope so that β commits to it, and derives u⋆next in the same gesture; this fuses the authorization of a state-update with the authorization of the accompanying salt rotation. U transmits the grant
G := (o, r, cid c⋆ , u⋆ , σ ⋆ , opt), to T directly over the authenticated and confidential channel, not via R; here opt = (u⋆next , ηcnext ⋆ ) appears only for rotation-class o. Channel confidentiality on the U → T leg is required: because ηc⋆ is public (carried in Σ), any party that observes u⋆ can recompute W ⋆ and decrypt, and the confidentiality of u⋆ is not protected by the signature. This makes the asymmetry between the R → U hand-off (public payload, no confidentiality needed) and the U → T transmission (carries u⋆ , confidentiality required) a security-critical part of the channel model. 14
II.3 Grant redemption.
On receipt of G, T validates five conditions in sequence:
1. consume (r, ·) from S (reject if absent or expired); 2. recompute β ′ := H(DSbind ∥ r ∥ H(o)) from the received o; 3. verify VrfyReg[cid c⋆ ] (β ′ , σ ⋆ ) = 1; 4. enforce Policy(cid c⋆ , o) = 1, where Policy is an application-supplied admissibility predicate; 5. check that o.valid.expiry is in the future at the current protocol instant. Steps 1–3 are the cryptographic core; any step-3 failure detects the forgery before any further state is touched. As standard hygiene against timing side channels on signature verification, the comparison inside Vrfy is performed in constant time. Policy in step 4 is used only for semantic admissibility of the already-committed o: it cannot widen the operation beyond the fields cryptographically committed in H(o), and AV, OB, and RR do not depend on Policy secrecy. On success, T emits the redeemed grant ρ := (o, cid c⋆ , u⋆ , opt). ρ is custodian-internal: R never sees it, and the single-use bookkeeping of S guarantees that the same (o, r, σ ⋆ ) triple cannot authorize two Phase III invocations. II.4 Anti-substitution. Because β commits to H(o) and U renders o inside its trusted boundary before the gesture, the o that T validates in II.3 is necessarily the same o that U reviewed in II.2, regardless of adversarial control over R or over any channel between R and U . Any substitution, tampering, or injection of a modified o′ between approval and redemption produces a β ′ that diverges from the β signed by the authenticator; under EUF-CMA of Sig, no adversary without access to sk c⋆ can produce a valid signature on the new β ′ . 5.7
Phase III: Grant Consumption
Consumption executes o against the sealed persistent state under ρ, in a form determined by o.act.type. SUDP distinguishes three operation classes, the semantic cases of Phase III: non-extracting use (III.1) spends the secret inside T and releases only the authorized result form to R; recipient-protected export (III.2) releases protected material only to the recipient named in o.bind and is ASU-preserving only when that recipient lies outside R’s trust boundary; and state-update / lifecycle operations (III.3) mutate protected state and are coupled to rotation. These are not deployment APIs; they are the semantic cases of Phase III consumption. All three begin with the same access step (Figure 5). III.0 Access to protected state. We write so := M [o.act.target] for the authority-bearing service secret selected by an accepted operation (e.g., the API key, OAuth token, or signing key referenced by o.act.target); so is the only secret T materializes for o, and the symbol s (Definition 3) is its abstract counterpart. Given ρ, T reconstructs the acting authenticator credential’s wrapping key from u⋆ and the stored salt ηc⋆ , unwraps K, and decrypts M : W ⋆ ← KDF(u⋆ ; ηc⋆ , DSwrap ∥ cid c⋆ ∥ ver ),
b c⋆ ), K ← UnwrapW ⋆ (K
M ← DecK (C).
⋆
The Unwrap succeeds only under a W derived from the matching salt, credential identifier, and version (per Phase I.2); the Dec call binds its AEAD associated data to the protected-state context; any failure aborts the phase without releasing plaintext, and ρ is consumed whether or not decryption succeeds. Consumption-on-abort prevents an adversary who has obtained a valid G from probing degraded state for partial successes. On success, T holds K and M within its trusted execution boundary and dispatches on o.act.type. III.1 Non-extracting consumption (type = use). The common consumption mode: T applies the authorized action to M inside its own boundary and never releases secret material from M to R. Typical instances are API-request injection (T attaches a secret drawn from M to an outgoing HTTPS request, forwards the call, and returns the remote response to R) and local cryptographic use (T signs a message using a key drawn from M and returns only the signature). The protocol guarantees that ρout contains no plaintext element of M ; the substantive content of ρout (the downstream response, signature, or derived artifact) is released under o.act.scope and Policy rather than by protocol construction, since the downstream environment’s response may itself carry sensitive or authority-amplified data. For signing operations specifically, the scope must bind the exact message 15
Requester R
Authorizer U
Env E / Rcp
Custodian T
request for o
II.1
r, {(cid c , ηc )} (o, r, {(cid c , ηc )}) out-of-band
II.2 review o; gesture on Ac⋆ compute β, sign σ ⋆ ; derive u⋆
II.2
grant G [conf.] carries u⋆
II.3
II.3 verify σ ⋆ against β ′ ; consume r; emit ρ
Phase III
III.0 derive W ⋆ ; unwrap K; decrypt M (inside T )
ρout
III.1 use
act on behalf of U
delivery π sealed for rcp
III.2 export
III.3 lifecycle
authenticity
+ confidentiality
out-of-band
commit Σ′
custodian-internal
external output
Figure 4: End-to-end online SUDP flow after Phase I setup (offline; not shown). II.1 is the public grant-request exchange (R submits o, T issues freshness r with the public hand-off tuple, R relays out-of-band to U ). II.2 is U ’s authenticator-backed gesture, producing grant G transmitted U → T over an authenticated, confidential leg. II.3 is T ’s redemption into the internal record ρ. Phase III dispatches on o.act.type into non-extracting use (result ρout back to R, action on E), recipientprotected export (sealed π opening only under sk rcp ), or lifecycle state-update (internal commit of Σ′ ). Invariants: (i) reusable authority never crosses the requester boundary—R receives only the authorized release form Release(o); (ii) T never learns any sk c ; (iii) E is not a SUDP-speaking party.
or transaction digest, the intended verifier/domain/audience, and the replay domain, so that a ρout signature is not usable outside the authorized context. This mode is the one used for non-extracting secret use; its security argument is part of Proposition 2 in §9.
III.2 Recipient-protected extracting delivery (type = export). Some operations inherently require extraction: migrating a secret between devices, provisioning a downstream service, or handing off to a specialized sub-agent. SUDP admits these under the constraint that the extracted value leaves T only in a form cryptographically protected for a named recipient. For ASU-preserving execution, a well-formed export operation requires bind.recipient to denote a party outside R’s trust boundary; if U authorizes an export with bind.recipient = R, the operation is a deliberate ownershiptransfer that falls outside SUDP’s CRC and ASU non-disclosure guarantees and must be surfaced as such at authorization time. Given pk rcp from o.bind, T uses a key-encapsulation mechanism to produce an ephemeral encapsulated key, derives a delivery key bound to the specific operation via 16
input: ρ, Σ, o custodian T boundary
III.0 unwrap K; select so := M [o.act.target]
III.1 use
III.2 export
III.3 lifecycle
ρout = Release(o) T presents so to E; R gets only the response
sealed π opens only under sk rcp
committed Σ′ K rotated; ηc⋆ advanced
Figure 5: Phase III dispatch inside the custodian T boundary. III.0 unwraps K and selects the authority-bearing service secret so := M [o.act.target]; dispatch on o.act.type then selects the consumption mode. Use: T may present so to E’s native interface but never to R; R receives only Release(o) = ρout . Export: T emits a sealed delivery π that opens only under sk rcp . Lifecycle: T commits a new sealed state Σ′ with rotated K and advanced authenticator-credential salt ηc⋆ . In all three modes, reusable authority never crosses the T boundary toward R. H(o), and seals the target: (Kd , ct d ) ← Encap(pk rcp ), kd ← KDF(Kd ; ⊥, DSdeliver ∥ H(o)), δ ← Enckd (so ; DSdeliver-ad ∥ H(o)). T emits the delivery artifact π := (ct d , δ). Only the holder of sk rcp can Decap to recover Kd , rederive kd , and open δ. Binding both the KDF info and the AEAD associated data to H(o) prevents an adversary from substituting a captured π into the transcript of a different authorized operation: any such substitution would change H(o) and fail the AEAD integrity check. When the recipient is a third party, R may act as a relay and gains no additional capability because π transits R only in sealed form. III.3 State-update / lifecycle consumption (type ∈ {write, rotate, enroll, revoke}). Operations that mutate M (writes, pure K-rotations, and lifecycle events such as credential enrollment or revocation) are structurally coupled to key rotation. A single consumption applies o to M to obtain M ′ , samples a fresh state key K ′ under which M ′ is re-sealed, and replaces the acting credential’s wrapping material with material derived from the next-salt committed in Phase II.2: $
K ′ ← CSPRNG, C ′ ← EncK ′ (M ′ ; DSstate ∥ ver ), ⋆ Wnew ← KDF(u⋆next ; ηcnext ⋆ , DSwrap ∥ cid c⋆ ∥ ver ), ′ ′ Ec⋆ ← WrapWnew ⋆ (K ). b c }) is replaced by (C ′ , {E ′ }) in its The update must be atomic as a protocol invariant: either (C, {K c entirety or neither is written. As an implementation requirement for atomicity, the new wrapping material {Ec′ } must be persisted durably before the old entries are retired; any crash between the two b c }) recoverable, never a state in which both sides have been partially steps must leave the old (C, {K overwritten. Violating this order leaves the only decryption path to K unreachable and produces an unrecoverable Σ. Multi-path recoverability requires rewrapping K ′ under each Wc for c ̸= c⋆ ; the structure of this rewrap is part of the security argument and is addressed in §5.8. 5.8
Rotation, Rewrap, and Forward Secrecy
Rotation is a protocol invariant of SUDP, not an optional discipline: every SUDP-conformant deployment advances both the wrapping epoch on every state-update and, on a deployment-defined 17
cadence, the underlying authority-bearing secret at E together with revocation of the retired secret. The first part is enforced by Phase III.3 below; the second part is mandated by the protocol’s type = rotate operation class (Phase III.3, §5.7) and its compliance requirement that authoritybearing secrets never persist beyond their rotation epoch. This section specifies the wrapping-side mechanism; the authority-side cadence is a deployment policy parameter, not a rotation-skipping option. Rotation triggers. Every state-update consumption (III.3) generates a fresh K ′ and rotates the acting credential’s salt ηc⋆ → ηcnext ⋆ . Two specialized rotation modes arise as sub-cases: • Rewrap rotates a single credential’s wrapping material without changing K or M . Its purpose is credential hygiene: advancing a credential’s salt independently of write traffic, or migrating it to new domain-separation parameters. Formally, rewrap is a III.3 execution with M ′ = M except for the Peer[cid c ] update described below. • Full rotation rotates K and the acting credential’s W , and rewraps all other credentials under the same K ′ . Formally, this is the ordinary III.3 execution with o.act.type = rotate and M ′ = M . Coupling rotation to every write tightens the wrapping-epoch forward-secrecy profile without introducing a new ceremony: any adversary who has transiently obtained pre-rotation key material is locked out of wrapped state produced after the next write. Authority-level forward secrecy additionally requires that retired authority-bearing secrets at E be revoked on the deployment’s rotation cadence; without that revocation, compromise of the current epoch confers the same authority as compromise of any prior epoch and the wrapping-side forward secrecy is meaningless against E. Forward secrecy. Let rotc⋆ (t) denote the most recent time t′ ≤ t at which credential c⋆ performed a state-update. The following claim is instantiated by SUDP’s per-write discipline. Lemma 1 (Per-authenticator-credential wrapping forward secrecy). For any credential c⋆ and (t′ ) (t′ ) (t′ ) any t′ < rotc⋆ (t), compromise of the tuple (yc⋆ , uc⋆ , Wc⋆ ) does not enable recovery of K or M from Σt , under the PRF security of Ac⋆ , the key-hiding property of KDF, and the key-unforgeability of Wrap. is sampled inside the rotation gesture from a fresh Proof sketch. At rotc⋆ (t), the next-salt ηcnext ⋆ CSPRNG draw, independent of all prior salts. Under the PRF security of Ac⋆ , the PRF output on ηcnext is indistinguishable from random given any number of PRF outputs under distinct prior ⋆ (t′ ) salts; hence the compromised yc⋆ carries no information about the post-rotation ycnew ⋆ . The domainnew separated KDF propagates this indistinguishability to unew c⋆ and Wc⋆ . Finally, the wrapped entry in Σt is under Wcnew ⋆ , so no efficient adversary holding only pre-rotation state can unwrap. Forward secrecy in SUDP is therefore per-credential: the claim holds only for credentials that have rotated at least once after the compromise window. A credential that is registered but never participates in a state-update (a dormant credential) retains its initial salt indefinitely, and historical PRF capture, if it ever occurred, remains useful against that credential’s wrapping entry. This is intrinsic to any-of-N authorization without a global ceremony; we disclose it as a residual limitation in §9. Default recoverability policy. In multi-credential SUDP deployments, Phase III.3 by credential c⋆ must rewrap K ′ under {Wc }c̸=c⋆ . The default construction adopts an in-state peer map Peer := {cid c 7→ Wc }c∈Creds ⊆ M, which III.0’s decryption of C transiently exposes to T . Under this policy, III.3 completes by ⋆ rewrapping Ec′ ← WrapWc (K ′ ) for each c ̸= c⋆ , updating Peer[cid c⋆ ] := Wnew , and sealing: Σ′ := (C ′ , {(cid c , ηc′ , Ec′ )}c∈Creds , Reg, ver ), with ηc′ ⋆ = ηcnext and ηc′ = ηc for c ̸= c⋆ . ρ is marked consumed; as an implementation hardening ⋆ note, T zeroizes K, K ′ , all W values, u⋆ , u⋆next , and M after persistence. Peer-map limitation. A single credential compromise transiently exposes the current {Wc }; a captured peer Wc unwraps every post-exposure III.3 rewrap of K ′ under Wc until c itself rotates. Only after 18
User U + authenticator Ac reviews o, signs β
Requester R model-steerable boundary
grant G (cross-device)
tool runtime
Custodian T tool call
observation
propose o
redeems G, spends s sealed state Σ
execute(o; s)
Environment E (outside protocol)
LLM
result ρout
Figure 6: The secret-use interface specialized to an agentic deployment. Inside R, the tool runtime and the LLM form a standard agentic loop; either layer can originate a request, but both go through the same uniform interface and neither receives the secret s. The user U (with authenticator Ac , typically on a separate device) reviews o and signs β; the custodian T redeems the resulting grant G and executes o at E on U ’s behalf. R receives only the release form ρout authorized by o; reusable authority over s never crosses R’s boundary. each peer c performs its own rotation does Lemma 1 close the gap for that peer. This is disclosed as a residual limitation in §9. Alternative recoverability policies (all-present rotation, append-only catch-up chain) and their tradeoffs against the default are discussed as a design choice in §8. Lifecycle extensions: enrollment and revocation. Credential addition and removal are ordinary III.3 executions with o.act naming the credential affected and M ′ encoding the change. Enrolling a credential c+ proceeds in two coupled user-verified gestures bundled into one operation: an enrollment gesture on Ac+ that yields (cid c+ , pk c+ , ηc+ , uc+ ), and the acting-credential rotation b c+ ← WrapW (K ′ ), adds gesture on Ac⋆ that authorizes the write. T derives Wc+ , computes K c+ b c+ ) to Σ′ , and updates Peer[cid c+ ] := Wc+ . Revocation removes the target credential (cid c+ , ηc+ , K from Reg, from the wrapping set, and from Peer, and reseals M ′ under a fresh K ′ . Neither operation requires machinery beyond what has already been specified.
6
Secret-Use Interfaces for Agentic Systems
This section specializes the secret-use interface induced by Agent Secret Use (§3.1) to agentic systems. The central thesis is a contract change: in an agentic system, an authority-relevant action should be operation proposal, not secret retrieval. SUDP is not an agent architecture—it does not prescribe a planner, memory system, sandbox, tool scheduler, or policy engine; it specifies the cryptographic backbone that lets an agent propose an authority-relevant operation, lets the user authorize that operation, and lets the custodian spend the secret only for the accepted use, while the requester never receives reusable authority. Figure 6 gives the structural view. The remainder of this section instantiates the interface against the agentic execution boundary (§6.1), the tool-call compilation step (§6.3), the approval-and-execution invariants the interface preserves (§6.4), and the prompt-injection threat model (§6.5). 6.1
The Model-Steerable Requester Boundary
In an agentic deployment, R is not merely the language model. R is the model-steerable execution boundary: the LLM’s context, planner, and scratchpad; agent-visible memory; the tool scheduler and dispatching shims; tool clients (including MCP-style brokered tool runtimes); agent-readable traces and logs; and any code path whose behavior can be influenced by model outputs, prompt injection, tool-side content, or attacker-controlled observations. The custodian T and the user U (with U ’s 19
authenticator) remain outside this boundary. Treating R as the full model-steerable boundary—rather than the LLM alone—is what lets the analysis cover modern agent threat models in which compromise propagates through tool outputs, scratchpad rewriting, retrieval contamination, and runtime shims, not just through the model’s parameters. 6.2
Operation Proposal, Not Credential Retrieval
The agentic specialization is a contract change at the requester boundary: operation proposal, not secret retrieval. Where the prevailing pattern lets the agent runtime obtain reusable authority and then decide how to spend it, SUDP inverts the order: R proposes an operation o ∈ OE , U authorizes o, T spends s on the accepted o, and R receives only the release form authorized by o. Compactly, R ⇝ o ∈ OE , U ⊢ o, T : (o, G, Σ) 7→ ρout , R ̸← s. The contract is the conceptual point; the engineering name a deployment chooses for the proposal call is incidental. Scope of secrets. SUDP applies to user-authority secrets: secrets whose use exercises authority on behalf of U at E. Service-internal infrastructure secrets—an operator-owned model-provider key whose only purpose is to run the platform—represent a separate principal’s authority and lie outside Agent Secret Use unless the deployment intentionally models them as protected user authority. SUDP therefore does not require a per-call user gesture for every model-provider request; it requires one only for secret uses that exercise U ’s authority at an external environment. 6.3
Compiling Tool Calls into Secret-Use Operations
Agent-generated tool calls and natural-language intents are not authorization objects. A tool-specific adapter compiles a proposed call into a canonical operation o. Per §5.3, the adapter has four responsibilities: (i) identify the authority-relevant fields of the call; (ii) canonicalize them into o; (iii) produce the trusted rendering Render(o) shown to U ; and (iv) define the deterministic execution mapping from accepted o to the native call at E. The first responsibility is per-tool—a schema design choice—while the remaining three reuse the protocol-level invariants of §5.3. The schemas are typically terse. Three illustrative cases: • GitHub. type=use; target= GitHub token; scope=(method, repo, endpoint, branch, body_hash). • Email. type=use; target= mailbox credential; scope= (send, to, cc/bcc, subject_hash, body_hash, attachment_hashes). • Cloud API. type=use; target= cloud credential; scope= (service, region, action, resource_arn, request_body_hash, idempotency_key). These are schemas only; adapter implementation, a declarative service registry, or a manual specification are realization choices outside the protocol abstraction. The completeness condition of §5.3 fixes the obligation: any field that can affect the authority exercised at E must be in the schema, or it falls outside SUDP’s operation-binding guarantee. 6.4
Approval and Execution Invariants
A SUDP-enabled agentic system maintains five interface invariants beyond the abstract protocol contract. Commit-before-approval. All authority-relevant execution inputs must be represented or committed in o before U ’s gesture. The user authorizes a closed object, not an open intent. A concrete binding may realize this by storing a request shadow at proposal time and replaying only frozen bytes at execution time; this is illustrative, not protocol-required. No post-approval authority injection. After redemption, R cannot supply authority-relevant fields— endpoint, body, recipient, or headers that affect authority—that were not already represented in o. Per §5.3, the native action at E must be a deterministic function of o, the protected material released inside T , and any o-committed payload. One-shot execution. An approved use is a one-shot continuation bound to the accepted o, not a reusable session token. This is the operational form of use-boundedness (Definition 3(c)). 20
Custodian-selected authority. The authority used at E is selected by T from o and the protected state. R-supplied Authorization headers, x-api-key headers, or body-embedded credentials must be stripped before T injects the real secret; otherwise R could escalate by smuggling reusable material past the authorization boundary. Plane separation. A SUDP-enabled agentic system has at least three authentication planes: (i) user-session authentication, which gates UI/service-account access; (ii) protocol authorization, which authorizes a specific secret-backed use through the SUDP grant path; (iii) runtime identity, which authenticates service instances, custodians, or routing components. These planes must not substitute for one another: a user-session cookie must not authorize Phase III, a runtime identity must not authorize user-facing secret use, and a protocol authorization artifact must not authorize runtime lifecycle operations. Confusing them collapses the agentic boundary the rest of the interface depends on. Routing/orchestration boundary. Routing or scheduling components that may sit between R, U , and T (delivering grants, polling pending operations) are not authorization authorities: they may carry operation proposals, grants, or pending handles, but they must not authorize Phase III and must not hold K, any Wc , plaintext M , or reusable authority-bearing material. A protocol-level adversary controlling such a component can delay or drop messages but cannot recover any secret. 6.5
Security Semantics Under Prompt Injection
The interface yields a stable answer to the question “what does SUDP guarantee when R is fully compromised?” Trace: 1. Tool-side content or injected instructions compromise R. 2. R attempts to exfiltrate or misuse s. 3. Under SUDP, R cannot read s or any reusable artifact derived from s (Definition 3(d)). 4. R can at most propose some adversarial obad to T . 5. R cannot replay an old grant against obad : redemption consumes r and verifies σ ⋆ against β = H(DSbind ∥ r ∥ H(o)). 6. R cannot substitute obad for an already-approved o: tampering changes β and fails Phase II.3. 7. T executes only the accepted, committed o; commit-before-approval and no post-approval injection bound what R can attach. 8. If U approves a dangerous-but-correctly-rendered obad , SUDP does not prevent the action. Punchline. SUDP does not make compromised agents benign; it turns secret-backed actions by compromised agents into explicit, user-witnessed, bounded operation proposals. What is not solved. Dangerous-but-correctly-rendered obad ; trusted-rendering failures that hide authority-relevant fields from U ; downstream response leakage through ρout (a deployment-policy concern, not a protocol property); T runtime compromise during consumption (CMC, deferred to TEE composition); and incomplete adapter schemas that leave authority-relevant fields outside o. Composition. Runtime monitors, policy DSLs, taint tracking, and sandboxes reason about R’s behavior. SUDP assumes R may already be compromised and constrains what secret-backed authority remains exercisable through the secret-use boundary; §4 positions these defenses as complementary rather than substitutive. Multiplicity policy. Deployments may layer batching or TTL-scoped approvals only when the batch scope is itself represented and rendered in o; otherwise the single-use guarantee silently weakens.
7
Standard Construction
§6 specialized the secret-use interface to agentic systems. This section gives the standards-based cryptographic instantiation of the protocol primitives: each abstract interface of §5 is fixed to a standardized component, and Phase II’s authenticated-channel assumption (§5.6) is realized concretely. §7.1 covers primitive selection layer by layer; §7.2 gives the cross-device channel instantiation when U and T are not co-located. The construction introduces no new cryptographic assumption. 21
7.1
Primitives
Authenticator and user-mediated authorization. The abstract protocol requires a tamper-resistant module Ac that (i) signs a challenge under user verification and (ii) emits an authenticator-bound pseudo-random value that is scoped per credential. We instantiate Ac with WebAuthn credentials using the PRF extension [Balfanz et al., 2021, FIDO Alliance, 2024]. Under this profile, the abstract σ ← Sigsk c (β) interface is realized by a WebAuthn assertion produced with challenge = β, and the corresponding Vrfy check covers not only the ECDSA-P256 signature but also the assertion’s rpId hash, origin, user-verification flag, and credential-ID binding; a signature-verification success without these structural checks does not satisfy the Sig interface in this profile. The authenticatorbound pseudo-random value is realized by the WebAuthn PRF (hmac-secret) extension with a per-credential salt; credentials or assertions whose response does not contain the PRF output are rejected by the profile. Two standards-compliance implications are worth noting: (a) binding PRF output to a passkey means deletion of the passkey implies loss of access to any data encrypted under the derived key; (b) per-credential PRF salts support domain separation across credentials. Key schedule. The abstract protocol requires a KDF that supports extract-then-expand semantics and domain separation. We instantiate KDF with HKDF-SHA-256 [Krawczyk and Eronen, 2010], following NIST SP 800-56C key-derivation guidance [Chen, 2020]. Domain separation is achieved by encoding a disjoint DS⋆ label in the info argument of each derivation; this is sufficient to ensure that distinct derivations produce independent keys under the hash-function random-oracle idealization. Sealing and key wrapping. Enc/Dec is instantiated with an AEAD scheme (AES-GCM [Dworkin, 2007] or XChaCha20-Poly1305 [Bernstein et al., 2012]), and the AEAD’s associated-data input carries the DS⋆ label together with the version identifier ver . For (Wrap, Unwrap), SUDP binds wrapping context through the derivation of W rather than through an explicit parameter to Wrap. Because Wc ← KDF(uc ; ηc , DSwrap ∥ cid c ∥ ver ) already embeds the credential identifier, salt, and version (§5.2), the interface can be instantiated directly as AES-KW/KWP [Dworkin, 2012, Schaad and Housley, 2002, Housley et al., 2009] wrapping K under Wc without associated data. Profiles that prefer AEAD-as-wrap may additionally authenticate the same domain-separation labels as associated data, yielding the same abstract contract. Recipient-protected extraction. For Phase III.2, the abstract protocol requires a KEM that admits a recipient-specific encapsulation. We instantiate (Encap, Decap) with HPKE [Barnes et al., 2022] rather than an ad-hoc ECIES construction [Abdalla et al., 2001]: HPKE provides a standardized hybrid encryption interface with clear security properties and parameter choices, and it composes cleanly with HKDF-based domain-separation labels. Transport. Pairwise communication runs over TLS 1.3 [Rescorla, 2018]. TLS supplies the authenticated and confidential channel assumed by Phase II on the U → T leg, not a cryptographic layer we extend. Neither TLS session keys nor TLS peer identities enter the protocol’s cryptographic commitments: all protocol-level binding is at the application layer. When U and T do not share a live TLS session, Phase II’s channel assumptions (authenticity and confidentiality) are realized by the cross-device handshake of §7.2. Sender-constraining view of the grant. The grant G is a sender-constrained authorization token in the sense of DPoP [Fett et al., 2023]: the signature σ ⋆ binds the challenge β (which commits to H(o) and the per-grant freshness token r) to the per-credential signing key sk c⋆ . Viewed through this lens, II.4’s anti-substitution property is the sender-constraining property instantiated for user-mediated authorization, and II.3’s signature verification plus single-use consumption of r from S is the standard grant-binding check. Table 2 maps each abstract requirement to its concrete realization. 7.2
Cross-Device Channel Instantiation
When U and T do not share a live TLS session (the agent runs on hosted infrastructure while the user is on a phone, for example), Phase II’s channel assumptions (authenticity and confidentiality) must be realized by an alternative transport. This profile is transport-only: it does not modify the 22
Table 2: SUDP concrete profile: abstract requirements and their standard-component instantiations. Abstract requirement
Realization
Reference
Tamper-resistant module Ac ; user-verified Sig, PRF Hash H KDF (extract-and-expand, domain separation) AEAD Enc/Dec
WebAuthn with PRF extension; ECDSA-P256 SHA-256 HKDF-SHA-256
[Balfanz et al., 2021, FIDO Alliance, 2024, NIST, 2013] n/a [Krawczyk and Eronen, 2010, Chen, 2020] [Dworkin, 2007, Bernstein et al., 2012] [Dworkin, 2012, Schaad and Housley, 2002, Housley et al., 2009] [Barnes et al., 2022]
Key wrap Wrap/Unwrap KEM Encap/Decap Authenticated channel (U ↔T ) Sender-constraining view of G
AES-GCM or XChaCha20-Poly1305 AES-KW / AES-KWP (or AEAD-as-wrap) HPKE (DHKEM-P256 / HKDF-SHA-256 / AEAD) TLS 1.3, or cross-device handshake (§7.2) DPoP-style PoP binding
[Rescorla, 2018] [Fett et al., 2023]
abstract Phase II grant. The signed authorization evidence inside G is still σ ⋆ = Sigsk c⋆ (β) over β = H(DSbind ∥ r ∥ H(o)) (§5.6); the cross-device profile only provides a confidential channel that delivers G intact from U to T . Authenticated key agreement is required for confidentiality. Confidentiality of u⋆ (carried inside G) is security-critical: ηc is public, so any party that observes u⋆ can recompute W ⋆ (and, with b c , C) from Σ, decrypt M ). A naïve unauthenticated ECDH admits an persistent wrapped state (K active man-in-the-middle: an adversary substituting its own pkM for pkT causes U to derive a shared secret with the adversary and AEAD-encrypt G under a key the adversary controls. U must therefore verify that T ’s ephemeral public key pkT belongs to the intended custodian. A concrete profile may obtain this authenticity by (a) a signature on pkT under a long-term T -instance key whose public counterpart is provisioned to U ’s trusted client at registration; (b) binding pkT to an existing authenticated session between U ’s client and the orchestration service that issued the cross-device link—provided the orchestration service is trusted for custodian-key binding (this caveat matters: if the deployment treats orchestration as adversarial, as in the plane-separation invariant of §6.4, this option is unavailable); (c) an out-of-band channel integrity-protected against substitution (e.g., a QR code displayed on a console authenticated to U ); or (d) a mutually authenticated PAKE or equivalent. The handshake below assumes authenticated pkT ; without it, the confidentiality argument does not apply. Construction. U and T generate ephemeral ECDH key pairs, derive a shared secret ss, and use it to derive a session AEAD key kxd : (skU , pkU ) ← ECDH.Gen, (skT , pkT ) ← ECDH.Gen, ss ← ECDH.Derive(skU , pkT ) = ECDH.Derive(skT , pkU ), kxd ← KDF(ss; r, DSxd-enc ∥ pkU ∥ pkT ). U constructs the abstract grant G = (o, r, cid c⋆ , u⋆ , σ ⋆ , opt) exactly as in §5.6, AEAD-encrypts it as ct G ← Enckxd (G; ad) with ad = H(pkU ∥ pkT ∥ r), and transmits (pkU , ct G ) as a CBOR envelope. T derives kxd from ss, authenticates the same ad, decrypts G, and runs the abstract Phase II.3 redemption against σ ⋆ and β unchanged. The cross-device leg supplies confidentiality (AEAD under kxd ) and channel-binding (AEAD AD over pkU ∥ pkT ∥ r); it does not supply authorization—authorization remains σ ⋆ inside G. A relay that captures ct G cannot reuse it: r is consumed at T on first redemption, so a replay fails Phase II.3 step 1; substitution of o inside G fails σ ⋆ verification at step 3. Under the authenticity precondition on pkT , the handshake does not require a live TLS tunnel between U and T ; without it, the confidentiality of u⋆ on the U → T leg is not guaranteed.
8
Design Rationale
Several design decisions in SUDP are consequential but local: a reader who sees them in isolation may reasonably ask why each was taken. We consolidate the architectural-level choices here. Small 23
construction-local decisions (domain-separation strings, concrete primitive selections) are discussed inline at the point of construction. Single-use authorization committed to H(o). The redeemed grant ρ is cryptographically bound to a specific operation via H(o) and consumed on first use, rather than being a bearer or scoped capability valid for many actions. This lifts anti-replay and anti-substitution from engineering discipline (TTLs, revocation lists, nonce tracking in each tool) to protocol-level guarantees: any captured artifact, within any time window, is redeemable only against the exact operation it was signed for. The cost is a per-action user-verification gesture; we consider this cost acceptable because SUDP targets high-authority secrets whose misuse already warrants human oversight per action, and because standardized authenticators (WebAuthn platform/security keys) make the gesture sub-second. Authenticator-bound PRF for wrapping material. Wrapping keys are derived from authenticatorbound PRF outputs (yc = Ac .PRF(ηc )) rather than from passwords, server-held master keys, or envelope-encryption KMS services. The unlock material therefore lives exclusively in the user’s authenticator hardware: neither the server’s persistent state nor its runtime memory can reconstruct a wrapping key without a live user gesture. This is what distinguishes SUDP’s satisfaction of CSB from schemes whose “encrypted at rest” claim collapses when an attacker captures the server together with its unlock material (§4). The cost is a WebAuthn-capable authenticator as a deployment prerequisite; this is now a commodity assumption in agent-capable user environments. Recoverability inherited from the authenticator. A SUDP profile inherits the recoverability semantics of its authenticator family: if all enrolled credentials are lost, M becomes unrecoverable through SUDP. Deployments that need recovery must provision it as an additional enrolled credential—a recovery passkey, a second hardware authenticator, or an enterprise-controlled escrow credential whose use is itself an SUDP-authorized lifecycle operation—not as a backend master-key bypass, which would surrender CSB. Recoverability policy: why in-state peer map is the default. Each enrolled credential has its own wrapping key Wc , and Phase III.3 by one credential must rewrap the new K ′ under every peer’s Wc (§5.8). Three policies can satisfy this requirement; Table 3 summarizes their tradeoffs. The default—in-state peer map—preserves single-gesture rotation in an any-of-N setting, which is operationally useful for agent workflows that rotate on every write, at the cost of a transient exposure of the current {Wc } to T and a forward-secrecy gap for any peer credential that has not itself rotated since that exposure. The all-present alternative removes the peer-map exposure but forces every credential to be online at every rotation, which is ill-suited to continuous agent workflows. The append-only chain avoids both and supports offline catch-up, but does not provide forward secrecy against historical-key compromise: any captured Kj walks the chain forward. Deployments with stronger cross-credential isolation requirements may substitute all-present, or adopt append-only as an offline-catchup auxiliary whose FS implications are understood. Table 3: Recoverability policies for multi-credential SUDP. The default is the in-state peer map; the other two are available as substitutes when their tradeoffs match deployment needs. Policy
Online gestures
Extra storage
Peer-key exposure
FS profile
In-state peer map (default) 1 (single-gesture) O(|Creds|) in M transient during III.0 Lemma 1 per credential, after c rotates All-present rotation all credentials none none Lemma 1 per credential, independently Append-only chain 1 (single-gesture) unbounded (chain grows) none not FS: old Kj walks forward
Negative space in the channel-binding hash. The binding hash β = H(DSbind ∥ r ∥ H(o)) deliberately omits the custodian’s identity, the server’s TLS certificate hash, and cid c⋆ . The first two are already committed by the channel carrying the grant; cid c⋆ appears in σ ⋆ ’s signed message via the WebAuthn assertion structure [Balfanz et al., 2021]. Re-binding fields already bound elsewhere trades clarity for bloat, and β follows standard key-exchange transcript discipline of carrying only what the surrounding structure does not already commit [Krawczyk, 2005, Rescorla, 2018]. Rotation as a protocol invariant. SUDP treats rotation as a protocol invariant rather than an operator discipline. Every Phase III.3 state-update advances the wrapping epoch by sampling fresh K ′ and a fresh next-salt ηcnext (§5.8); on the deployment-defined cadence at which E supports it, the ⋆ 24
underlying authority-bearing secret is also rotated and the retired secret revoked. This separation lets the protocol claim wrapping-epoch isolation unconditionally under key-erasure assumptions (Proposition 4, Lemma 1), while authority-level forward secrecy depends on E-side revocation support (Proposition 5). The cost of the per-write wrapping advance is a modest increase in per-write work (one extra CSPRNG draw, one key derivation, |Creds| rewrap operations); we consider this marginal relative to the forward-secrecy dividend, particularly for agent workflows whose write volumes are typically low per user.
9
Security Analysis
We state SUDP’s security as a single main theorem (SUDP solves the Agent Secret Use problem), parameterized by explicit assumptions (§9.2) and three named interface preconditions (§9.2). The proof decomposes into five propositions (§9.4); a corollary (§9.5) maps the result back to the seven taxonomy axes. Proofs are sketched; a mechanized analysis in a tool such as Tamarin [Meier et al., 2013] or ProVerif [Blanchet, 2001] is left to future work. 9.1
Security Statement and Allowed Leakage
Informally, SUDP solves the Agent Secret Use problem against any adversary controlling R and all requester-visible or non-trusted routing infrastructure: every Phase III execution is covered by a fresh, U -rooted, operation-bound, single-use grant, and R’s view across all sessions is restricted to public proposal material plus the explicitly authorized release form Release(o), defined as follows. Definition 6 (Allowed release). For an accepted operation o, Release(o) is a profile-defined polynomial-time release function (or distribution) the custodian T computes from the bounded action’s effect at E under o. Concretely it covers the response ρout for non-extracting use (governed by o.act.scope and Policy), the recipient-sealed delivery π for export (opening only under sk rcp ), or the commit confirmation for state-update. A conformant Release(o) may include authorized downstream content but must not include reusable authority-bearing material or transferable artifacts derived from it. Non-exposure is modulo Release(o). SUDP’s requester non-exposure claim is bounded by Release(o) of the operations R actually causes: the protocol guarantees that R’s view consists of public proposal material and Release(o) of accepted operations, not that Release(o) itself is nonsensitive. A profile that defines Release(o) to expose reusable authority (e.g., echoing the secret in ρout ) is non-conformant and falls outside the theorem. What SUDP does not claim. SUDP does not protect against semantic content of a conformant Release(o) (an authorized downstream API response may itself be sensitive, which is a deploymentpolicy concern); against trusted-rendering failures that hide authority-relevant fields from U (P2); against descriptors with insufficient field coverage (P1); against runtime-memory compromise of T during the unwrap-use-zeroize window (CMC, deferred to TEE composition); or against U approving a dangerous-but-correctly-rendered descriptor. 9.2
Assumptions and Interface Preconditions
Assumptions. (A1) EUF-CMA security of the signature scheme Sig. (A2) IND-CCA security of the AEAD scheme. (A3) PRF security of the authenticator Ac (WebAuthn PRF extension). (A4) Collision resistance of H combined with deterministic, injective canonical serialization of o. (A5) IND-CCA2 security of the KEM (HPKE). (A6) Authenticated and confidential channel U → T for the leg carrying u⋆ (TLS 1.3, or the crossdevice profile of §7.2 under its authenticated-key precondition). (A7) Single-use freshness-state integrity at T : r is consumed exactly once, and S is not adversarially modified between issuance and redemption (no T memory compromise during the gesture). 25
(A8) (Conditional, used only by Proposition 5.) E supports rotation and revocation of authoritybearing secrets on the deployment’s rotation cadence. Interface preconditions. (P1) Canonical Operation Completeness. Every authority-relevant field of the action exercised at E is represented in o.act.scope, o.bind, or o.valid (§5.3). (P2) Trusted Rendering Faithfulness. Render(o) at U is deterministic, complete with respect to the fields in o, and produced inside U ’s trusted client (§5.3). (P3) Execution Determinism. The native call performed at E by T is a deterministic function of accepted o, the protected material released inside T , and any o-committed payload; R cannot supply authority-relevant fields after redemption (§5.3). 9.3
Main Theorem
Theorem 1 (SUDP solves the Agent Secret Use problem). Under the listed assumptions (A1–A7) and interface preconditions (P1–P3), SUDP solves the Agent Secret Use problem (Definition 3) for any adversary controlling R and all requester-visible or non-trusted routing infrastructure, while the U → T grant channel satisfies the authenticity and confidentiality assumptions stated in (A6). Concretely: 1. Every Phase III execution admitted by T is covered by a fresh, U -rooted, operation-bound, single-use grant (Definition 3(a–c)); 2. R’s view across all sessions consists of public proposal material and Release(o), and excludes any reusable authority-bearing material or transferable artifact (Definition 3(d)); 3. SUDP additionally provides storage confidentiality (CSB) and wrapping-epoch key isolation (RFS-wrap) under stated sealing and erasure assumptions; plaintext-level forward secrecy of the authority-bearing secret requires Proposition 5. Authority-level forward secrecy (RFS-auth) holds under the further assumption (A8). Runtimememory confidentiality of T during the unwrap-use-zeroize window (CMC) is out of scope; it is the natural composition target for TEE-backed custodians. The proof decomposes into five propositions that together discharge Theorem 1: Proposition 1 for item 1 and the AV/OB/RR axes; Proposition 2 for item 2 and the CRC/CSB axes; Proposition 3 for the ASU-preserving export case; Proposition 4 for item 3’s RFS-wrap; and Proposition 5 for the conditional RFS-auth. 9.4
Supporting Propositions
Proposition 1 (Authorization Integrity: AV ∧ OB ∧ RR). Under (A1, A4, A7) and (P1–P3), every Phase III execution that T admits carries a signature σ ⋆ verifiable as a U -rooted authenticator assertion under Reg[cid c⋆ ] over β = H(DSbind ∥ r ∥ H(o)) (AV); no valid grant admits any o′ ̸≡E o (OB); and no (r, o, σ ⋆ ) triple admits two Phase III executions (RR). Proof sketch. Phase II.3 (§5.6) verifies VrfyReg[cid c⋆ ] (β ′ , σ ⋆ ) = 1 and consumes r from S before any Phase III execution. AV: under (A1), only the holder of sk c⋆ (i.e., U via Ac⋆ ) can produce a σ ⋆ accepted by this check; Reg[cid c⋆ ] is public, so any auditor with the transcript can re-run the verification. OB: under (A4) and (P1), if any o′ ̸≡E o is presented, the recomputed β ′ diverges from the signed β and verification fails; (P2) ensures U authorized the canonical o that T validates, so the user cannot be tricked into authorizing one operation while T executes another; (P3) prevents R from injecting authority-relevant fields after redemption. RR: under (A7), r is consumed once by T ’s freshness state, so the same triple cannot redeem twice; under (A1), no fresh σ ⋆ on a new r can be forged without sk c⋆ . Proposition 2 (Requester Non-Exposure and Storage Confidentiality: CRC ∧ CSB). Under (A2, A3, A6), the trust model of §3.1, and a conformant Release(o) (Definition 6), R’s view across all sessions is bounded by public proposal material and Release(o) of accepted operations; it contains 26
no value from which s, K, Wc , uc , or so can be recovered (CRC). Independently, an adversary obtaining the full persistent state Σ without a live user-verified Ac invocation cannot recover M (CSB). b c }, {ηc }, Reg}; K and {Wc } materialize only Proof sketch. CRC: Σ exposes only public {C, {K inside T under a user-verified gesture. R observes the public hand-off (o, r, cid c , ηc ) and Release(o); under (A6), the U → T leg of G is confidential, so R never observes u⋆ . σ ⋆ is public authorization evidence and its visibility to R is immaterial: redemption requires the matching unconsumed r and the secret u⋆ , neither of which R obtains. CSB: recovering M from Σ requires K, hence some Wc , hence uc , hence yc = PRFc (ηc ); under (A3), no efficient adversary without a fresh Ac invocation can produce yc ; under (A2) and key-wrap security, the AEAD/key-wrap ciphertexts hide the underlying plaintext from any party without the key. Proposition 3 (Recipient-Protected Export). Given an accepted operation o satisfying Proposition 1, and under (A5, A2), for any ASU-preserving Phase III.2 execution (a well-formed o whose bind.recipient identifies a principal outside R’s trust boundary), the delivery π reveals nothing about so to any party other than the holder of sk rcp . Proof sketch. π = (ct d , δ) couples an IND-CCA2 KEM ciphertext under pk rcp with an AEAD ciphertext under kd , derived from the KEM output and committing to H(o). Without sk rcp , π reveals nothing about so under (A5) and (A2). Recipient substitution fails because pk rcp is in o.bind, hence in β; changing it invalidates σ ⋆ (Proposition 1). A grant whose recipient names R itself is a deliberate ownership transfer outside ASU non-disclosure (§5.7). Proposition 4 (Wrapping-Epoch Key Isolation). Under (A2, A3), CSPRNG independence of fresh draws, and erasure of retired epoch keys, a Phase III.3 update yields wrapping-epoch key isolation: ⋆ the post-rotation keys (K ′ , Wnew ) are computationally independent of the pre-rotation keys (K, Wc⋆ ); compromise of either epoch’s keys does not enable deriving the other epoch’s keys or decrypting retained ciphertexts encrypted under the other epoch’s key. Proof sketch. K ′ is sampled fresh and independent of K (CSPRNG); under (A2), ciphertexts under K ′ are indistinguishable from random given any number of K-decryptions, and symmetrically for ⋆ ciphertexts under K given K ′ -decryptions. Wnew is derived through the chain PRFc⋆ → KDF → KDF rooted in a fresh next-salt ηcnext ⋆ ; per Lemma 1 (per-credential FS), the chain breaks the derivation link in both directions. The claim applies to credentials that have actually rotated; dormant-credential and peer-map limitations are L3 and L4 below. Plaintext caveat. Wrapping-epoch key isolation does not by itself protect plaintext values that are intentionally carried forward across rotations. The rewrap and pure-rotate sub-cases of Phase III.3 explicitly preserve M ′ = M (§5.8); under those operations, the plaintext present in current state equals the plaintext recoverable from the previous state, so an adversary who decrypts either epoch’s ciphertext recovers the same M . Plaintext-level forward secrecy of authority-bearing material requires either (i) a Phase III.3 update that retires the prior secret in M , or (ii) composition with E-side authority rotation (Proposition 5), which decouples plaintext continuity from authority continuity. Proposition 5 (Authority-Level Forward Secrecy under E-side rotation). Under (A8) in addition to the assumptions of Proposition 4, compromise of one epoch’s authority-bearing secret at E confers no authority over operations executed in any other epoch. Proof sketch. By (A8), each epoch executes against an authority-bearing secret issued for that epoch and revoked at the next rotation. Authority over a retired epoch therefore requires a secret E no longer accepts; the same argument runs in reverse for a current-epoch operation under a retired secret. Combined with Proposition 4’s wrapping-side forward secrecy, authority is bounded to its issuing epoch. Without (A8), the claim degrades to wrapping-epoch isolation only. 27
Table 4: Taxonomy-axis coverage. Theorem 1 provides the headline guarantee; each axis is discharged by one of the supporting propositions, with explicit assumption dependencies. Axis
Discharged by
Key assumptions
AV (Authorization Verifiability) OB (Operation Binding) RR (Replay Resistance) CRC (Requester Compromise) CSB (Storage Breach) RFS-wrap (Wrapping epoch) RFS-auth (Authority epoch)
Prop. 1 Prop. 1 Prop. 1 Prop. 2, Prop. 3 Prop. 2 Prop. 4 Prop. 5
A1, A4, P1–P2 A1, A4, P1–P3 A1, A7 A2, A3, A5, A6 A2, A3 A2, A3, key erasure A2, A3, A8 (conditional)
CMC (Runtime Memory)
out of scope (L1)
TEE composition
9.5
Corollary: Taxonomy-Axis Coverage
9.6
Residual Limitations
Four limitations are explicit in the design and should be disclosed to any deployment. (L1) Runtime compromise during consumption. A fully compromised T runtime during legitimate consumption exfiltrates plaintext by construction: III.0 materializes K and M inside T ’s memory, and no protocol-level mechanism prevents code executing inside T from reading them. Composition with confidential-computing runtimes is the natural remediation. As a defense-in-depth note (not a protocol-level guarantee), a deployment can narrow exposure to the unwrap-use-zeroize critical section by zeroing K, W ⋆ , u⋆ , and any derived plaintext immediately after use, disabling swap and core dumps for T , and gating against memory inspection by co-tenant processes; only TEE composition closes CMC. (L2) Authenticator compromise. A fully compromised authenticator Ac⋆ reduces Phase II.2 to adversary-controlled authorization; authenticator security (A3) is an assumption, not a protocol-level property. (L3) Dormant-credential forward-secrecy gap. Lemma 1’s forward secrecy is per-credential and activates only after a credential rotates. A credential that is registered but never participates in a stateupdate retains its initial salt indefinitely; historical PRF capture, if it ever occurred, remains useful against its wrapping entry until the credential is exercised. This is intrinsic to any-of-N authorization without a global ceremony; deployments should track per-credential last-rotation timestamps and drive scheduled rewrap under the in-state peer-map construction (§5.8). (L4) Peer-map cross-credential exposure. Under the in-state peer-map construction, Phase III.0 by any credential c transiently exposes the current {Wc }c∈Creds to T . Compromise of one credential’s gesture yields the current wrapping keys of all peers; a captured Wc′ continues to unwrap subsequent rewraps until c′ itself rotates. Deployments requiring stronger cross-credential isolation may substitute the all-present alternative of §5.8.
10
Conclusion
Agentic workflows make secret safety a use problem, not merely a storage problem. Encrypting an API key at rest is no longer enough when the runtime that retrieves or holds it is itself model-steerable. The central question is whether an agent can be authorized to cause a secret-backed operation without ever being exposed to reusable authority over the secret. This paper answers that question with Agent Secret Use and SUDP. ASU isolates the structural separation between requesting use of authority and being exposed to reusable authority; the securityproperty taxonomy turns agent secret-security claims into comparable outcomes. SUDP realizes this separation with a user-rooted, operation-bound, single-use grant protocol: agents propose canonical operations, users authorize committed descriptors, and custodians execute bounded uses while reusable authority never crosses the requester boundary. The resulting agentic interface changes the agent contract from secret retrieval to operation proposal: agents propose operations; they do not retrieve secrets. 28
SUDP does not make compromised agents benign. It reduces their secret-backed blast radius: a compromised agent can propose a dangerous operation, but it cannot read the secret, replay an old grant, or substitute a different operation after approval. The remaining limits are explicit: trusted rendering and descriptor completeness are required preconditions; downstream responses remain deployment-policy concerns; and custodian runtime-memory compromise requires TEE or equivalent composition. Future work should formalize the protocol in Tamarin [Meier et al., 2013] or ProVerif [Blanchet, 2001], evaluate realistic approval burden and prompt-injection blastradius reduction, and study composition with confidential-computing custodians and multi-domain delegation.
References Michel Abdalla, Mihir Bellare, and Phillip Rogaway. DHIES: An encryption scheme based on the Diffie-Hellman problem. In Topics in Cryptology—CT-RSA 2001, pages 143–158. Springer, 2001. Amazon Web Services. AWS Secrets Manager: Rotate, manage, and retrieve secrets. In AWS Documentation, 2024. URL https://docs.aws.amazon.com/secretsmanager/. Anthropic. The Claude model card and evaluations. Anthropic Technical Reports, 2024. Anthropic. Claude Agent SDK: Secure deployment patterns. https://code.claude.com/docs /en/agent-sdk/secure-deployment, 2026. Anthropic and MCP Working Group. Model context protocol authorization specification. Technical report, Model Context Protocol, 2025. URL https://modelcontextprotocol.io/specific ation/draft/basic/authorization. Dirk Balfanz, Alexei Czeskis, Jeff Hodges, J.C. Jones, Michael B. Jones, Akshay Kumar, Rolf Lindemann, and Emil Lundberg. Web Authentication: An API for accessing Public Key Credentials level 2. In W3C Recommendation, 2021. URL https://www.w3.org/TR/webauthn-2/. Richard Barnes, Karthikeyan Bhargavan, Benjamin Lipp, and Christopher A. Wood. Hybrid public key encryption. RFC 9180, 2022. doi: 10.17487/RFC9180. URL https://www.rfceditor.org/rfc/rfc9180. Daniel J. Bernstein, Tanja Lange, and Peter Schwabe. The security impact of a new cryptographic library. International Conference on Cryptology and Information Security in Latin America, pages 159–176, 2012. Arnar Birgisson, Joe Gibbs Politz, Úlfar Erlingsson, Ankur Taly, Michael Vrable, and Mark Lentczner. Macaroons: Cookies with contextual caveats for decentralized authorization in the cloud. In 21st Annual Network and Distributed System Security Symposium (NDSS), 2014. Bruno Blanchet. An efficient cryptographic protocol verifier based on Prolog rules. In 14th IEEE Computer Security Foundations Workshop (CSFW), pages 82–96, 2001. Lily Chen. Recommendation for key-derivation methods in key-establishment schemes. NIST Special Publication 800-56C Rev. 2, 2020. Sizhe Chen, Julien Piet, Chawin Sitawarin, and David Wagner. StruQ: Defending against prompt injection with structured queries. arXiv preprint arXiv:2402.06363, 2024a. URL https://arxi v.org/abs/2402.06363. Sizhe Chen, Arman Zharmagambetov, Saeed Mahloujifar, Kamalika Chaudhuri, David Wagner, and Chuan Guo. SecAlign: Defending against prompt injection with preference optimization. arXiv preprint arXiv:2410.05451, 2024b. URL https://arxiv.org/abs/2410.05451. Sahana Chennabasappa, Cyrus Nikolaidis, Daniel Song, David Molnar, Stephanie Ding, Shengye Wan, Spencer Whitman, Lauren Deason, Nicholas Doucette, Abraham Montilla, Alekhya Gampa, Beto de Paola, Dominik Gabi, James Crnkovich, Jean-Christophe Testud, Kat He, Rashnil Chaturvedi, Wu Zhou, and Joshua Saxe. LlamaFirewall: An open source guardrail system for building secure AI agents. arXiv preprint arXiv:2505.03574, 2025. URL https://arxiv.org/abs/2505.03574. 29
Katriel Cohn-Gordon, Cas Cremers, and Luke Garratt. On post-compromise security. In IEEE 29th Computer Security Foundations Symposium (CSF), pages 164–178, 2016. Victor Costan and Srinivas Devadas. Intel SGX explained. IACR Cryptology ePrint Archive 2016/086, 2016. CrewAI. CrewAI: Framework for orchestrating role-playing, autonomous AI agents. https: //github.com/crewAIInc/crewAI, 2024. Asiri Dalugoda. HDP: A lightweight cryptographic protocol for human delegation provenance in agentic AI systems. arXiv preprint arXiv:2604.04522, 2026. URL https://arxiv.org/abs/ 2604.04522. Edoardo Debenedetti, Jie Zhang, Mislav Balunović, Luca Beurer-Kellner, Marc Fischer, and Florian Tramèr. Agentdojo: A dynamic environment to evaluate prompt injection attacks and defenses for LLM agents. In The Thirty-eighth Conference on Neural Information Processing Systems Datasets and Benchmarks Track, 2024. URL https://openreview.net/forum?id=m1YYAQjO3w. Edoardo Debenedetti, Ilia Shumailov, Tianqi Fan, Jamie Hayes, Nicholas Carlini, Daniel Fabian, Christoph Kern, Chongyang Shi, Andreas Terzis, and Florian Tramèr. Defeating prompt injections by design. arXiv preprint arXiv:2503.18813, 2025. URL https://arxiv.org/abs/2503.188 13. Xinhao Deng, Yixiang Zhang, Jiaqing Wu, Jiaqi Bai, Sibo Yi, Zhuoheng Zou, Yue Xiao, Rennai Qiu, Jianan Ma, Jialuo Chen, Xiaohu Du, Xiaofang Yang, Shiwen Cui, Changhua Meng, Weiqiang Wang, Jiaxing Song, Ke Xu, and Qi Li. Taming OpenClaw: Security analysis and mitigation of autonomous LLM agent threats. arXiv preprint arXiv:2603.11619, 2026. URL https: //arxiv.org/abs/2603.11619. Jack B. Dennis and Earl C. Van Horn. Programming semantics for multiprogrammed computations. Technical Report 3, Communications of the ACM, 1966. Morris J. Dworkin. Recommendation for block cipher modes of operation: Galois/Counter Mode (GCM) and GMAC. NIST Special Publication 800-38D, 2007. Morris J. Dworkin. Recommendation for block cipher modes of operation: Methods for key wrapping. NIST Special Publication 800-38F, 2012. Faouzi El Yagoubi, Godwin Badu-Marfo, and Ranwa Al Mallah. AgentLeak: A full-stack benchmark for privacy leakage in multi-agent LLM systems. arXiv preprint arXiv:2602.11510, 2026. URL https://arxiv.org/abs/2602.11510. Daniel Fett, Brian Campbell, John Bradley, Torsten Lodderstedt, Michael B. Jones, and David Waite. OAuth 2.0 demonstrating proof of possession (DPoP). RFC 9449, 2023. URL https://www.rfceditor.org/rfc/rfc9449. FIDO Alliance. CTAP2 extensions: PRF and large blob storage. In Client to Authenticator Protocol (CTAP) v2.2, 2024. URL https://fidoalliance.org/specs/fido-v2.2-ps-20250228/f ido-client-to-authenticator-protocol-v2.2-ps-20250228.html. Abhishek Goswami. Agentic JWT: A secure delegation protocol for autonomous AI agents. arXiv preprint arXiv:2509.13597, 2025. URL https://arxiv.org/abs/2509.13597. Kai Greshake, Sahar Abdelnabi, Shailesh Mishra, Christoph Endres, Thorsten Holz, and Mario Fritz. Not what you’ve signed up for: Compromising real-world LLM-integrated applications with indirect prompt injection. In ACM AISec Workshop, 2023. Dick Hardt. The OAuth 2.0 authorization framework. RFC 6749, 2012. Norm Hardy. The confused deputy: (or why capabilities might have been invented). ACM SIGOPS Operating Systems Review, 22(4):36–38, 1988. doi: 10.1145/54289.871709. HashiCorp. HashiCorp Vault: Secrets management and data protection. In HashiCorp Documentation, 2024a. URL https://www.vaultproject.io/docs. 30
HashiCorp. HashiCorp vault: AI agent identity pattern. https://developer.hashicorp.com/ validated-patterns/vault/ai-agent-identity-with-hashicorp-vault, 2024b. Keegan Hines, Gary Lopez, Matthew Hall, Federico Zarfati, Yonatan Zunger, and Emre Kıcıman. Defending against indirect prompt injection attacks with spotlighting. arXiv preprint arXiv:2403.14720, 2024. URL https://arxiv.org/abs/2403.14720. Russ Housley, Quynh Dang, and Sean Turner. Advanced encryption standard (AES) key wrap with padding algorithm. RFC 5649, 2009. Stanisław Jarecki, Hugo Krawczyk, and Jiayu Xu. OPAQUE: An asymmetric PAKE protocol secure against pre-computation attacks. In Advances in Cryptology – EUROCRYPT 2018, pages 456–486. Springer, 2018. Michael Jones and Dick Hardt. The OAuth 2.0 authorization framework: Bearer token usage. Technical Report RFC 6750, Internet Engineering Task Force, 2012. URL https://www.rfceditor.org/rfc/rfc6750. Hugo Krawczyk. HMQV: A high-performance secure Diffie-Hellman protocol. In Advances in Cryptology – CRYPTO 2005, pages 546–566. Springer, 2005. Hugo Krawczyk and Pasi Eronen. HMAC-based extract-and-expand key derivation function (HKDF). RFC 5869, 2010. LangChain. LangChain: Building applications with LLMs through composability. https://gith ub.com/langchain-ai/langchain, 2024. Ninghui Li, Kaiyuan Zhang, Kyle Polley, and Jerry Ma. Security considerations for artificial intelligence agents (perplexity response to NIST/CAISI request for information 2025-0035). arXiv preprint arXiv:2603.12230, 2026. URL https://arxiv.org/abs/2603.12230. Junda Lin, Zhaomeng Zhou, Zhi Zheng, Shuochen Liu, Tong Xu, Yong Chen, and Enhong Chen. VIGIL: Defending LLM agents against tool stream injection via verify-before-commit. arXiv preprint arXiv:2601.05755, 2026. URL https://arxiv.org/abs/2601.05755. Songyang Liu, Chaozhuo Li, Chenxu Wang, Jinyu Hou, Zejian Chen, Litian Zhang, Zheng Liu, Qiwei Ye, Yiming Hei, Xi Zhang, and Zhongyuan Wang. ClawKeeper: Comprehensive safety protection for OpenClaw agents through skills, plugins, and watchers. arXiv preprint arXiv:2603.24414, 2026. URL https://arxiv.org/abs/2603.24414. Yi Liu, Gelei Deng, Yuekang Li, Kailong Wang, Tianwei Zhang, Yepang Liu, Haoyu Wang, Yan Zheng, and Yang Liu. Prompt injection attacks and defenses in LLM-integrated applications. In ACM Computing Surveys, 2024. Torsten Lodderstedt, Justin Richer, and Brian Campbell. OAuth 2.0 rich authorization requests. https://www.rfc-editor.org/rfc/rfc9396, 2023. RFC 9396. Hanjun Luo, Shenyu Dai, Chiming Ni, Xinfeng Li, Guibin Zhang, Kun Wang, Tongliang Liu, and Hanan Salam. AgentAuditor: Human-level safety and security evaluation for LLM agents. In Advances in Neural Information Processing Systems (NeurIPS), 2025. URL https://arxiv.or g/abs/2506.00641. John McCumber. Information systems security: A comprehensive model. In Proceedings of the 14th National Computer Security Conference, pages 328–337, 1991. Simon Meier, Benedikt Schmidt, Cas Cremers, and David Basin. The TAMARIN prover for the symbolic analysis of security protocols. In Computer Aided Verification (CAV), pages 696–701, 2013. Grégoire Mialon, Roberto Dessì, Maria Lomeli, Christoforos Nalmpantis, Ram Pasunuru, Roberta Raileanu, Baptiste Rozière, Timo Schick, Jane Dwivedi-Yu, Asli Celikyilmaz, et al. Augmented language models: a survey. Transactions on Machine Learning Research, 2023. Mark Samuel Miller. Robust composition: Towards a unified approach to access control and concurrency control. In Ph.D. Dissertation, Johns Hopkins University, 2006. 31
NEAR AI. IronClaw: An open-source secure runtime for AI agents. https://github.com/neara i/ironclaw, 2026. NIST. Digital signature standard (DSS). Federal Information Processing Standards Publication 186-4, 2013. OpenAI. GPT-4 technical report. arXiv preprint arXiv:2303.08774, 2023. OpenAI. OpenAI Agents SDK. https://github.com/openai/openai-agents-python, 2024. OpenID Foundation. OpenID Connect for Agents (OIDC-A) 1.0. arXiv preprint arXiv:2509.25974, 2025. URL https://arxiv.org/abs/2509.25974. OWASP Foundation. OWASP Top 10 for large language model applications. OWASP Project, 2024. URL https://owasp.org/www-project-top-10-for-large-language-modelapplications/. Yuxuan Qiao, Dongqin Liu, Hongchang Yang, Wei Zhou, and Songlin Hu. Agent tools orchestration leaks more: Dataset, benchmark, and mitigation. arXiv preprint arXiv:2512.16310, 2025. doi: 10.48550/arXiv.2512.16310. URL https://arxiv.org/abs/2512.16310. Eric Rescorla. The transport layer security (TLS) protocol version 1.3. RFC 8446, 2018. Justin (Ed.) Richer. GNAP: Grant negotiation and authorization protocol. https://www.rfceditor.org/rfc/rfc9635, 2024. RFC 9635. Yangjun Ruan, Honghua Dong, Andrew Wang, Silviu Pitis, Yongchao Zhou, Jimmy Ba, Yann Dubois, Chris J. Maddison, and Tatsunori Hashimoto. Identifying the risks of LM agents with an LM-emulated sandbox. arXiv preprint arXiv:2309.15817, 2023. doi: 10.48550/arXiv.2309.15817. URL https://arxiv.org/abs/2309.15817. Jerome H. Saltzer and Michael D. Schroeder. The protection of information in computer systems. Proceedings of the IEEE, 63(9):1278–1308, 1975. doi: 10.1109/PROC.1975.9939. Jim Schaad and Russ Housley. Advanced encryption standard (AES) key wrap algorithm. RFC 3394, 2002. Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Eric Hambro, Luke Zettlemoyer, Nicola Cancedda, and Thomas Scialom. Toolformer: Language models can teach themselves to use tools. Advances in Neural Information Processing Systems, 36, 2023. Tianneng Shi, Jingxuan He, Zhun Wang, Hongwei Li, Linyu Wu, Wenbo Guo, and Dawn Song. Progent: Programmable privilege control for LLM agents. arXiv preprint arXiv:2504.11703, 2025. URL https://arxiv.org/abs/2504.11703. Tobin South, Samuele Marro, Thomas Hardjono, Robert Mahari, Cedric Deslandes Whitney, Dazza Greenwood, Alan Chan, and Alex Pentland. Authenticated delegation and authorized AI agents. arXiv preprint arXiv:2501.09674, 2025. URL https://arxiv.org/abs/2501.09674. Georgios Syros, Anshuman Suri, Jacob Ginesin, Cristina Nita-Rotaru, and Alina Oprea. SAGA: A security architecture for governing AI agentic systems. arXiv preprint arXiv:2504.21034, 2025. URL https://arxiv.org/abs/2504.21034. Lillian Tsai and Eugene Bagdasarian. Contextual agent security: A policy for every purpose. In Workshop on Hot Topics in Operating Systems (HotOS), 2025. doi: 10.1145/3713082.3730378. Sanidhya Vijayvargiya, Aditya Bharat Soni, Xuhui Zhou, Zora Zhiruo Wang, Nouha Dziri, Graham Neubig, and Maarten Sap. OpenAgentSafety: A comprehensive framework for evaluating realworld AI agent safety. In International Conference on Learning Representations (ICLR), 2026. URL https://arxiv.org/abs/2507.06134. W3C Web Payments Working Group. Secure payment confirmation. https://www.w3.org/TR/ secure-payment-confirmation/, 2024. W3C Working Draft. 32
Haoyu Wang, Christopher M. Poskitt, and Jun Sun. AgentSpec: Customizable runtime enforcement for safe and reliable LLM agents. arXiv preprint arXiv:2503.18666, 2025. URL https://arxiv. org/abs/2503.18666. Sam Warren. Aegis: A credential isolation proxy for AI agents. https://github.com/getaegi s/aegis, 2025. Qingyun Wu, Gagan Bansal, Jieyu Zhang, Yiran Wu, Beibin Li, Erkang Zhu, Li Jiang, Xiaoyun Zhang, Shaokun Zhang, Jiale Liu, Ahmed Hassan Awadallah, Ryen W. White, Doug Burger, and Chi Wang. AutoGen: Enabling next-gen LLM applications via multi-agent conversation. https://arxiv.org/abs/2308.08155, 2023. Yuhao Wu, Franziska Roesner, Tadayoshi Kohno, Ning Zhang, and Umar Iqbal. IsolateGPT: An execution isolation architecture for LLM-based agentic systems. In Network and Distributed System Security Symposium (NDSS), 2025. doi: 10.14722/ndss.2025.241131. URL https: //arxiv.org/abs/2403.04960. Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. ReAct: Synergizing reasoning and acting in language models. International Conference on Learning Representations (ICLR), 2023. Zonghao Ying, Xiao Yang, Siyang Wu, Yumeng Song, Yang Qu, Hainan Li, Tianlin Li, Jiakai Wang, Aishan Liu, and Xianglong Liu. Uncovering security threats and architecting defenses in autonomous agents: A case study of OpenClaw. arXiv preprint arXiv:2603.12644, 2026. URL https://arxiv.org/abs/2603.12644. Qiusi Zhan, Zhixiang Liang, Zifan Ying, and Daniel Kang. Injecagent: Benchmarking indirect prompt injections in tool-integrated large language model agents. In Findings of the Association for Computational Linguistics: ACL 2024, pages 10471–10506, Bangkok, Thailand, 2024. Association for Computational Linguistics. URL https://aclanthology.org/2024.findings-acl.62 4/. Hanrong Zhang, Jingyuan Huang, Kai Mei, Yifei Yao, Zhenting Wang, Chenlu Zhan, Hongwei Wang, and Yongfeng Zhang. Agent security bench (ASB): Formalizing and benchmarking attacks and defenses in LLM-based agents. In International Conference on Learning Representations (ICLR), 2025. URL https://arxiv.org/abs/2410.02644. Zhexin Zhang, Shiyao Cui, Yida Lu, Jingzhuo Zhou, Junxiao Yang, Hongning Wang, and Minlie Huang. Agent-safetybench: Evaluating the safety of LLM agents. arXiv preprint arXiv:2412.14470, 2024. doi: 10.48550/arXiv.2412.14470. URL https://arxiv.org/abs/2412.14470. Xuhui Zhou, Hyunwoo Kim, Faeze Brahman, Liwei Jiang, Hao Zhu, Ximing Lu, Frank F. Xu, Bill Yuchen Lin, Yejin Choi, Niloofar Mireshghallah, Ronan Le Bras, and Maarten Sap. Haicosystem: An ecosystem for sandboxing safety risks in interactive AI agents. In Conference on Language Modeling (COLM), 2025. URL https://openreview.net/forum?id=KI1WQ6rLiy.
33