SUDP: letting agents act on your credentials without ever holding them
A May 2026 protocol reframes agent credential handling: instead of putting a reusable secret inside the model-steerable runtime, the agent only proposes an operation the user signs off on, single-use.
What is this?
In May 2026, researchers from Imperial College London, Oxford and Stanford published SUDP: Secret-Use Delegation Protocol for Agentic Systems (arXiv preprint, v2 dated 1 May 2026). It is not an attack. It is an attempt to fix one of the most under-addressed pieces of agent security: what happens to the API keys, OAuth tokens and signing keys an agent needs in order to actually do things.
The paper’s framing is blunt. Today’s engineering practice is authorization by exposure: to let an agent send a message, push to a repository, or call a paid API, you place a reusable secret — or something derived from it — inside the agent’s runtime. But the agent runtime is exactly the boundary that untrusted input can reach. So a transient prompt injection or a compromised tool stops being a one-off bad action and becomes durable account compromise, because the attacker now sits next to a reusable credential.
How it works
SUDP first names the underlying problem as a clean abstraction the authors call Agent Secret Use (ASU): an untrusted autonomous requester must be able to cause a user-authorized, secret-backed operation without ever being exposed to reusable authority over the secret. Native bearer interfaces cannot satisfy both halves — hand the key to the agent and it works but leaks; withhold it and the call is simply rejected by the service.
The protocol resolves the tension by splitting the job across three roles. The Requester is the agent runtime: it proposes a specific, canonicalized operation and holds no secret. The Authorizer is the user plus a hardware authenticator (WebAuthn / FIDO): they review the exact proposed operation and issue a fresh signed grant that is cryptographically bound to a hash of that operation, is single-use, and names the credential that may act. The Custodian holds the sealed secret, redeems the grant exactly once to perform the bounded action against the external service, and then zeroizes. Only the result flows back to the agent.
The consequence is the design’s whole point: reusable authority never crosses the requester boundary. Because each execution is covered by a fresh, user-signed grant bound to one canonical operation, properties like anti-substitution, operation binding and replay resistance hold by construction rather than by careful code review. Even a fully prompt-injected agent can at most propose an operation the user still has to witness and approve — it can never retrieve a credential to reuse later or elsewhere.
Why it matters
This targets the “access to private data” leg of the well-known lethal-trifecta risk directly, and it does so at the layer where most current mitigations do not operate. Instruction–data separators, tool-policy engines, sandboxes and guardrails all reason about what the agent is doing or where it does it; SUDP instead constrains what a secret can be used for at the boundary where the secret lives. The two approaches compose: a behavioral guardrail that fails still leaves an attacker bounded by the user-signed operation scope.
The honest limits are stated in the paper. SUDP gives storage confidentiality and key-epoch isolation under explicit sealing and erasure assumptions, but plaintext-level forward secrecy of the underlying secret still requires the environment to rotate and revoke it. It also assumes the external service accepts the custodian’s mediated call, and that the user actually reads the operation they approve — a canonicalized, human-reviewable operation descriptor is doing real work here.
Defenses
The practical takeaways generalize beyond this one protocol. Treat “the agent holds the API key” as a design smell, not a convenience: any reusable credential inside a model-steerable runtime is one injection away from durable compromise. Prefer per-operation authorization over per-session credentials — bind approval to a specific, canonical action rather than granting the agent standing authority for a whole task. Keep secrets behind a mediator (a custodian or credential proxy) that spends them internally and returns only results, so the agent proposes but never possesses. Anchor human approval in a phishing-resistant authenticator and make the approved operation legible to the person signing it. And keep rotating and revoking underlying secrets: mediation limits blast radius, but forward secrecy of the real credential still depends on the environment retiring it.
Status
| Aspect | Detail |
|---|---|
| Disclosure | arXiv preprint (2604.24920), v2 dated 1 May 2026 |
| Authors | Xiaohang Yu, Hejia Geng, Xinmeng Zeng, William Knottenbelt (Imperial College London, Oxford, Stanford) |
| Class | Defensive research — authorization protocol for agent credential use |
| Method | ”Agent Secret Use” problem formalization; three-role protocol (Requester / Authorizer / Custodian); fresh single-use grants bound to a canonical operation |
| Guarantees | Verifiable, operation-bound, single-use authorization; storage confidentiality and key-epoch isolation under stated assumptions |
| Stated limits | Plaintext forward secrecy still requires environment-side rotation/revocation; assumes service accepts mediated calls and users review the operation |
| Exploited in the wild | Not applicable — defensive protocol proposal |