SUDP: Secret-Use Delegation Protocol for Agentic Systems

Introduction to the show: ident: Security Radio. Generated commentary on the latest security and cryptography papers.

Nadia: We're looking at the paper: "SUDP: Secret-Use Delegation Protocol for Agentic Systems".

Elias: Here's the gist of the paper. The gist: SUDP proposes a Secret-Use Delegation Protocol to allow untrusted agents to cause user-authorized secret-backed operations without gaining reusable authority over them.

Nadia: How it works SUDP formalizes the Agent Secret Use (ASU) problem, which arises when an autonomous requester must cause a user-authorized operation without ever gaining reusable authority over that operation The protocol involves three roles: the Requester R proposes an operation o; the Authorizer U reviews o and issues a grant G; and the Custodian T redeems grants, holds secret s sealed in Σ, and performs the bounded use The core mechanism ensures that reusable authority never crosses the requester boundary.

Elias: Security Properties The paper identifies seven security properties any solution must satisfy, spanning authorization integrity and secret confidentiality These properties are grouped into four core ones (AV, OB, UB, CRC) that preclude two adversarial wins of extraction or misuse Specifically: Authorization integrity: 1.

Nadia: AV (Authorization Verifiability): 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 2.

Paper summary: Nadia: So we're talking about this paper called "SUDP: Secret-Use Delegation Protocol for Agentic Systems". Basically it formalizes the whole problem of how an untrusted autonomous agent can use a user-authorized secret to do something without getting permanent authority over that operation.

Elias: Right, so the core idea is that agents are increasingly acting with user secrets for things like APIs and cloud services, and currently, the way runtimes handle authorization by exposure means placing reusable artifacts inside the runtime which can turn a temporary prompt injection into a lasting account compromise.

Priya: That sounds like it’s about making sure that when an agent tries to use a secret-backed operation, it doesn't gain any persistent power over that secret itself.

Nadia: Exactly, and they call this the Agent Secret Use or ASU problem because existing defenses only cover separate things like secret storage or scoped delegation, but none of them specify how to stop the requester from gaining reusable authority over the secret.

Elias: The paper proposes something called the Secret-Use Delegation Protocol, SUDP. It sets up three roles: a Requester R who proposes an operation o, an Authorizer U who reviews it and issues a grant G, and a Custodian T who redeems that grant to perform the bounded use.

Priya: So what's the main goal of this protocol in plain terms?

Nadia: The main thing is that reusable authority never crosses that requester boundary. The Requester only proposes the action, but they don't get to reuse the actual authority for that secret-backed operation >

Elias: It formalizes this by identifying seven security properties any solution needs to satisfy, which cover both authorization integrity and secret confidentiality. They group these into four core ones: AV, OB, UB, and CRC >

Priya: Can you tell us what those mean in a way that isn't just jargon?

Nadia: Authorization integrity means that any successful execution induced through this mechanism is traceable back to the Authorizer U under the assumptions of the mechanism >

Elias: Operation binding means that an authorization is tied to a specific operation o, so the system doesn't let it execute anything semantically different from o >

Priya: And use boundedness? What does that mean for a user?

Nadia: Use boundedness means that any execution done through this mechanism cannot go beyond the limits that the Authorizer U actually authorized >

Elias: Then there's secret confidentiality, specifically CRC, which stands for Confidentiality under Requester Compromise. This property says that if the requester gets compromised, it shouldn't expose any of the authority-bearing material >

Priya: That sounds really important when you think about what happens when an agent is compromised; they shouldn't just walk away with all those user secrets >

Nadia: Right. So SUDP is specialized for LLM-driven agents, meaning it applies whenever a tool call would use user-enrolled material >

Elias: The protocol flow involves three phases: Setup, Authorization Grant, and Consumption. In the setup phase, credentials get registered with T and protected-state sealing generates an initial state C and specific wrapping keys Wc >

Priya: When we look at the authorization grant phase, what's happening there?

Nadia: The Requester R proposes o, the Authorizer U reviews o and signs a thing called beta which is bound to H(o) in a channel binding r >

Elias: That grant G is then authorized by U and it’s bound to H(o), a freshness token r, and an acting credential identifier cidc that needs to be verified >

Priya: And the consumption phase? How does the secret actually get used without the requester getting any extra leverage?

Nadia: The Custodian T redeems G by consuming a freshness token r from S, and then they use the secret s sealed in state Σ to execute o at E, which is an external API or service >

Elias: The key point there is that only the result returns to R, and reusable authority never crosses that requester boundary >

Priya: That sounds like a solid way to isolate the risk; it keeps the ability to do something strictly limited and temporary for the agent >

Nadia: It does, but we have some limitations. The paper says SUDP satisfies six of those seven properties under standard cryptographic assumptions, but the seventh property, runtime-memory confidentiality, is closed by composition with a hardware-rooted runtime >

Elias: And they also list some things that aren't covered at the protocol level. They mention things like Runtime compromise during consumption and Authenticator compromise >

Priya: I remember reading them mentioned a "dormant-credential forward-secrecy gap" and "peer-map cross-credential exposure" as limitations because authorization is bounded by the Authorizer U's judgment, not necessarily their intent >

Nadia: So what does this mean for us when we look at the whole picture of agentic systems?

Elias: It suggests that while SUDP is a strong protocol for bounding use, you still need to consider how it interacts with the underlying execution environment and hardware roots to get full security coverage >

Priya: It really shows that this isn't just about one piece of code; it’s about the entire stack from enrollment through execution and monitoring >

Nadia: So we've covered what SUDP is, what it tries to stop, and where its limits lie. Next up we’re going to talk a bit more about the big picture implications of this work on agent security generally.

Conclusion: Nadia: So we're wrapping up this look at SUDP, which stands for Secret-Use Delegation Protocol for Agentic Systems. Basically, it’s about giving untrusted agents a way to use user secrets without them getting permanent control over that secret's authority.

Elias: Yeah, so the authors are looking at how agent runtimes handle authorization by exposure—which means putting reusable secrets inside the runtime environment—and they say that’s dangerous because it makes a temporary security glitch into a lasting account compromise.

Priya: What does this mean for someone just trying to keep their data safe?

Nadia: It means we have to figure out how to stop an autonomous agent from hoarding user secrets that they shouldn't be able to reuse indefinitely. SUDP proposes a way where the requester can propose an action, but the actual use of the secret is delegated through a fresh authorization grant.

Elias: The core mechanism is that reusable authority never crosses that line from the person who wants to act to the person who actually performs the operation. They have three roles: Requester, Authorizer, and Custodian.

Priya: So if I’m using an AI agent for a task, this protocol ensures that even if the agent gets tricked into doing something weird, it can’t just keep using my main API key for everything?

Nadia: Exactly. The paper shows that SUDP satisfies seven security properties spanning authorization integrity and secret confidentiality. It covers things like making sure the execution is traceable back to the user's authorization and that the requester's own compromise doesn't leak the secret material.

Elias: And they show that under standard cryptographic assumptions, it hits six of those seven points right away. The seventh one, runtime-memory confidentiality, they say you have to add a hardware-rooted runtime on top of it to close that gap.

Priya: So what are the actual practical limits when you try to run this in the real world? What’s still shaky?

Nadia: The limitations they point out involve things like if the authenticator itself gets compromised, or issues with how long a credential stays valid if it's dormant. They also note that authorization is bound by what the user *authorized*, not necessarily what they *intended* to authorize.

Elias: That lack of intent modeling is a big thing for cryptography because it means you can't perfectly prove the security assumptions hold across every possible use case an agent might try.

Priya: It sounds like this protocol is a really strong way to structure the delegation, but it still depends on other security layers being in place to handle those edge cases.

Nadia: That’s right. So SUDP gives us a structured way to think about how agents use user secrets, and now we gotta look at how these kinds of protocols actually verify their own assumptions when they're dealing with real-world agent workloads and active adversaries.