AI Agents and Identity Management

Hello, and welcome to the AI Engineering podcast,

your guide to the fast moving world of building scalable and maintainable

AI systems.

When ML teams try to run complex workflows through traditional orchestration tools, they hit walls.

Cash App discovered this with their fraud detection models. They needed flexible compute, isolated environments, and seamless data exchange between workflows, but their existing tools couldn't deliver.

That's why Cash App relies on Prefect.

Now their ML workflows run on whatever infrastructure each model needs across Google Cloud, AWS, and Databricks.

Custom packages stay isolated.

Model outputs flow seamlessly between workflows.

Companies like Whoop and 1Password also trust Prefect for their critical workflows, but Prefect didn't stop there.

They just launched FastMCP,

production ready infrastructure for AI tools.

You get Prefect's orchestration plus instant OAuth, serverless scaling, and blazing fast Python execution.

Deploy your AI tools once. Connect to Cloud, Cursor, or any MCP client. No more building off flows or managing servers.

Prefect orchestrates your ML pipeline.

FastMCP handles your AI tool infrastructure.

See what Prefect and FastMCP

can do for your AI work flows at aiengineeringpodcast.com/prefect

today.

Your host is Tobias Macey, and today I'm interviewing Julianna Lamb about the complexities of managing identity and auth and agentic workflows. So, Juliana, can you start by introducing yourself?

Yeah. Thanks so much for having me on. I'm Julianna. I'm the cofounder and CTO of Stitch.

My background is in engineering.

My cofounder and I met working together at Plaid, worked on a bunch of fraud detection and prevention

systems there as well as some auth flows.

Ended up starting Stitch about five years ago to tackle some of the problems,

I was facing in my work,

having to build auth in house from scratch.

So Stitch is a modern identity and access management platform

providing

authentication flows for both humans and now agents as well,

and we do some some fraud detection and prevention as well. And do you remember how you first got exposed or involved in the overall space of ML and AI?

Yeah. I think, like, some of my

beginnings started when I was working at Plod on the fraud detection systems.

That was a lot of, like, I think looking at trends and patterns, right, it was not like the AI that we see today. Generative

AI is a whole different beast, but how do you look at anomalies in traffic? How do you predict sort of like baseline,

versus

anomalous patterns?

So did some sort of basic work then.

And then I think just being in sort of like San Francisco in in the tech world, like, you end up keeping a pulse on on kind of what's been going on. And, I think it's been really exciting to see over the past few years just, like, how this space has has blown up. And there's so many amazing tools out there, both to build software with, but also to to help in in different workflows. And so,

over the past few years have been going deeper on kind of, some of the,

agent space and and what that looks like in particular just given our vantage point as Stitch. We're thinking about identity. Right? And now there's, like, a new form of,

identities that you need to know about, authenticate, authorize, etcetera with agents, and so,

have been going deeper on that over the past few years.

And before we get too far into some of the technical and AI specific bits, I think it's worth giving a very structured and clear definition of what we mean when we use the word identity because it is something that is very overloaded and used across a number of different contexts. But within the space of authentication and authorization, it has a very specific meaning. And I'm wondering if you can give your view of how you think about the specifics and the semantics of the term identity.

Yeah. I think the way that I would sort of define it, for the vantage point I'm coming from is, like, an entity that,

is able to, perform some sort of actions and have access to certain resources. And how do you, so how do you sort of, like, define that entity? Right? It could be a human that's the entity. It could be an agent. It could be a machine. I think there's a lot of different, sort of applications of what that could look like. But, ultimately, it's, like, some sort of, entity that can perform actions,

that you are trying to verify that this is who they say they are and

what permissions, you know, they might have once they gain access to a system. But I think when you're talking about the authentication piece, it's very much like, do they have the right sort of credentials on their side to verify, like, I am who I say I am. This agent is who it says it is,

and what should they have access to,

once they get into that given system.

With the

introduction

of AI agents and these new nonhuman entities that are able to take actions on the behalf of humans or organizations,

how does that shift the

ways that identity needs to be conceived of and managed with the technical systems that they are interacting with?

Yeah. I think it's a really interesting challenge, and we've had to deal with authenticating

nonhuman,

identities in the past. Right? Like machine to machine authentication, API authentication.

Like, that's not a new concept.

But I think agents just sit in sort of an interesting spot where they're kind of something in between

a machine and a human,

just in terms of, like, the actions that they're able to perform.

A machine tends to be really tightly scoped in the actions that it can and should be able to perform, and that tends to be pretty easy then to lock down. A human, on the other hand, often can do a lot of different things, but is limited be because of of sort of, like, what they're able to do. Right? Like, I, as a human, can only, you know, maybe cause so much damage, for example. Right? And, like, you put a lot of trust in in humans often to behave in a certain way and,

sort of, you know, do what they're supposed to do within a system. Obviously, you wanna make sure that there are protections against them doing things that they shouldn't. But the, like, speed at which I think humans can perform actions,

is just so different compared to agents. And so now you have agents that can go off and kind of, like, do their own thing. Right? And they can do it at a pace that,

is much faster than a human can do. Like, I can only search through our knowledge base at a certain rate. Right? But an agent can go and do that incredibly quickly. And so I think permissions become even more important,

when you're thinking about agents because of that sort of, like, access that they'll have and also the ability to, like, really quickly reason through systems and perform actions.

If left unchecked, they can cause a lot of damage and and wreak a lot of havoc really quickly. But you also can't tightly scope,

I think, agents the same way you might scope machine access because in order for them to be useful,

for a human, they need to be able to, like, sort of act on their behalf, right, and and have the same level of of permissions and access.

So I think one of the the really big challenges is sort of, like, how do you wrangle this, and how do you think about,

what agents should have permission to? It should be pretty broad and expansive,

but it still needs to be limited. Right? You don't want them to be able to maybe go off and, like, you know, make right

updates to your production database. That could be very catastrophic very quickly. So kinda thinking about, like, how do you layer in that that permission structure, I think, is going to continue to be a a challenge for folks.

And in terms of

the

protocols and technologies and implementation details of identity, which also intersects with authentication and authorization,

as an industry, we have a lot of prior art, a lot of experience.

But as you said, those are typically scoped to either a human operator that is going to behave within the bounds of expected capabilities

and also only at a certain

pace. And we also have these very

deterministic

machine to machine identity use cases

that are going to be

predefined

and are not going to

randomly decide

to go do various other activities that they weren't initially programmed to do.

And

as we enter this new era where we have this hybrid situation

of these agentic AI systems

that do not have deterministic predefined behaviors and are not fully human in terms of their reasoning capabilities and their rule following abilities,

what are some of the most significant ways in which you are seeing that the existing infrastructure and existing

patterns and policies for identity

authentication and authorization are insufficient for the moment that we're in?

Yeah. So I think one of the things that I'm excited about to sort of, like, help solve this problem for both companies that are trying to expose their data, but then also the agents that are trying to build on top of that is MCP servers and using OAuth as,

the protocol there for doing authentication and authorization.

But a lot of systems aren't sort of set up to,

offer that today. Right? Like, there's definitely companies out there that have relied on integrations,

in the past, and therefore, they're an OAuth provider already. They have their identity server. They have APIs,

often that are are ready to expose some of that data.

But that's a limited set of companies. And so now I think kind of every company needs to think about how data is exposed in a way that agents can really easily work with it. Sure. Agents can do, you know, screen scraping and all of that, but that's sort of a really inefficient way both for a company to serve data to agents and also for agents to parse that data.

So I think MCP servers,

help solve that in a way that, is both efficient from a resource perspective, but also from just sort of like an accuracy perspective.

But that means that a lot of companies are going to have to build,

MCP servers and and think about how they're exposing their data,

via API. And and even if they already do have APIs, they might need to get more expansive in terms of, like, what they're able to expose.

I think the use cases for integrations have just been really different historically compared to how people are trying to use agents. Like, most cases, you're really trying to let an agent kind of, like, act on your behalf. And so,

they're going to need access to, like, you know, the management

console of of an application

that,

an API might not have exposed historically. So sort of APIification,

and and I think the application of that will end up being MCP servers, but that's still nascent and and could evolve.

So I think that's one piece of it. And then the the authentication and authorization is is another piece of that. I think everyone's knee going to need to become an OAuth identity provider.

I think that,

is a really great solve for agent authentication because,

it lets a human grant scoped permission

access to their agent.

And it's a standard that, you know, has been battle tested over many years. It's something that users are really familiar with, like, the experience of, you know, going to chat g p t, for example, and clicking, like, connect your your Google account. Right?

That's something that that people,

are familiar with. My mom's gonna recognize that flow. Right? It's not a more sort of, like, developer centric flow that is often happening today where you maybe have to go and get an API key and then, like, do all this setup and whatnot. Like, that's not gonna work

work for mass adoption, but I think OAuth is is well poised to and and something that, yeah, had has a lot of, just sort of good standards around today and a lot of I I think work is going to still need to be done to evolve,

maybe some of the the specs there to make sure that the agent use case is is really well solved.

But I think companies can already start thinking about, okay, what is it going to look like for me to both expose my data and then authorize access to that data?

And my recommendation

is is to go to MCP

and and the OAuth spec there, just because I think that's a great standard for people to get started with.

One of the other

potential challenges

that you hinted at in the description of the

difference between AI agents,

machine to machine communication, and humans is the pace at which they're able to operate.

And a lot of systems, particularly if they're a, API driven, already have some conception of rate limits.

The challenge there is that most of those rate limits are tuned to assumptions of human activity or maybe machine activity where the machine is going to expect some level of rate limiting and obey the various header responses

of when the rate limit resets, etcetera,

With the fact that agents can operate so much faster and in such varying ways, how does

that change the ways that we need to think about what rate limits are allowed, how the rate limits are applied to various types of identity, and some of the new stresses that we're going to have on infrastructure

as these agents

take over a substantial portion of the actual activity between these technical systems?

Yeah. I think it's a really interesting question, and I don't know that the, like,

full answer is, like,

out there yet today. I think this is probably going to be something that people have to, like, experiment with and and iterate on to some degree.

But I do think you'll need to kind of rethink,

what those rate limits look like for often, it's going to be the actions that historically a human has taken. Like, I think, for example, within Stitch, like, some of the rate limits we think about are, like, what is just, like, crazy behavior for a human to do? Like, you're trying to log in, you know, a 100 times in a a few minutes, and, like, obviously, a human is either, like, just crazy, like, clicking a button, right, in, like, anger or something and, like, they're having a bad time and we shouldn't let them keep going,

or, this is, you know, a high volume sort of bot attack potentially. Right? It's really easy to separate those two. I don't think agents should go and try and log into systems hundreds of times. We probably don't need to adjust, adjust, those rate limits. But there's gonna be other cases like that where something that was designed to prevent a human from, like, just, like, spiraling essentially or doing something really crazy,

actually might make sense for an agent, just the volume of requests that they might be sending, etcetera. I think the feedback question is is really interesting too. And I think this is part of the reason I'm, like, so all in on MCPs that it's still evolving and, like, there's a bunch of pieces that I think are going to need to still be figured out in terms of exactly what that spec looks like. But I think having the interoperability

of how different agents should be able to, like, interact with the system makes it just really easy to

for everyone to build integrations. Right? And I'm just imagining, like, in the rate limit case, right,

you wanna make sure that the agent is getting the feedback that they need that, hey. You're doing something wrong. Like, maybe pull out of this and and try something else. Or maybe the approach that they're taking to trying to access data is wrong, and it's resulting in in a really high,

amount of requests. Like, thinking about how that agent gets that feedback so that they can learn and,

not cause undue sort of load on your system, right, but still get what they need to get done.

And that might require some sort of, like, iteration and and collaboration too in terms of a system figuring out, okay, what are the agents

doing and what rate limit should I expect,

and how do I think then about what that means for my systems and the the load that I'm seeing. But I think I'm optimistic that the more sort of MCP driven approach and tool calling versus another approach that would be, yeah, more of that that sort of screen scraping, like, it lets companies have a little bit more sort of, like, control and predictability

about their systems and and understand the load that they're going to need to support,

which I think will be important because,

yeah, agents can just cause a lot of load on systems.

Another aspect

of being able to delegate identity from a human to an agent

is, one, that you need to be able to differentiate,

but then the other aspect is

which side of the

system should be

allowed to determine what are the

permissions granted to the agent. Is that something that lives with the human who is performing the delegation, or does it live with the

system that the agent is going to be interacting with? Or is there some other middle ground that we need to deal with, and how does that change when the agent is something external to a service provider? So something like ChatGPT

is doing something on my behalf

to then go interact with

my Google account, but Google doesn't know anything about ChatGPT.

Or on the other side of the system where maybe Google is the creator of the agent and I am delegating my Google identity to the agent, they'll then go and perform some action on my behalf within the Google ecosystem?

It's a it's a good question. And I think in the enterprise context, there's also then the, like, IT admin,

persona as well that might wanna lock down their systems in a way that's specific to one organization

versus another. And so you have to think about, like, okay, what access

do I, the service provider, think agents should have access to? Right? And define that. I think

my take is that over time, like, it's gonna be pretty unfettered

access, but you're gonna wanna be able to enable, like, some level of controls,

so that both an individual can say, hey. I'm, like, not comfortable with this agent going and making certain right actions, but the rest is is totally okay. You also might have IT admins that wanna lock that down for an entire organization, right, and say, hey. End users can choose between this set of scope down permissions, but I'm only allowing this subset of permissions to agents period within my organization. And I think especially for that more sort of, like, external use case, that's going to be really important. I think it's a little bit different, like you're saying,

if the agent is internal to a given system. So if it's a a Google agent, right, I think you don't have to think about, like, this other third party that you're trusting in that use case. And so, I think it's more understanding from then the, like, Google side. Okay. What do I think an agent should be able to do? You probably still need to have some of those system

controls in place so that if necessary,

you can let the IT admin,

sort of figure that out and let them lock it down as as necessary.

The other interesting aspect of

bringing agents into the equation

in terms of the scoping of identity

is that

for a human, you're going to have one identity

per system. Obviously, that's a

gross overgeneralization.

There are people who have multiple accounts within a certain provider, etcetera. But it's going to be a fairly limited scope,

whereas,

particularly, if you're talking about a system

where

an agent

is

performing some broad range of activities,

that agent might proliferate the sense of identity where maybe you have one of the anecdotal places that I've heard about this is in the context of

an agent that needs to manage some sort of state storage, and so it is given permission to go and create a database instance with some database provider such as Neon or,

the Fly PaaS.

And so

I've spoken with people who have said that, actually, the vast majority of databases that get created are created by these agents and not by humans. And so, obviously, that

creates some different challenges and different ways that you want to optimize your service for

those agentic access patterns. And I'm curious how you're seeing

people who are on the receiving side of this of having agents interacting with their systems and needing to be able to provide services to those agents on behalf of some human,

how does that change the ways that they need to think about the scope and scale of identity that they need to be able to maintain?

Yeah. That's a it's a really good question. And I I think,

like you're saying,

the there's certain use cases where agents are already just, like,

so impactful and and kind of running wild. Right? And so you're seeing I think especially in sort of, like, the dev tools world, like, a lot of to, like, navigate this and and figure it out already just because it's happening, and agents are powerful. People are using them.

I do think that how you think about, like, building and scaling your systems

might have to evolve depending on how agents are interacting

with your systems. Right? So I think that database example is a really good one, right, where historically

humans could only probably create so many databases

in a given day. Right? And now you can sort of spin up agents left and right, and they're going in and provisioning them. So then how do you think about, like, what it means to be a provisioned database? Right? How do you think about how long that should maybe live? Like, how do you think about basically protecting your systems from being overloaded but making sure that the human that's trying to, like, get something done is not sort of impeded because

you're imposing too many limitations

in terms of what agents can do. So I think people have to to really think about, like, what are the workflows here that agents are going to be really effective with, and how do you make sure that you are unblocking them? But then also doing that in a way that is helping the user ultimately solve the problem that they're trying to solve? I think,

yeah, it it's definitely just going to be somewhat unique to each system and in terms of what services you provide. Right? Is it something where

agents are doing just, like, a ton of,

read actions, or is it something that is more sort of creating resources?

Right? That might look different, just for different companies too. But I think understanding those agent use cases is gonna be really important so people can design systems accordingly.

And the other

aspect as well is the persistence of identity where

when you have a human, the identity is typically going to be log lived because that human is going to interact with that system multiple times over varying timescales

with no with not not necessarily any degree of consistency.

So you need to be able to persist the identity for an indefinite period of time in the event that the human does want to interact with that system.

How does that change when you're thinking about agentic identity where

an agent

is delegated some permission scope, it goes and performs some action or series of actions over an indeterminate period of time?

What is the

how does that change the way that service providers need to think about how long to maintain that identity for?

Yeah. I do think some of this also comes down to kind of, like, use case and the agents that are interacting with your system and how, like, persistent that specific agent might be. Is it something where people are spinning up a a bunch of different ones,

or is it kind of for example, I have ChatGPT

connected to, like, my Google Drive account. Right? I kinda always want that connection to be in place, and that should be pretty long lived.

But I could see other use cases where I want to, you know, maybe allow,

for my session the day, whatever, access to some system and then say, hey. I I don't want this agent to have access after that. Being able to configure sort of, like, the session length for agents, I think, is is really important too.

So you can say, yeah. I wanna grant access, but I don't want to grant access forever and always. Right? I wanna be able to, like, reauthenticate

if if I wanna grant access again in the future.

So I think that's going to be one example of of sort of how that pans out. I think also giving people controls over, like, their connected accounts,

so I can go to my dashboard and see, you know, which agents have connected to that given service provider and maybe, you know, remote access. If I say, I don't really want this one to have access anymore, giving people that central,

sort of consent management and,

be able to revoke that consent is going to be, I think, valuable as well. I think there's just gonna have to be a lot of tooling that that folks are building out around this.

Another aspect

of identity and access

and managing controls around

machine capabilities in particular

is as somebody who is operating a system

for

since since the Internet has been around effectively,

we have also had issues around malicious actors trying to use some sort of automated

means of access gaining access to systems.

And so that has led to a whole industry of bot detection, bot refusal.

You know, recaptchas are kind of the canonical way that people visualize that.

And I'm wondering how the introduction of agentic capabilities

changes some of that paradigm of

deter detecting and mitigating

the malicious actions of automated systems.

Yeah. I think it requires people to evolve kind of how they think about bot detection.

Historically,

in most use cases, bots have just been bad

across the board. Right? But now you have good bots,

their agents that are trying to act on behalf of users. I think I I'm just gonna, like, keep beating the MCP drum, but I I do think that is one of the reasons that MCP is really great is if you are able to build an MCP server and expose that, then you can have that, like, really clear access path for agents.

But I think it's definitely going to be time before that,

spec is, like, fully baked and everyone has adopted it. And so in the meantime, I think agents are just going and, you know, trying to,

sort of act on behalf of users in a a less sort of, like, sanctioned and permissioned way. Right? They're using screen scraping,

headless browsing, etcetera.

And I think it's important for service providers to be able to decide what they want to allow. So we have a a device fingerprinting product that basically lets you identify, like, exactly who and what is on on your site. Is this,

someone just trying to commit abuse? Is this a chat JPT agent? Is this a Claude agent? Like, who exactly is this, and how do you want to,

grant access? And something that we think is going to happen too is that people are going to design different experiences

for agents versus humans.

So we have, like, a a nice little,

helper function that's basically called is agent, and it tells you if whoever's on your site is an agent or a human and which agent it is,

so you can design a different experience. Our, like, demo site basically shows this. Like, there's a very image rich version that we surface to humans, and then it's a very sort of text heavy version that

is surface to agents because that's going to be easier for them to parse. It's gonna be probably less expensive for you to serve, and, you're gonna give the people that need this experience,

humans or agents, the right experience depending on who they are. So I think a lot of that will will end up having to happen. I think there's also, like, a a difference,

that I think is sometimes missed in in some of the discourse around sort of agents

on websites.

There's, like, the sort of scraping for content that LLMs are doing, and then there's, like, agents that are going and acting on behalf of humans. And I think different sites are probably going to want to treat those very differently. Right? Like, I understand

why, you know, Reddit, for example, probably doesn't want ChatJPT,

like, scraping their data to train their LLMs on, without sort of any commercials in in place there. But I'd love if, like, my ChatJPT

agent could maybe, you know, like, go and and read some threads for me on Reddit and maybe post a comment so I don't have to, like, leave my my chat gbt interface. I don't think that's, like, the perfect example,

because,

Reddit does a lot in terms of UI. But you can imagine a situation like that, right, where,

people wanna distinguish not just between, like, is this OpenAI

on my website, but between, is this, like, a human backed agent on my site, or is this,

sort of scraping for content,

LLM sort of based approach?

So I think people are going to need to think a lot more about this in terms of how do they identify traffic. I think stuff like CAPTCHA is is just pretty outdated at this point. It's not really going to to stop bots, and it might stop bots that you don't wanna stop, but also I think is is pretty solvable,

in most cases already. And so,

people are going to need to find sort of new approaches to this and rethink how they block bots too, now that there's more of those good bots out there.

To the point of permissioning and authorization

and allowable actions

for the agentic use cases,

that is something that has been

technically capable for a long time, again, at the human operator level, at the machine operator level.

But it's also something that is typically

underinvested in by a lot of people who are building systems because it is very complicated to do right. It is very complicated to do well.

There are various opinions about how to manage that authorization.

There's RBAC, ABAC, etcetera, etcetera. The acronyms go on.

And

in terms of your experience of working with people who are adding some form of identity and access control to their systems,

what are you seeing

in broad terms as far as the shortcomings

of existing

capacity for being able to actually

effectively manage the more granular permissioning that is necessary

to allow agents to do work without also doing harm?

Yeah. I think there's some cases where people are going to need more granular permissions

than they have today and might have to evolve,

from, like, a more traditional RBAC system to something like ReVac.

I also think there's a lot of folks that just need to clean up their RBAC implementation, because I I often see the sort of pattern with agent use cases is that people generally want read access for the agent to most things, and then they wanna limit write access to certain resources. And so you can model that with a a pretty basic RBAC implementation,

but the way that you think about, like, write actions and bifurcating them might be a little bit different than you've had to think about historically.

Right? So I'll give one example that that comes up all the time with GitHub.

The way that they model their permissions is basically to, like, do anything, create a PR, etcetera.

You need to give

full write access.

That's just how they've they've managed their sort of permissions and scopes. And I wanna give full access to, you know, Carcer and and these other coding agents

to do everything but, like, make a commit. Right? So you can have protections in your repos so that you have to get approvals and and all of that. Yes. But it'd also

be a a lot cleaner if I could say, like, at this like, I wanna give these write permissions,

to these resources, but I don't wanna allow write for for certain other permissions. So I think there's some folks that probably do need to think about things like specific access that you might wanna be granting. Like, do you wanna be able to, for, like, Google Docs, for example, grant access to your agent to certain Google Docs and not others? Google already has, like, very complex permissions modeled out, and and so that's that's doable. There might be similar types of companies that haven't had to think about that and and then to think about that more sort of like Google Zanzibar type permissioning. But I think there's a lot of cases where there's just some basic kind of, like, cleanup in terms of permissions that now that you're thinking about it from,

the perspective of, like, what do you want to let an agent do, you might wanna revise how you sort of bifurcate those permissions, and, it's going to be pretty straightforward.

But I do think everyone just is going to need to be thinking about this and probably making some tweaks to how they've thought about,

structuring their own permissions.

And that also brings up the question

of where, when, and how often do you establish

and verify identity and allowable

actions where,

for the most part, the typical design of a system has been as soon as you

land on some action that requires

authentication,

you are

redirected to some login page to establish your identity and then redirected back.

And then once that is done, you are

largely left to do whatever it is you want to do within the confines of the system. So it's largely a perimeter security

rather than something that is the sort of zero trust

is is the term that's used in networking

spaces, but the more defense in-depth approach of, okay. Well, you've ident you've verified your identity

right here, but now that you're doing something else, you need to verify your identity again. I think most of the time, people have experienced that on the account,

settings page or maybe they want to change their password or their email, so they're asked to authenticate again before they could perform that new action.

And, again, to the point of

many systems

have

an insufficient level

of security

implemented, what are some of the patterns that you're seeing as far as the

lacking

of the appropriate controls and ways that people who are building and operating these systems need to be thinking about layering in new securities

as agents

become a larger portion of their traffic?

Yeah. I think

people are going to want to have certain actions that agents can take but require a human in the loop approval. One example we're seeing is, like, with payments, for example.

You wanna let the agent do the payment, but you don't wanna let it do it without getting the human sign off, and so you wanna gate that. And this is where OAuth,

is really strong. They there are,

RFCs in place for doing things like a client initiated back channel authentication, which basically says the client so,

let's use Shopify. I'm trying to buy something online. And, basically, Shopify wants to say, okay. This agent can have Chargebee T can have total access to the Shopify store that I wanna browse, right, for everything except for making a purchase. And then we're going to kick off a required,

sort of authorization

to the human and and require them to go through that OAuth consent flow to say, hey.

I'm authenticating.

I'm a human, and I'm approving this, but still let the agent go forward with the the transaction. Just require that human in the loop approval. So then you'll see use cases like that where there's, yeah, certain right actions, destructive actions, or just highly sensitive things that,

you still want the agent to be able to perform, but you just wanna do it in a more sort of, like, supervised

way with that human loop approval.

As the capability of agents evolves, that obviously changes the types of actions that should be allowable,

the types of actions that are even possible to do correctly.

But then there is also the challenge of

an agent

conceptually can complete some task, but may have a high error rate as far as doing

it properly,

which also brings up other challenges around how to properly engineer a system,

item potency being one of them.

And, obviously, that is beyond the bounds of identity specifically,

but

I'm wondering how you're thinking about the

expectations

of a system for certain action to be done properly and how to manage some of that feedback to the agent and guide it appropriately

to say, hey. You're doing it wrong. You need to do it over here. I know that MCP provides some capacity for that. So I imagine that's the preferred means of exposing

capabilities of your system for an agent to interact with. But in the event that somebody

chooses to not use your MCP interface and use your system anyway or other ways to be accessing the system? How how should we be thinking about the ways of identifying

who is performing an action and what expectations we should have around it, doing it properly,

and,

you know, the the frequency of that action, especially if it's done wrong the first time?

Yeah. It's a good question, and I I think the way that you can

incorporate that feedback

might be different with different systems. I think the coding agents, for example,

do make this somewhat easy. They have

the different markdown files that you can have. You can have, like, cloud. Md, right, that has sort of, like, your guidelines and feedback. I think, different

service providers might need to think about,

exposing

things to

their users to be able to put in those types of files. Right? Like, ideally, you don't have to go and copy and paste some stuff, but I think that's kind of just the state of the world right now. So do you have, like, an l 0m.txt

that has a bunch of,

sort of maybe,

instructions

for agents,

to be able to understand,

how to work with your system? Like, we see this with people using Cursor, Cloud Code, etcetera, to integrate Stitch into their systems. There are certain nuanced things about how Stitch works that are really obvious if you're a human.

Like, on our docs site, we have two different product lines, for example.

And agents just tend to get the two confused and, like, try and, like, implement things that, are only available in one product line, in the other, stuff like that.

And so we've, like, written some instructions that people can copy and paste into,

their coding agent of their choice, that sort of give the the agent some direction around, like, how to work with Stitch.

So I think you're gonna see some stuff like that. That's, again, I think more of, like,

the, sort of, developer centric world where

you can ask a a developer to go and copy and paste that, and they'll understand what they're what they're having to do. But I think

it's still early in terms of, like, how other service providers are are going to, like, implement that type of a feedback and instructions. And I think MCP

does just make it easier because there's tools,

that are

really easy for the agent to discover and call, and, like, that just makes it harder to to make mistakes. Right? But I think there's probably going to need to be more than that. I'm just, like, not sure what it is in sort of the, like, mass adoption,

approach yet today.

And in terms of other engineering efforts or design considerations,

architectural

shifts that

engineers should be considering and system operators should be considering as we

increase

the numbers and capabilities of agents? What are some of the concrete steps that you're advising

in your interactions with your customers or people that you might, speak to within the industry?

Yeah. I think that example

I just mentioned of, like, our two different products and that confusing agents, like, we've known it confuses humans for a long time, and we've spent a lot of time trying to, like, articulate that and and make it more clear. And I think agents will just, like, sort of put China spotlight on challenges like that. So I think if your API is, like, hard for humans to understand, it's gonna be even harder probably for agents to understand. And so I think we have spent a lot of time, you know, thinking about developer experience as an industry, right, and have made a lot of strides there. I think agent experience,

sometimes is going to require, like, different experiences,

but also I think just, like, will really sort of, like, stress test your systems and how easy they are to, like, understand and work with. And so I think people are going to need to think even more about that in terms of, like, can, you know, an agent understand

these APIs, this MCP server, how data is modeled, all of those things. If there are really, like, nuanced tricky things that you're seeing humans, even with a ton of, like, you know, visual explanations and all of this context understand,

probably is going to be hard for agents to understand. And so I think people will just need to think about, like, how their data is structured, presented, all of that, so that it's really clean and easy, for agents to work with.

Speaking

from an example of what I'm currently dealing with at work

is that

one way to maybe help

bootstrap

that work of

improving the ways that your systems can be accessed by your agents is

by building your own agents or

LLM powered use cases

for your own internal uses or uses focused on your customers, and then

that will be a forcing function for your systems to then be friendlier to those agents as well. So,

concretely,

we

are at my day job building a set of API powered

applications. We're actually rearchitecting

multiple applications into one SOA approach,

and we have

a handful of bot use cases for helping people navigate the system.

And in order to be able to expand the capabilities of those bots, we then want to expose some of those existing APIs, which then necessitates the creation of MCP servers that can do the translation

on the behalf of the bot. And so that is something that we're currently going through, and I think that that is an interesting and useful way for organizations

to

find some of those edge cases before they have to expose their customers to them or before their customers find them for them and they have to quickly play catch up.

Yeah. I think that's awesome. I think, that's a a really good approach. And, yeah, we we do something similar both in terms of, like, building our own MCP server and then using it as part of, like, building demos, example apps, etcetera, so we can understand, like, how our customers are are going to work with it. But I think we we've been talking about trying to do some more internally just to, like, sort of dog food both LLMs generally,

but then also our data, our systems, and how,

people might interface with that to better understand kind of, like, our customers' use cases and and all of that. So I think, yeah, trying it out and and seeing what happens is is one of the best approaches.

And as you have been working in this space, working with some of your customers

and

staying up to speed with the identity aspects of agents and all of the nuances that go along with them? What are some of the most interesting or innovative or unexpected ways that you're seeing organizations

address that challenge of the intersection of identity and permissioning?

Yeah. I think it's a it's a good question.

And I think, like, some of what we're seeing right now is definitely,

colored by kind of, like, you know, who are going to be the first movers in this space. And I think you're seeing a lot of dev tools companies invest in building

MCP servers. Right? Because coding agents are super popular and also support remote MCP servers, and I think adoption beyond that is still, like, pretty nascent. And so I think what you're seeing right now is, like, a lot of those dev tools companies, especially smaller start ups, wanna just, like, really sort of, like, open the floodgates and say, hey. I wanna let agents work within my system. I wanna see, like, what they can do. I think to a degree, like, making sure that, you're putting some limits on on kind of, you know, maybe the most destructive right actions, for example. But I think people are trying to kind of, like, kind of like you were saying, right, like, stress test systems and, like, figure out, like, what is possible because this is all so new. And, I think people are trying to experiment and and sort of figure things out. And I think you're seeing that also sort of impact how things like the MCP spec are evolving and making sure that the the feedback that people are getting from, like, their customers, right, in terms of, the limitations that they might wanna have in place and, just, like, how these these systems are working as you get to more kind of, like, bigger enterprise context. I think that's leading to things like dynamic client registration, for example, has been just sort of how

MCP servers have registered themselves.

So a remote MCP server

will let any sort of agent

client of that server register

and just, like, get provisioned access for the user. But I don't think that's how, this is necessarily going to work in the enterprise, and I think that's something that's kind of, like, come to light as as people have been, testing these out. It's like, you don't wanna let any client necessarily register. You probably want to, like, allow list certain clients that can register.

You wanna give people more sort of, like, controls and access. And so I think you're seeing people kind of, like, yeah, stress test things right now,

and that's leading to, I think, good insights and kind of, like, evolution of maturing the MCP spec so that it's going to be able to solve some of these more kind of, like, high stakes enterprise use cases.

And in your experience

of working in this particular

space of the industry at this point in time, what are some of the most interesting or unexpected or challenging lessons that you're learning that you've learned in the process?

Yeah. I think I have been speaking so positively about MCP. Right? I'm really excited about it. I think it's great.

But I also think it just really highlights, like, how hard it is to get standards agreed upon. And if you try and, like, use

the the ChatGPD connectors product,

the, like, quad web or desktop

versus quad code and how

those all connect to remote MCP servers, Cursor, They're all are slightly different. There's different flavors. So there's a spec out there. Right?

And,

it still isn't quite enough to get standardization. You still have to do a little bit of kind of, you know, like, one off sort of customization to make sure that your remote MCP server works

with all of these different clients, which makes sense. Like, people are gonna have different interpretations

of the spec. But I think it is just like

I think the challenge of interoperability

is really important for agents because you want to be able to, like, yeah, build this MCP server that's going to work with all of these different clients so all these different agents can interact with your systems. But that means that they all need to, like, implement the same spec in the same way so that you don't have to build, like,

10,000 different versions of your remote MCP server. And I think we're just, like, not quite there yet. We're getting there. We're making progress. But it's just really hard to get all those different types of organizations,

fully on the same page.

And

in terms of the forward looking predictions

for identity,

how it's going to evolve, the requirements

around it that we will have, what are some of the things that you are projecting or planning for as you continue to iterate on your own business in this space?

Yeah. I think,

we are really bullish on what OAuth is going to do here, and so have been investing a lot

vested interest in,

that taking off because we can help people solve that problem, so that's great.

But outside of that, I really do believe that OAuth is going to be,

a great solution for agent authentication and authorization.

Because it is a battle tested standard, there's probably gonna be some things we need to evolve. It's something users are familiar with. And I think people are just going to have to, like, think about what that means for their services and systems, and a lot of folks haven't had to think about that historically. So I think MCP is is really exciting and interesting. I think it's, like,

showing a lot of promise in terms of being fully adopted as the standard, and I hope it continues to evolve, and and that is also what takes off. I'm, like, maybe slightly less confident that MCP will be how agents work in, like, two or three years versus I have much stronger confidence that OAuth will be how they're getting permission to access. So we'll kinda see what happens. I think it just is evolving really quickly, and it is hard to know. Like, a year ago, no one was talking about MCP. Right? And and now there's, like, thousands of companies that have adopted it. So, a year from now, I could be totally wrong in those predictions.

Yeah. On the specifics of MCP, I think it'll be interesting

as

newer models and newer architectures come out. I'm thinking in particular of some of the large action model style of

foundation models, how that will change the

way that tools are

conceived of and represented and what the capabilities of those agents are

when they go beyond having to formulate some arbitrary language constructs to be able to actually execute any actions.

I think that's a really good point. Like, there's just so much that could change. Like, what an agent looks like and how they operate could look so different a year from now.

There's so many different factors at play.

Are there any other aspects of this confluence of identity,

access, permissioning,

and systems design that we didn't discuss yet that you'd like to cover before we close out the show?

I think my only, like, I don't know, maybe slightly hot take is that, like, this is happening. And so anyone who's, like, resistant to agents interacting with their systems, I think, is just going to kinda be left behind or, having to scramble,

to sort of figure this out. And so I think it's not a question of, like, if agents will take off. I think it's more, like, when will they work in a way that is able to get mass adoption, and I think we're already starting to see a lot of that happen. And so I think getting out there and, like, experimenting and trying things out and starting to think about how your systems will work with agents is just, like, super important. Like, the best time to start thinking about that was probably a few months ago. And if you haven't started, now's the next best time. So I think

just, like, yeah, it's coming. Agents are awesome. I think when when you test them out and and start to work with them, it's just, like, really amazing what they're capable of. And that means that to get them really successful, we're gonna need to think about, like, all the different systems that they're integrating with and making sure that they have easy, seamless interactions in a way that I, the user,

can feel confident in and and good in. Right? And that they're not gonna go off and and cause havoc for me. So I'm really excited about it and, yeah, I encourage everyone to to kinda dive in and and start figuring it out.

Alright. Well, for anybody who wants to get in touch with you and follow along with the work that you're doing, I'll have you add your preferred contact information to the show notes. And as the final question, I'd like to get your perspective on what you see as being the biggest gap in the tooling technology or human training that's available for AI systems today.

That's that's a good question.

So

I think

there's so many different ways that people are using agents,

and that's, like, okay right now in terms of, like, how we're experimenting.

But we were just, like, going through this with,

quad code and how different people on our team use quad code. And, like, if you looked at each person's setup and usage, like, you would think they're using a totally different tool. And, like, maybe that's that's how this ends up panning out, but I also think that just makes it really hard for, like, everyone to get the most value out of these tools. And so we're trying to do a bunch, like, internal knowledge sharing,

to, like, help people understand how to better utilize the tools at their disposal. But I wish there was something that was, like, a little more baked into the tools themselves that, like, helped with that. So there wasn't quite so much on each individual person to figure out, like, how do I get the best usage of all of these different tools? So I don't know what that looks like. I don't know if that that's, like, a a reasonable,

like, ask to have, but, I think figuring out how that sort of, like, learning curve can be a little bit less steep, I think, is is probably going to be really important.

Alright. Well, thank you very much for taking the time today to join me and share your,

understanding and knowledge and experience around these challenges of identity and how they intersect with agentic use cases. It's definitely something that is very important and something that we all need to come to grips with. So I appreciate the time and effort that you and your team are putting into making that a more tractable,

a more tractable problem, and I hope you enjoy the rest of your day. Awesome. Thanks so much for having me on.

Thank you for listening. Don't forget to check out our other shows. The data engineering podcast covers the latest on modern data management, and podcast.on it covers the Python language, its community, and the innovative ways it is being used. Visit the site to subscribe to the show, sign up for the mailing list, and read the show notes. And if you've learned something or tried out a project from the show, then tell us about it. Email hosts@AIengineeringpodcast.com

with your story.

AI Engineering Podcast