Latest / AI Conversations / Keeping Credentials Out of AI Agents with Relay

Transcript

Keeping Credentials Out of AI Agents with Relay · AI Conversations

• 0:00
  SPEAKER_01: So we're talking about AI agents, right?
• 0:03
  SPEAKER_01: And the big uh the big scary thing in the room is always like prompt injection or, you know, accidental disclosure.
• 0:11
  SPEAKER_01: But it sounds like those are really just different ways to describe the same core problem, which is credentials getting out.
• 0:18
  SPEAKER_02: Aaron Ross Powell Exactly.
• 0:19
  SPEAKER_02: Christian Posta, he puts it really well.
• 0:21
  SPEAKER_02: He says these things: prompt injection, exfiltration, accidental disclosure.
• 0:27
  SPEAKER_02: They sound like different attacks, but they're just uh delivery mechanisms for the same failure mode.
• 0:33
  SPEAKER_02: And that failure mode is the bytes of a sensitive credential leave the agent and they still work.
• 0:39
  SPEAKER_01: So it's not even about like trying to trick the AI into giving up the credential.
• 0:44
  SPEAKER_01: It's just that if the credential is there, it can just leave.
• 0:49
  SPEAKER_02: Right.
• 0:49
  SPEAKER_02: And the scary part is the model itself doesn't always know it's doing something wrong.
• 0:54
  SPEAKER_02: It's goal-oriented, it's stochastic, and it might just hand over its credentials unprompted because it genuinely believes it's solving your problem.
• 1:03
  SPEAKER_02: It's trying to be helpful.
• 1:05
  SPEAKER_01: So it's like it doesn't have a reliable way to tell what my instructions are versus what it just read in some untrusted content.
• 1:13
  SPEAKER_02: Precisely.
• 1:14
  SPEAKER_02: Simon Willison talks about this lethal trifecta.
• 1:17
  SPEAKER_02: You have access to private data, exposure to untrusted content, and the ability to externally communicate.
• 1:24
  SPEAKER_02: The third one, the ability to communicate externally, that's the cheap one.
• 1:29
  SPEAKER_02: Any tool that can make an HTTP request, load an image, even give a user a link to click, it can carry stolen information right out.
• 1:38
  SPEAKER_01: So if we want to prevent this, we basically have to keep two things away from the agent: the credential itself and the open road out.
• 1:46
  SPEAKER_02: Mm-hmm.
• 1:46
  SPEAKER_02: And that's where something like relay comes in.
• 1:49
  SPEAKER_02: It's Workos' answer to this.
• 1:51
  SPEAKER_02: It lets you call third-party APIs on behalf of your users without directly handling those secrets.
• 1:57
  SPEAKER_02: The requests proxy through Workos, and that's where the third-party credential gets swapped in.
• 2:03
  SPEAKER_02: The agent itself holds nothing worth stealing.
• 2:06
  SPEAKER_01: So the agent never actually sees the sensitive credential.
• 2:10
  SPEAKER_01: It's like a middleman that just passes the message along, and the secret gets added at the very last second.
• 2:16
  SPEAKER_02: That's the idea.
• 2:17
  SPEAKER_02: And there's a good framework for this, actually.
• 2:19
  SPEAKER_02: The IETF draft, Credential Broker for Agents, or CB4A, it outlines three different credential proxy models.
• 2:27
  SPEAKER_01: Okay, three models.
• 2:29
  SPEAKER_01: Could you uh could you unpack those a little for us?
• 2:32
  SPEAKER_02: Yeah.
• 2:32
  SPEAKER_02: So model A is what they call the proxy gateway.
• 2:36
  SPEAKER_02: In this model, the agent's container is essentially empty.
• 2:39
  SPEAKER_02: The credential sits outside of it.
• 2:41
  SPEAKER_02: It travels directly from the broker to the target service.
• 2:45
  SPEAKER_02: The agent never touches it.
• 2:46
  SPEAKER_02: The blast radius there is minimal.
• 2:49
  SPEAKER_01: So that's the safest, it sounds like.
• 2:51
  SPEAKER_02: It is.
• 2:52
  SPEAKER_02: Then you have model B, which is short-lived token minting.
• 2:56
  SPEAKER_02: Here, the broker mints a narrow, short-lived token and hands it to the agent.
• 3:00
  SPEAKER_02: So the credential, or a temporary version of it, lives inside the agent container for a limited time.
• 3:06
  SPEAKER_02: It's time to live or TTL.
• 3:09
  SPEAKER_02: The blast radius is bounded by that TTL.
• 3:12
  SPEAKER_01: So it's still in the agent, but it expires quickly.
• 3:15
  SPEAKER_02: Exactly.
• 3:16
  SPEAKER_02: And then Model C is credential wrapping with scheduled revocation.
• 3:20
  SPEAKER_02: This is where you hand over a long-lived credential to the agent and then schedule its revocation.
• 3:26
  SPEAKER_02: The draft calls this the weakest model, actually.
• 3:29
  SPEAKER_02: It's not recommended for new integrations, because the blast radius is full until that revocation happens.
• 3:35
  SPEAKER_01: So model A, where the credential never even touches the agent, that's the ideal.
• 3:40
  SPEAKER_01: But I imagine there are reasons why B or C might even exist, right?
• 3:45
  SPEAKER_02: Well, the gap between A and B, it's smaller on paper than in practice.
• 3:50
  SPEAKER_02: A Model B token, even if it's short-lived, still lives in the same context window that might have just read a JIRA comment written by a stranger.
• 3:58
  SPEAKER_02: For its TTL, it's a working bearer credential.
• 4:02
  SPEAKER_02: A Model A request, though, has nothing for an attacker to get out.
• 4:06
  SPEAKER_02: The credential travels from the broker to the target service, but never, uh never to the agent.
• 4:11
  SPEAKER_01: So it's about what the agent holds.
• 4:14
  SPEAKER_01: If it holds nothing, there's nothing to steal.
• 4:16
  SPEAKER_02: Precisely.
• 4:17
  SPEAKER_02: And Posta actually argues that for most enterprises today, the draft's ordering is backwards, and Model A should be the primary approach.
• 4:26
  SPEAKER_02: The practical reason is that minting tokens, like in Model B, often requires the target service to cooperate, and many don't.
• 4:34
  SPEAKER_02: For example, there's no easy way to exchange something from your corporate IDP for a GitHub token.
• 4:40
  SPEAKER_02: GitHub wants its own OAuth token, obtained by user consent.
• 4:44
  SPEAKER_02: You get it once, and then you have to keep it.
• 4:47
  SPEAKER_01: So relay then follows that Model A approach?
• 4:50
  SPEAKER_02: It does.
• 4:51
  SPEAKER_02: For the provider's Worko supports, relay matches that Model A shape.
• 4:56
  SPEAKER_02: The credential goes broker to target and never to the agent.
• 5:00
  SPEAKER_02: You can also vend a credential and use it yourself, but the documentation draws a clear line.
• 5:06
  SPEAKER_02: Access tokens for trusted infrastructure and long-running syncs, but relay for agents, sandboxes, and untrusted runtimes.
• 5:14
  SPEAKER_01: So for developers, what does a call look like when their agent holds nothing?
• 5:19
  SPEAKER_02: It's pretty straightforward.
• 5:20
  SPEAKER_02: The relay base URL is api.workos.com slash relay.
• 5:26
  SPEAKER_02: You keep your original method, body, and content headers.
• 5:30
  SPEAKER_02: You send it to the relay base URL, but you put the original URL in an XRelay URL header.
• 5:37
  SPEAKER_02: You put your Workos API key in the authorization header instead of the provider token.
• 5:42
  SPEAKER_02: And you name the user in XRelay user, adding XRelay organization if it's an organization-scoped connection.
• 5:50
  SPEAKER_02: The provider is usually resolved from the host in XRelay URL, so you often don't even need a separate provider header.
• 5:57
  SPEAKER_01: So it's essentially just redirecting the request through Workos, and Workos handles injecting the real credentials.
• 6:04
  SPEAKER_02: Yes.
• 6:05
  SPEAKER_02: Behind that request, Workos verifies your key, resolves the environment and user, looks up the connected account, fetches and refreshes the credential if needed, and then strips those relay control headers before sending it to the provider.
• 6:20
  SPEAKER_02: The agent holds your Workos API key, but nothing else.
• 6:23
  SPEAKER_02: The provider credential is attached only after that boundary.
• 6:27
  SPEAKER_02: It never exists in the agent's process.
• 6:30
  SPEAKER_00: That's a really clean way to solve that problem.
• 6:33
  SPEAKER_00: It's like the credential exists, but it exists in the right place and only there.
• 6:39
  SPEAKER_02: Exactly.
• 6:40
  SPEAKER_02: It fundamentally changes the attack surface by ensuring that the sensitive credential is never present in the environment where prompt injection or accidental disclosure could occur.