Securing agentic identity
Home
Archives
Search
Links
RSS
Dark Mode
As is the case for many people working in the security industry, the last<br>few months of my life have been focused on dealing with people wanting to<br>use LLMs everywhere. From an enterprise security perspective that’s not an<br>inherent problem - what’s more of a problem is that people want those agents<br>to have access to resources like their calendar and email and so on, and now<br>we have somewhat non-deterministic agents that seem very enthusiastic to<br>achieve what you asked whether that’s a good idea or not, and we’re<br>combining this with credentials that give them access to sensitive data, and<br>leaving those credentials on disk where they can be committed into git repos<br>or exfiltrated to some other service to make use of them on the agent’s<br>behalf or well just any other number of things, at which point your CEO’s<br>email is suddenly readable by everyone and you’re having a bad day.
As I mentioned in my last<br>post, pretty<br>much every strong mechanism for keeping credentials in place is just not<br>supported in the wider world. We can imagine a universe where agents use<br>hardware (or at least hypervisor) backed certificates to obtain credentials<br>and any that end up leaking are worthless as a result. But, sadly, that’s<br>not an option for most people using existing identity providers. The state<br>of the art is that you use the device code<br>flow and a human authenticates and<br>the token ends up back inside the agent environment and then it proceeds to<br>do whatever it wants with it and you just hope that you wake up the next<br>morning without an awful infoleak occurring.
(An aside: I do not like the device code flow as used in enterprise<br>environments, and I never will. The identity provider doesn’t have a real<br>opportuity to inspect the security posture of the system asking for the<br>token, and as a result some identity providers will restrict tokens that are<br>issued in this way. The common alternative of doing stuff using a more<br>standard flow and having a redirect URI pointing at localhost works fine for<br>local systems and is a pain for remote ones, even if you can commit crimes<br>with SSH forwarding. I’m going to suggest something that I think is better,<br>and you are free to disagree)
I’m not in a position to get every identity provider and service provider to<br>change their security posture, so I’m somewhat stuck in terms of the tokens<br>they’re willing to issue me - largely either JWTs or opaque access tokens,<br>with no support for any mechanism of binding that token to an instance. The<br>token that’s going to have to be provided to the remote service is something<br>I have little influence over. But that doesn’t mean I can’t influence the<br>token that lands inside the agent’s environment. I can issue a placeholder<br>token to the agent, and force it to communicate via a proxy that swaps out<br>the placeholder for the real thing. The worst the agent can do is exfiltrate<br>the placeholder token, and as long as malicious actors don’t have access to<br>that proxy, it doesn’t matter - nobody else can do anything with the<br>placeholder.
This isn’t a terribly novel insight, and it seems like almost everybody has<br>reinvented this on their own. But a lot of these implementations involve you<br>somehow obtaining the real token in advance and then pasting that into<br>something that generates a placeholder that you provide to your agent<br>environment somehow, and it’s all a bit clunky and awkward, and it also<br>means that you need to deal with something that keeps track of the mapping<br>between placeholders and real tokens and oh no we’ve just invented a secret<br>store, and if you want this to work at scale and reliably you’re just<br>invented a high availability distributed secret store, and a lot of people<br>who’ve read that are now shaking their heads and reaching for gin. Can we<br>simplify this, and improve security at the same time? I think we can!
Remember when I said “as long as malicious actors don’t have access to that<br>proxy, it doesn’t matter”? What if they do? What if they compromise one<br>machine inside your environment and are then able to email a bunch of<br>employees and convince their agents to send more tokens back to them and<br>then delete the email before a human reads it? Now you have someone inside<br>the wall with access to those tokens, and presumably with access to the<br>proxy, and now they can be anyone whose agent was gullible enough to think<br>sending them a token was a good idea. This isn’t good!
So, I thought for a while, and I came up with a new idea. We can have a<br>broker service that obtains credentials for us. We can run that centrally,<br>away from the agents. A client in an agentic environment can request a<br>token, and that can result in a URL being generated and the user being<br>directed to open a URL in a browser and authenticate....