Insecure Agents — Episode 47: Sergey Burykin, Senior Software Engineer on the AI Security team at Uber
Podcast: https://insecureagents.com
Listen: https://open.spotify.com/episode/7cren32FmDiiiFY9XFXMWT
Transcript (auto-generated, lightly edited for clarity).

Allie Howe: Welcome to another episode of the Insecure Agents podcast. I'm your host, Allie Howe, and today I'm super excited to be here at AI Engineer World's Fair day two. I'm here with Sergei Furiukin. He is a senior software engineer at Uber, working at AI security there. He helped write the article that Uber published in May titled The Identity Crisis for AI Agents. And super excited to dive more into that and understand, okay, what is the agent identity crisis? How did Uber solve that? And what other interesting things is Uber working on today? Sergei, would you like to introduce yourself?

Sergey Burykin: Yes, of course. Hi, Ali. Thank you so much for the invite. So, my name is Sergei. I've been working as software engineer for almost a decade. I've been working in different areas and industries. I started with telecommunications, then transitioned to advertisement technologies, and then to banking. Then I was a, a funding engineer in the Y Combinator Bay startup called Jitsu. We built some open source segment of core alternative, and now I'm here at Uber working on some exciting projects like securing AI, agent identity and authorization

Allie Howe: Amazing. All right, so that article was, that you wrote was titled Solving the Identity Crisis for AI Agents. What's the identity crisis?

Sergey Burykin: Right. So let's start with from the beginning. Historically we used to have our identities for services and for personals. Basically, all this kind of identity is static, and you configure rules based on who can access what, what service can access what service, and then what user can access what service, basically, what resource. So with agent, the, the industry shifted to some dynamic tan- trends. So basically you don't wanna limit your agent accessing only some specific services, and you don't wanna configure this sta- in, in a static fashion. So as well as since agent become more dynamic you would like to know what happened at every hub, right?

So you might have multiple agents calling each other and then call, hitting the resource. And as a enterprise, you should be able to first apply right authorization policies. Second, have a good observability in order to investigate in case of any incidents and so on and so forth. So it's a completely big shift in terms of how we how we work with identities.

Allie Howe: Yeah. Yes, absolutely. 'Cause agents are working on behalf of users, but also increasingly on behalf of other agents. So there's a lot to think about here in how identity evolves and also in these multi-delegation chains, which you get into in, in the article of like, okay, there's all these like multi hops happening from the user delegates something to agent B, and then agent B maybe needs to use a browser agent to go out to web, which is agent C. And like, does agent C have the permissions of the original user? Is it a subset? Is it based on the agent's permissions in addition to the users?

Is it like some like weird, like union between the two? Like, how do you all think about that?

Sergey Burykin: Right. This is actually a really good question. So I, I think we should we should model our authorization systems as a- Kinda, you know, consider both user permissions and agent permissions, and agent permissions should not extend user permissions. So the the final set of permission that is being evaluated at the source should be intersection between user and agent permissions. So because there are, like, two problems, basically. You don't wanna just use user permissions, because then your agent can do some other calls, let's say LLM hallucinates agent making some call that user is not aware of, that was not an intention of the user. Or, and vice versa you don't want a agent just having agent identities and agent permissions because then any user that can have a- access to the agent can have access to some L1, L2 data which is strictly like business or a customer's data.

So that being said, you basically wanna authorize in both and configure both, but it's kind of different from services I mentioned because it's not static. So agent m- can make multiple calls, and we... In generally, we would like to make agent more dynamic for us.

Allie Howe: Yeah. That makes sense. And it seems like you all built a tremendous amount of infrastructure to help solve these problems around, like, you built a secure, like, token service- Yeah... exchange SES. You also built an MCP gateway. What was it like having to build all of that from scratch?

Sergey Burykin: Right. Yeah. So yeah, that's... It's worth to mention that the industry was evolving like, during the time, so there was no moment of time when we have all the challenges all together. So the first challenge was when Anthropic released the MCP protocol, right? So we start thinking, "Okay what is the current... Where is the scale," right? And the scale was on the side when we had a lot of MCP servers, a lot of APIs that should be consumed by agent, and we need to convert them to the MCP server. That's why we started this initiative at, which is called MCP Gateway, where we first we made it basically a- There's no, so low effort converting API to the to the MCP, so users don't need to basically write their own MCP spec.

They can just... We, we, we do it for them, basically, in flight. Another thing is authorization, because you would like to have additional controls over, let's say, you have a service that has billing data. You don't wanna expose it as MCP to agent, or maybe you should have some authorization, additional authorization. That's why MCP gateway is useful here, there. At the moment we were building this, there was no, I believe, open source solution for this. There was one in I believe from Microsoft which is was written in C Sharp, but we, in, in, in Toolware we use, like, Java, Go, Python, so we don't use C Sharp, so it was not a good investment to bring the new programming language and to use this product.

Allie Howe: Yeah, and I imagine it's hard to, like, invest in, like, an external solution too, with, like, how quickly the industry is changing. Yeah. Unless you're, like, super confident, okay, like, these, like, these vendors, like, really on, like, the cutting edge, the bleeding edge of, like, understanding where this space is headed, they're betting on the right protocols, or maybe they're protocol agnostic. They're, like, on the... You know, they understand, like, where Auth is headed. So you're, like, you know, you to bet on their primitives essentially, if you're not gonna, like, roll your own. And so you said, like, nothing really existed when you were building it.

Like, has that changed now? Do you think, like, maybe the industry's evolved enough where people aren't rolling their own infrastructure? Maybe there's, like, solutions on the market that exist for that, or no still?

Sergey Burykin: Honestly, we haven't looked into the, like, MCP gateway open source solution because we already have one, right? Yeah, yeah, yeah. So I believe there is some good initiatives in the industry when some companies, let's say Okta, they try to to unify a way how you share the access between apps. It's called Okta Cross-App Access. Yeah. It's really good initiative because it solves a problem of requiring user to go and to consent to every scope. So basically you would like to control the scopes at an enterprise level. That's why this solution I feel like is good, but it requires some vendor vendors to adopt it. So- So let's see how it goes.

I feel like industry is evolving and there are a lot of good companies that are trying to build open source solution, that are trying to build some other solution that, like, we need to buy. I feel like it's, it's a good direction.

Allie Howe: Yeah. No, I agree with that, for sure. And I, I saw that release from Okta. That really excited me as well, the Cross-App Access launch, and it became the backbone for enterprise managed auth from Cloud. Yeah. Which was great because it's, it's... Here's the solution that's now not only a win for security teams that are trying to manage all of these, like, OAuth islands that were out there previously. Now there's you have the ability to revoke Authentication... people's access to MCP servers from, like, the enterprise or admin level, which is great for security, but it's also, like you said, a win for developers because they only have to log in one time to the IDP.

Sergey Burykin: Yes. As well as enterprise would like to know, so basically be a central identity issuer, right? So you don't want your users go and add different scopes to the cloud code, let's say, right? You do wanna have it centrally, so you can audit it, you can track all the requests, let's say the usage of external APIs, let's say using, like, Slack APIs or whatever. So this is, this is a requirement for central solution, so you cannot rely on just OAuth.

Allie Howe: Exactly. No, it takes a whole, like, industry, and it's not just, like, one protocol. It's not just one, like, JWT token that's gonna solve the whole thing, or authorization grant rather. Like- There's so much that has to go into it, like policy enforcement, runtime security control. I know there's other new protocols in the works such as like AAuth, which is stands for Agent Auth. And the Agent Auth has this concept of a mission, like the agent's mission, built into it so you can track that over time, see if there's deviation, and then use that at the runtime layer to be able to say, "Okay, like this agent's gonna make this, like, action that's not in line with the mission, so we should, we should shut it down."

Sergey Burykin: Yeah. And, we actually have this work at Uber as well. So we have a team who is working on some guardrails. So one of them is persona guardrail. You s- let's say you have an agent, and the intention of this agent, the g- the goal of this agent is to process like metrics or logs. So you don't wanna allow this agent pushing PRs or, like, reading other data. So yeah, I think, like, AI security is generally the multilayer cake, where at the, at the foundation layer you have a identity, next layer is authorization, next layer is some runtime controls, let's say guardrails, and then some observability on top when you would like to understand what is happening.

Yeah. So the guardrails might be apply- applicable at the runtime as well as post-factum. So it also possible because you don't, you don't always have a control in runtime or let's say you have a high latency requirements, you cannot run this heavy guardrails in runtime, but you can do it post-factum and then block access afterwards, after the fact.

Allie Howe: That makes sense. Yeah, yeah, yeah. What's it like managing all of the infrastructure that you built? Is it a load on engineering? Is it hard to do that? Or is it quite simple? What does that, like, look like in practice?

Sergey Burykin: Right. So I think at Uber it's all... works pretty well because we have multiple teams who is responsible for multiple pieces. As I mentioned, the cake, multiple teams is responsible for multiple layers which makes it like, helpful and easy at some point. You still have some additional cost on collaboration and to communication to other teams what you are doing. But in general, I feel like- For sure we got a lot of new work, right? Yeah. If we look back, let's say two years back there was no requirement for managing all this new infrastructure, right? So let's say within the agents, we used to have services, so we have a good layer for deploying services, but now with agents, they're more lightweight, more dynamic, sometimes it's ephemeral.

So you do need a new layer of managing this infrastructure in order to not increase the cost, the compute cost, and to make it 100% secure. So it's always a trade-off right now between like 100% secure and the cost. And then as a company you should decide where you are on this spectrum.

Allie Howe: No, that makes sense. Yeah, I also, I also wonder, 'cause I see, you know, across the industry I have a lot of these conversation and it seems like everyone's building some sort of version of their own infrastructure for identity and Auth and it's like, well, what are the things that people are rebuilding that are the same that we could maybe have like a centralized solution for? But then like what's different? What is the customization piece? I think the guardrails that you talked about are a really good example of that, where, okay, everyone might have the same guardrail or want the same guardrail around like PII detection or the model saying, you know, not inappropriate things, whatever.

Everybody wants that, but- The car does have to be customized too. So it's like if you are Toyota and you recommend Tesla you wouldn't want that 'cause you're a different company. Right. So it's like, what's that customization piece, and what does that look like for identity and auth infrastructure today? What's the thing that everyone keeps rebuilding we shouldn't, and what should be customized?

Sergey Burykin: Right. So I think there is one, at least one opportunity, right? As we as we talked before this podcast. So, the... Nowadays, the OAuth is based on static scopes that user grants or you grant as a enterprise. But with agents, they all should be dynamic. So when you write, let's say you create two services, and you know that this service, one service have like, let's say three APIs, three scopes, another service has two. So the, the scopes list is static, and you can manage it. But with agents, it's not static. You don't know what agent will be called after the first agent. You don't know what resource will be called, because it's all about non-deterministic logic.

So I can, I can clearly see the requirement for some dynamics scopes framework, and it's... I think it's really hot topic right now. We also at Uber, we are thinking about it, how, how we should model the scopes, how we should ensure an agent ha- having, like least privileged access at any point of time. So it can be mo- modeled on the resource level, it can be modeled on the client level. So we are in between right now.

Allie Howe: That makes sense. But then what, what happens when you have an API that only has coarse-grain access? So like, for example, like I think, like, Luma's API for events. So if we wanna use that it's just one API token can do everything, can delete your event if you want to. You can't control that, like, within the API level, so you have to, like, roll your own sort of, like, permission set around that. Are you doing that at Uber? And if so, like, what does that solution look like?

Sergey Burykin: Yeah, this is also a good question because one API can, let's say, get some data with 20 fields, but you wanna give user or agent access to only some subset of fields. So I don't know I'm not aware of any solution that helps to solve this. That's why we're building inside Uber. So basically you wanna grain control, as you mentioned. This is true. So, yeah. Or let's say if you're using some sort of API, let's say third party API, like Slack API. Slack supports only, like one token, one OAuth token. So you cannot, as a user, you cannot give one agent token with reading messages and another agent token with writing mes- with permissions of, to write messages.

So this is also a problem. And then the solution would be, like, build some gateway as a temporary solution. Build some gateway on our side to manage these scopes internally. This is not, like, clean, right? Yeah. So I wish Slack change the token model and allow multiple tokens. And I feel like every company will eventually do it. They will... Because they're interested in moving towards a agentic world, right? So all the rules that were really good, worked really good at the service for services previously won't work necessarily, won't, won't work for agents. So companies should shift as well.

Allie Howe: I agree. Yeah, absolutely. Yeah, it's, it's wild to see, like, how everyone's kind of like having to solve, like, the same problem around that and what it might take for all of us to not, you know, have to do that per se. One thing that's top of mind for me after spending all day at Worlds Forum yesterday, like the main stage track was software factories. And it's hard to imagine software factories actually being real and, you know, no one writing code, having it all run autonomously overnight, like great great dream there. And I think it's possible with the raw materials we have today, with the advances and vision models capability to verify work, improved larger context windows.

So like in the loop, the agents can now track work that's been done before, so you don't have to retry things, save tokens. Like we're, we're there with the raw materials, but we're not there with the identity solutions- Right... that actually makes this usable, unfortunately.

Sergey Burykin: Yeah. Not yet, but I feel like we'll be there.

Allie Howe: Yes. Yeah, yeah, absolutely. Is there any other things you're following in the industry right now? I know we mentioned the Cross-App Access launch, which was really cool. Are you following AAuth at all, that new protocol, or?

Sergey Burykin: So, yeah we had some conversation with Okta previously, but we end up building our own solution which is not 100% Cross-App Access, but we're managing the token exchange. So what is the problem, right? So we would like to allow our users to exchange their Uber identities or, like- Uber identities to the third party token. So let's say inside Uber production you have your identities, so you can access some APIs and some authorization rules will be applied based on your identity. But when the request goes externally to the third party system, you should be able to have a token, right? So we built the solution inside Uber where you go to basically MCP gateway and then you can authorize your Slack.

And then MCP gateway knows your token, so the token is stored inside the vault. I believe Okta has this solution right now already. So then next time you come in, your token will be exchanged for the third party token, and then this token will be used for external requests. So this actually what our Uber users really wanted. Because everyone wants to configure like Slack, Google Doc with their cloud code in order to read their IDs, which is engineering design documents and write code. This is one of the use cases. So yeah, we built this, but we're really looking forward of for adoption of Okta Crosswind, because it will give us out of the box a lot of in- integrations basically, right?

Because now we need to build it For every platform you need to go and manually create this. So, yeah.

Allie Howe: Yeah, I know. It, it's very challenging 'cause, like yeah, like we mentioned, like some APIs are coarse-grained, some have the fine grain access scopes. Some MCP servers are easier to configure with OAuth than others. I mean, you can roll it a whole different ways. Like, sometimes, like MCP servers don't even come shipped with authorization. It's not like a standard part of the protocol. It's not required at least. Yeah... so yeah, teams having to do this themselves, there's just like, it's an extreme amount of like overhead once you start like getting into it. One thing, one solution that I've seen that I thought was like really helpful or interesting is, like if you'd rather use a CLI, or you'd rather use an API instead of like if an MCP doesn't exist, for example- Yeah you can use SDKs to roll it into an MCP, and then you can use that same SDK to like add OAuth on top of it in a way that's like super easy to configure.

And like that saved me a whole lot of time. 'Cause now what's really cool is like I don't have to decide like, okay, like, you know, my agent's faster with the CLI, I'd rather use a CLI. Yeah. But the one too many permission set of like a CLI is only meant for like, you know, one user and one credential set. It's not meant for the many to many that like an MCP- Yeah... OAuth is. So I mean, that's been... That saved me a lot of time. I'm curious if you've seen solutions like that.

Sergey Burykin: So we're trying, as I mentioned, we're trying to centralize all this access. So let's say there's a Jira MCP server, and then there's a Jira CLI. We're trying to nudge our folks to use Jira MCP because we would like to know this to do the audit and OZ centrally. But there's still some use cases when people are using CLIs. I would say it's helpful when company has a good CLI, so you can convert it to a skill. You don't need a, like MCP nowadays, right? You can just pay the skill and have a short instructions for the agent how to use the CLI as a skill.

It also possible, and it saves actually a lot of tokens, so it's maybe useful too So speaking more about the, what next thing might be, I think it's a sandbox. Huh. Because currently, like, I feel like every company running agents, but now is the time when people start thinking about the sandboxing because pe- like, basically, you don't want a agent making some random internet calls or, like, random API calls or touching some files on a file system. So you do wanna ensure that agent cannot... It can do only what this intention is to do, right? Yeah. So a sandbox is the next thing. And now, and then you will figure out how to optimize the cost, how to deploy one agent multiple agents inside one single Kubernetes pod, and all of these challenges right now we are trying to solve.

Allie Howe: Yes. Yeah, I think sandboxes are for sure, like, part of that solution. Like, keeping all of it, like, localized. And I've seen some solutions where they're not even adding the credential into the sandbox, so it's got no access to it. It just in- injects them as it needs it, and then it's all highly ephemeral. So as soon as you, like, you know, clone the code you need in the sandbox from GitHub, that credential to GitHub is gone. I think, I think those models are particularly effective. Yeah. And it sounds very similar to how BrowserBase built Vivi, their internal AI agent that, like, interfaces with their entire company.

So super cool how they did their credential management, but also really interesting to see how they approach adding different use cases and different users. If you're supporting an entire company with an agent, like, there's always new tools that get requested of like, "Oh, I wanna add this to it." Like, what's that list look like at Uber to keep up with those kind of requests?

Sergey Burykin: I would say, so we- We have a lot of use cases and yeah, y- you can think about it as a, Uber as a just a world. And then you have a lot of users who wants a specific API, specific features and then you need to prioritize what should be built first what is a, like a high-risk use case when we should come in and secure it first, right? So it's completely similar to, like, we as a startup building something for multiple companies, and we need to prioritize different features. I would say it's really similar.

Allie Howe: Yes. No, that makes sense. I think you're one of the few companies that have taken agents from, like POC all the way to production. You've got 1,000 agents in production I think it was referenced in the article, which is super impressive, and just, like, wanna commend you for that, 'cause I think a lot of people get stuck on the identity thing, and then they, like, don't actually ever get to production.

Sergey Burykin: Yeah. This actually also a big challenge because historically, like at Uber, we have a lot of really smart people who are trying to build their own solutions. So as a security org, we are trying to like, let's say, make identities for every framework, and this is a really big challenge. So since there is no, a single framework or a single agentic system so we cannot just build one solution. So we need to build something as a platform. We need to build some security solutions to be a framework agnostic to support multiple use cases, and this is really big challenge. So I feel like that's why we have a lot of companies who are trying to solve like identity problem from different angles, and all of them are valid.

Allie Howe: Yes. No, 100%. Yeah, it'll be interesting to see how this evolves. I know at Instra, agents are really big about building a big tent around identity and auth. Like, we believe not one single company is gonna be able to solve this problem on their own. It's gonna take all of us together, the builders, the identity experts, the protocol developers, all in the same room figuring out, like, what's the best way to solve this? And that's what we're doing tonight at, at AAuth Night here in San Francisco, is we're getting like the creator of OAuth is gonna be there. A lot of people that are pushing this space forward, trying to figure out like, hey, what are the best practices today with like, okay, OAuth and ID Jack, for example.

But like, where are we headed? What is needed for a fully AI native stack? Do we need agent auth? And how do we learn from people like you that are doing it in practice to make sure the industry evolves in such a way that we're able to develop what you all need? And I'm super excited to have, like, the support of so many different amazing companies that are in this space. Like for example, Okta's supporting the event. So is like Kernel Snyk. So I'm really excited to just like build a big tent and see how this industry evolves and how we can all just like do it together.

Sergey Burykin: Yeah. This is good. I feel like the industry is evolving and yeah, we have a space for, like, we have a lot of problems, right, in general. And sometimes it might be really hard to come up with a really good solution right now, but we need to do, like, iteration and then next iteration, and then finally we'll get... eventually we'll get a really good solution for... to cover in a lot of use case, so maybe all the use cases.

Allie Howe: Yes. Amazing. Yeah, no, I, I, I hope we, like, do something similar, like, next year, like at AI Engineer, where I get to, like do these podcasts or be on stage or whatever and just be like, "Hey, like, we figured this out." Yeah, yeah. Like, we've, we've finally done it. So I, I think we'll see that in next year, which I'm super excited about.

Sergey Burykin: Yeah. Me too.

Allie Howe: Is there anything else you'd like to share with us today? Anything that excites you about where Uber is heading, what you're developing next?

Sergey Burykin: Yeah, as I mentioned now the focus on is sandboxy. And, there is one more problem of how to distinguish agentic traffic inside the production and the human traffic. Because basically when you have a user traffic from the laptop, it might be cloud code, but it might be actual user, and you basically wanna distinguish between these two, because they are, like, guardrails or OZ policies might be different. So this is also a challenge, because you can use eBPF on Linux, but on Mac, this should be another solution. So there's multiple solutions based on the OS, let's say, because in everywhere we have, like, dev pods, which is basically the Docker container when you develop your code, or you can do it locally on your laptop, on Mac.

So this is something we are working on right now to, to figure it out.

Allie Howe: Amazing. Yeah, super excited to continue to follow along. Definitely will be super excited to see any additional articles you all put out, put out on this. And yeah, just continue to follow the space, see where it's at. So thank you so much for coming on today. I really appreciate it.

Sergey Burykin: Yeah. Thank you so much for the invite.

Allie Howe: Yeah, anytime. This was fun. This was super fun. Thanks, Sergei. Yeah.