arxiv: 2604.24920 · v2 · submitted 2026-04-27 · 💻 cs.CR · cs.AI

Recognition: unknown

SUDP: Secret-Use Delegation Protocol for Agentic Systems

Xiaohang Yu , Hejia Geng , Xinmeng Zeng , William Knottenbelt

Authors on Pith no claims yet

Pith reviewed 2026-05-08 02:36 UTC · model grok-4.3

classification 💻 cs.CR cs.AI

keywords agentic systemssecret delegationauthorization protocolsingle-use grantsprompt injection defensecredential exposuresecure API access

0 comments

The pith

SUDP lets untrusted agents trigger secret-backed operations with single-use grants that never expose reusable authority.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

Agentic systems need to perform actions that require user secrets for APIs and services, yet current bearer-token methods expose reusable credentials inside model-steerable boundaries. The paper defines the Agent Secret Use problem as the need for an untrusted requester to cause a bounded secret operation without gaining durable authority. It introduces SUDP, a three-party protocol in which the requester proposes an operation, the user issues a fresh grant, and a custodian redeems it exactly once. Under the stated assumptions, this construction keeps authorization verifiable, operation-bound, and non-reusable while preserving storage confidentiality and key isolation.

Core claim

SUDP is a three-role protocol realizing Agent Secret Use: 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 that reusable authority never crosses the requester boundary. Under explicit assumptions the protocol satisfies verifiable, operation-bound, and single-use authorization; it additionally provides storage confidentiality and wrapping-epoch key isolation when sealing and erasure are enforced, with plaintext forward secrecy requiring environment-driven rotation and revocation of the secret.

What carries the argument

The Secret-Use Delegation Protocol (SUDP), a three-role mechanism in which an operation proposal is paired with a single-use, operation-bound grant that the custodian redeems exactly once.

If this is right

Agents can propose and cause secret-backed operations without ever retrieving or storing the secret itself.
A transient compromise of the requester cannot produce durable account access because grants are single-use and bound to specific operations.
Authorization decisions remain auditable because each grant carries an explicit, verifiable description of the permitted action.
Confidentiality of stored secrets holds as long as the custodian enforces the stated sealing and erasure steps between epochs.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

SUDP could be composed with existing scoped-token systems to add single-use enforcement on top of current delegation primitives.
The separation of roles suggests a natural place to insert human confirmation steps before grant issuance without changing the protocol flow.
Platform-level adoption would require custodians that can enforce erasure guarantees across heterogeneous agent runtimes.

Load-bearing premise

The custodian correctly seals and erases wrapping keys after each epoch, and the environment rotates and revokes the underlying secret to maintain forward secrecy.

What would settle it

A concrete attack in which a compromised requester successfully re-uses a prior grant to execute an operation outside the originally authorized scope.

Figures

Figures reproduced from arXiv: 2604.24920 by Hejia Geng, William Knottenbelt, Xiaohang Yu, Xinmeng Zeng.

**Figure 1.** 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), freshness r, and acting credential identifier cidc ⋆ ; T redeems G once and uses the secret s sealed in state Σ to execute o at E… view at source ↗

**Figure 2.** 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 reusab… view at source ↗

**Figure 3.** 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… view at source ↗

**Figure 4.** 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.typ… view at source ↗

**Figure 5.** 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 skrcp. Lifecycle: T commits a new sealed state Σ ′ with … view at source ↗

**Figure 6.** 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 o… view at source ↗

read the original 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.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Desk Editor's Note private letter to a colleague

The paper names a real structural gap in agentic secret use and sketches a three-role delegation protocol, but the abstract gives no construction details or proof to check whether the claims hold.

read the letter

The main thing here is that the authors have put a name on the problem of letting an agent trigger secret-backed operations without handing the agent reusable authority that could survive a prompt injection or compromise. They call it Agent Secret Use and propose SUDP as a fix: the agent proposes a canonical operation, the user issues a fresh authenticator-backed single-use grant, and a custodian redeems it once to execute the bounded action. Agents never retrieve the secret themselves. That separation is the core idea and it is new enough as a focused formalization, even if it builds on existing work with scoped tokens and sender-constrained authorization. The taxonomy that splits structural obligations from realization assumptions is also useful for comparing defenses. The paper scopes its security statements to explicit assumptions on sealing, erasure, and environment-driven rotation, which keeps the argument from overclaiming. The soft spot is that the abstract asserts the protocol meets the requirements but supplies no derivation, construction steps, or proof sketch. Without seeing how the grant is actually formed or why it enforces single-use and verifiability, it is impossible to tell whether the three-role design delivers what is promised. That gap makes soundness hard to assess from what is shown. This is for people working on secure agent architectures or authorization protocols in AI systems. Readers who want a clear problem statement and high-level design will get value from it as a starting point. It deserves a serious referee because the issue is timely and the framing is structured, even though the paper will need to add the missing protocol mechanics and security arguments before it can be evaluated properly. I would send it out for review rather than desk reject.

Referee Report

2 major / 0 minor

Summary. The paper formalizes the Agent Secret Use (ASU) problem for agentic systems acting with user secrets, derives a security-property taxonomy separating structural obligations from realization conditions, and proposes the Secret-Use Delegation Protocol (SUDP). SUDP is a three-role construction (requester proposes canonical operation; user issues fresh authenticator-backed grant; custodian redeems once) specialized so agents never retrieve secrets. The central claim is that, under explicit assumptions on sealing/erasure and environment-driven rotation/revocation, SUDP satisfies verifiable, operation-bound, single-use authorization plus storage confidentiality, wrapping-epoch key isolation, and plaintext forward secrecy.

Significance. If the claims hold, the work supplies a problem-grounded specification and protocol for preventing reusable-authority exposure in autonomous agents, a timely contribution given prompt-injection and tool-compromise risks in API-using agents. The explicit scoping to assumptions and the separation of ASU formalization from the concrete construction are strengths that could enable principled comparison of existing defenses.

major comments (2)

[Abstract] Abstract: the assertion that 'Under explicit assumptions, we show that SUDP satisfies the ASU requirements' is not supported by any derivation, proof sketch, formal argument, or reference to a later section containing the reasoning. This is load-bearing for the central claim, as the satisfaction statements cannot be assessed without seeing how the three-role structure and single-use grants entail the listed properties.
[Full manuscript] The manuscript supplies no explicit definitions of the protocol steps, message formats, authenticator construction, or the precise mapping from the three-role design to the ASU properties, preventing verification that the construction actually realizes the claimed guarantees even under the stated assumptions.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive and detailed review. We appreciate the recognition of the problem formalization and the potential for principled comparison of defenses. We address each major comment below, indicating the revisions we will undertake.

read point-by-point responses

Referee: [Abstract] Abstract: the assertion that 'Under explicit assumptions, we show that SUDP satisfies the ASU requirements' is not supported by any derivation, proof sketch, formal argument, or reference to a later section containing the reasoning. This is load-bearing for the central claim, as the satisfaction statements cannot be assessed without seeing how the three-role structure and single-use grants entail the listed properties.

Authors: We agree that the abstract claim requires an explicit pointer to the supporting reasoning for verifiability. In the revised manuscript we will update the abstract to reference the new section (or appendix) that contains a structured argument deriving the ASU properties—verifiable authorization, operation-boundedness, single-use semantics, storage confidentiality, wrapping-epoch isolation, and plaintext forward secrecy—from the three-role construction and single-use grant mechanism under the stated sealing, erasure, rotation, and revocation assumptions. This will make the entailment traceable without expanding the abstract length. revision: yes
Referee: [Full manuscript] The manuscript supplies no explicit definitions of the protocol steps, message formats, authenticator construction, or the precise mapping from the three-role design to the ASU properties, preventing verification that the construction actually realizes the claimed guarantees even under the stated assumptions.

Authors: We acknowledge the absence of these concrete artifacts in the current version. The manuscript intentionally presents SUDP at the level of structural obligations to separate the problem specification from any particular realization. To enable direct verification, the revision will add a dedicated section (or appendix) that supplies: (i) numbered protocol steps with participant roles, (ii) canonical message formats and fields, (iii) the authenticator construction (including freshness and binding mechanisms), and (iv) a property-mapping table or short proof sketch that shows, assumption by assumption, how each ASU requirement is satisfied by the three-role flow and single-use redemption. These additions will be self-contained and will not alter the high-level taxonomy or core claims. revision: yes

Circularity Check

0 steps flagged

No significant circularity

full rationale

The paper defines the ASU problem and its security taxonomy independently of the SUDP construction, then presents SUDP as a three-role protocol (requester proposes operation, user issues grant, custodian redeems once) whose properties are shown to hold under explicitly stated assumptions on sealing, erasure, and environment-driven rotation. No equations or claims reduce by construction to fitted parameters, self-referential definitions, or load-bearing self-citations; the satisfaction statements follow directly from the structural separation of roles and the listed assumptions rather than from any renaming or smuggling of prior results. The central argument remains self-contained against external benchmarks.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 0 invented entities

Information drawn exclusively from abstract; full paper likely contains additional details on cryptographic assumptions and protocol mechanics.

axioms (2)

domain assumption Sealing and erasure assumptions hold for storage confidentiality and wrapping-epoch key isolation
Explicitly required for SUDP to deliver those properties
domain assumption The environment rotates and revokes the underlying secret
Required for plaintext-level forward secrecy

pith-pipeline@v0.9.0 · 5599 in / 1405 out tokens · 52453 ms · 2026-05-08T02:36:05.262354+00:00 · methodology

discussion (0)

Reference graph

Works this paper leans on

5 extracted references · 5 canonical work pages · 2 internal anchors

[1]

Clawkeeper: Comprehensive safety protection for openclaw agents through skills, plugins, and watchers.arXiv preprint arXiv:2603.24414,

URLhttps://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.r...

work page arXiv 2024
[2]

OWASP Foundation

URLhttps://arxiv.org/abs/2509.25974. OWASP Foundation. OWASP Top 10 for large language model applications.OWASP Project,

work page arXiv
[3]

Agent tools orchestration leaks more: Dataset, benchmark, and mitigation,

URL https://owasp.org/www-project-top-10-for-large-language-model- applications/. 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. URLhttps://arxiv.org/abs/2512.16310. Eric Rescorla. The transpo...

work page doi:10.48550/arxiv.2512.16310 2025
[4]

Agent Security Bench (ASB): Formalizing and Benchmarking Attacks and Defenses in LLM-based Agents

URLhttps://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,

work page internal anchor Pith review arXiv
[5]

Agent-SafetyBench: Evaluating the Safety of LLM Agents

doi: 10.48550/arXiv.2412.14470. URLhttps://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. Haicosys- tem: An ecosystem for sandboxing safety risks in interactive AI agents. InConference on Language Modeling (...

work page internal anchor Pith review doi:10.48550/arxiv.2412.14470 2025