# Agent Identity And Mission Scoped Permissions

**Podcast:** The AI Native Dev - from Copilot today to AI Native Software Development tomorrow
**Published:** 2026-08-11

## Transcript

Ultimately, the identity question is, how do I ensure when an agent does make a mistake, it doesn't do something catastrophic, I didn't intend.
This thing is built on like a probabilistic distribution.
The feature is that it can reason and it can guess over large amounts of data.
Right.
And that it is non-deterministic, that's the feature.
Right.
The bug, from a security perspective, is that it's non-deterministic.
Yeah.
The feature and the bug are the same.
And the final question is, How do I know that an agent is performing actions aligned with the intent of whoever sets that agent to do something?
The AI Native Dev is a podcast for developers and engineering leads at the cutting edge of AI and agentic coding.
Join your hosts, Guy Pajani, and me, Simon Maple, every week as we chat with the most exciting voices in AI and tackle the biggest questions facing developers today.
This is the AI Native Dev.
We just wrapped up two amazing days at AI DevCon in London.
But the great thing is that we get to do it all over again in New York City this November.
You're absolutely right.
We're going to be back in the city that never sleeps on November 3rd and 4th for more amazing sessions, really engaging hands-on workshops and much more.
Yep, all that great networking, partying, eating and drinking that you've come to expect from AI DevCon.
We think we have one of the best hallway tracks in the business and it's the perfect complement to our incredible speakers and presenters.
We'll both be in person and virtual with live streamed access to all main stage keynotes and talks.
Sign up right now for our Super Blind Bird ticket for just $100, only available for a limited time.
We're really excited to be headed back to the Big Apple.
We hope to see you all there.
Hello, everyone.
Welcome back to the AI Native Dev.
We are in kind of an ad hoc office over here, you know, actually sort of Ian's hometown, like a home base at the moment here in San Francisco as part of the AI Engineer event and really kind of enjoying a lot of AI conversations on it.
And today we're going to dive into identity.
Identity, if you've been sort of exploring the security realm of agentic anything really, has been, you know, the top.
topic of it.
Everybody appreciates that it's a foundational aspect of how do you get these agents to actually be secure and kind of work and give them some autonomy.
And so to kind of demystify this whole domain and understand how to tackle that, we've got Ian Livingstone, who is the co-founder of Keycard, that is a really exciting kind of company in the identity space.
But also, really, Ian is...
really sharp and deep around explaining things as a whole, specifically identity.
I've known him from sneak days and his sort of past companies that he's founded on it.
So we'll learn about identity, we'll learn about what you can do, and we will hear a little bit about Keycard in the process of it as well.
Thanks for coming on.
Thanks for having me.
I'm super excited to talk about identity and agent and security and this whole bundle of things together today and really help people understand sort of how one is like, what's the problem?
Why is this a...
hot topic like why is identity like identity is like kind of boring a snooze fest it's been for years you know but why is this hot again and why are people thinking about it and how that actually changes the way that we actually think about the way we build systems and also how autonomous these systems can become.
Yeah.
Well, let's talk back over here.
So let's get started.
Just tell us a little bit about what are the problems or sort of the, you know, give us a bit of a structure for thinking about identity and agents.
Absolutely.
So I think the first step we have to think about is like, why is identity even a thing we talk about?
Like if we were to step back.
And identity has been a part of computing for as long as it existed.
The minute you had a mainframe and then I wanted to have multiple users, now you have an identity problem.
Which is like, what files or programs on the system are Guy's programs and files, and what files and systems are Ian's?
And does Guy have access to all of Ian's stuff?
Or does Ian have access to all of Guy's stuff?
It's been like every wave of computing introduces this question of, well, who can do what, when, and where?
And who can access it.
Exactly.
I remember high school sort of mini-hacking, getting into all sorts of information systems that I was not supposed to be.
Exactly.
And, you know, in the rise of the internet brought about, like, when we, you know, initially it was like TLS brought about commerce.
And so every wave of computing comes with that net new security challenges we have to solve because the interaction patterns change when we introduce, like, new paradigms with the rise of the cloud and then, you know, with IAM and identity for cloud vendors, like AWS and GCP and secret sprawl.
We've always had these problems.
And so agents, like many things, as we introduce new functionality and capability like platform shift we have to reassess our security model and you know the core crux of of the identity problem when it comes to agents is this thing is built on like a probabilistic distribution it's a statistical training right it's beautiful the the feature is that it can reason and it can guess over large amounts of data right um and that it is non-deterministic that's the feature right the bug from a security perspective is that it's non-deterministic yeah And that is still a feature.
So the feature and the bug are the same.
And the final question is, how do I know that an agent is performing actions aligned with the intent of whoever set that agent to do something?
Right.
Which is like the final question of this generation is, and there's many different facts of that, right?
You've got supply chain security as a part of it.
You know, data security is a part of it.
But identity is very foundational.
Right.
And thinking through, how do I have a secure agent?
And it's also foundational to think through how do I enable an agent to be autonomous, right?
And the more autonomous the agent becomes or the more autonomous you want an agent to be, the security equation becomes much more difficult to solve.
And the systems that used to work in the last era stop working as much in the new era, right?
And I think that's the fundamental sort of like thing to understand.
And then ultimately, the identity question is, how do I ensure that when an agent does make a mistake, It doesn't do something catastrophic.
I didn't intend, right?
And so today, if you have paid attention or have read, there's lots of different agentic problems associated with identity that people talk about.
One of them would be you have supply chain attacks that result in database passwords and keys being leaked, like the most recent LightLM attacks, that the actual attack vector was how do I take long-lived API keys off of disk and use those to exfiltrate data?
But there's other problems of how do I, you know, when I use an agent, if I ask the agent to do something, this is very common six months ago, I asked the agent to optimize a database, a potential path to optimizing a database that actually believed the day.
Exactly, right?
Makes it snappy.
Makes it snappy, but that would be deeply unaligned with what the actual user wants that agent to do.
And so that's finally a question of identity and access.
And the difference between what we've had and what with agents is I actually want to give agents access to different things depending upon the job I've assigned to do or the task I've assigned to do.
And that's a very different model we've had previously.
Yeah.
So I think there's basically a few aspects that you outlined over there.
So one aspect of it is...
is the non-determinism, right?
Or the safety is like, how likely is the agent to sort of choose to do a thing that is not the thing that you would have otherwise kind of reasoned is allowed on it.
So I guess there's sort of a broader safety element and some of that comes down to, you know, harnesses and context and all that of trying to sort of steer the agent to understand the lines are.
And I guess that's not really identity.
Those are like agentic workflows.
But then next to that, I think we have sort of two aspects of it.
identity that you touch on there.
One is, you know, who is the agent?
You know, what is the sort of entity, right, that I'm assigning?
And the second is the permissions.
You know, I guess we talk about authentication and authorization in identity.
So I guess, how do you, am I kind of dividing that correctly over here?
And maybe if we put...
Safety is a massively interesting topic on its own.
But do you think they're intertwined or do you just need to worry about all of them?
I think when a business, when you step back and ask, is it safe?
Or another way to think is, do I trust an agent to be able to perform this action?
Identity and access, delegation, all these things are fundamental components of that as they are in every other era of computing.
And to a certain extent, when it comes to identity and access there you you'll have deterministic controls around what agents can do and you'll have non-deterministic controls and like a good example is like safety work often is about how do i bias a model into ensuring that it is it is not affected or has you know it does the outcome i want so it's not going to do the bad thing or has less probable to do the bad thing but from a security equation you want to say, well, there's a set of things that just want to never happen.
I don't want a guardrail.
I want a hard boundary around what it can do.
And part of this is also the reason why things like Sandbox are very popular right now.
It's like, I can never 100% know the model may not do this.
But in order for me to put this in production for this type of workload or perform this type of task, I need to ensure that it has a hard boundary so it can never happen.
So I can say as a business that, yes, you know, the worst case scenarios that I worry about have actually removed from the equation and then the rest of the things that are left, it's like kind of okay if that happens.
Like it's not great if it does something weird, but it's not going to destroy the business or result in lost customer data or on and on and on it goes.
So there's one aspect of it is defining the sandbox.
So you're saying...
I know that these things won't happen.
Exactly.
And if I want the agent to do useful things, it might not delete all of my inbox, but I'm still getting it to send emails.
Exactly.
So it can still do unsafe things over there.
Yeah.
But if it doesn't have access to my HR records, it's not going to send those HR records outside.
Okay.
So we're talking now a little bit more about that sort of boundary zone.
Exactly.
So what are the types of agent identity conversation that we have?
Yeah.
I think there's...
one is like sort of where we're coming from right and if you look at sort of the identity systems of last generation like the way i would give a piece of software access to something is i'll give an api key it would maybe you know service account would represent a service account potentially or maybe represent a user because it was a user's api key or personal access token it was like we built a world based on shared secrets right and and the issue with shared secrets is They often bound strictly to a specific identity.
They bound specifically strictly to a set of permissions associated with that long-lived secret.
And the more important thing is if that secret were leaked, anyone who got access to that shared password also could do that thing.
And now the fundamental challenge is, okay, knowing that that's where we came from, how do we move to a world where...
I want, you know, I'm guide to journey.
I want, really want this agent to operate a very long period of time on my behalf because it's going to have access to my Gmail or have access to my Google Drive.
But if at any point it needs to perform a write action, so send an email on my behalf, I should probably approve it.
Right.
And how, like fundamentally the process we're going through is as we go up the autonomy curve.
So we go from, I love to use like self-driving car analogy, as we go from level zero, which is, you know, deterministic software pre-chat GPT to, you know, co-pilots, which is like, you know, level one to something that's like slightly or tab complete from cursor to sort of like cursor agents and cloud code agents, which are like level two as a human still involved.
How do we actually go from a world where like, as we go up that autonomy ladder, I'm retaining security over what that thing's doing.
And if, you know, currently if you were to use Cursor or Claude, when it goes to a tool call, oftentimes they're saying, hey guy, you sure you want to do that?
You always want to do that?
No, you don't want to do it on everything.
And so the question is, you can't have autonomy when the human has to constantly be in a loop, which is where these access systems come in, which is saying, as I go up the autonomy ladder, so as we want to get to this sort of self-driving car analogy, there's a...
trust and safety equation that associated with that, which is how do I keep this thing driving on the road instead of like driving off the road, off the cliff or whatever has to be done.
And that's at the crux of it.
what we're actually all talking about.
Right.
Yeah.
So I feel like the word identity is like, it can be a little bit confusing here, right?
Because there's like one question is, I've got this agent, it's running on my behalf.
Can I know that it is the agent?
Yeah.
So like I feel when I hear identity, I think primarily about who is it that is acting?
And that might be, you know, is it me talking or is it my agent talking?
So a system can separate the two of us.
It might be, is my agent talking to another agent to perform actions on its behalf?
So it's kind of, you know, agent.
all the way down, right?
They cascade down.
So that's one aspect.
But a lot of the attention you draw is actually to its decisions almost, right?
As it comes along, it might be, it's around the communication of when I delegate a task, what is not just the knowledge that it is my agent, but rather what is its scoped permissions right now within this world.
Like you can compose the email, but you are not allowed to send the email.
Exactly.
So is that, I guess, people will, like, again, the word identity is used for the market on it.
Exactly.
How do you separate this sort of authentication from authorization?
Yeah.
So this is interesting, right?
Because if you look at, in the identity world, the cloud, when we, getting to the cloud was really about, can I identify, so authenticate, that Guy Prajerny is, in fact, Guy Prajerny when Guy goes to Google Drive.
Like, that, the basis of cloud was really focused on that, and authorization didn't really.
fall into the problem space.
And that's because at the time, we didn't really have to solve authorization.
And we didn't have to solve authorization because if I could identify that it's Guy and I trust Guy, then I can give Guy really broad-based access.
Because implicitly, we've done the background check, we called all the references, he isn't a sociopath, right?
It turns out...
I did well.
Yeah, you did hide it well.
It turns out that Guy really cares about how people think about him and he wants to do a good job.
And it turns out if he got fired from the job, that'd be devastating.
So implicitly, we can trust that Guy is going to operate with high intent and not be malicious.
In part is because it's the same Guy that will sort of come into the next task and the next task.
Exactly.
While the agents are basically a brand new creature every time.
Exactly.
A brand new creature every time with completely different context.
And they don't have...
They have no sense of is this good or wrong.
Like they're not malicious.
Yeah.
Right.
They just don't know.
And there isn't a way for them to say, do I know or do I not know?
Right.
That's authoritative in a way that a human can be.
And so from that perspective, agents really change that equation where it used to be that, OK, if I just know it's a human and I trust that human, once it's all configured, it kind of works.
Now it's based on the thing that I've assigned them and the data they have about that thing.
I'm going to give them different levels of access based on what's in that context window.
And so much about this next generation is it is about authorization, which is how, what things can this do, but it's also about what things has this agency done.
So I know that it is in a well-bounded box on whether it should have access to that.
And if I can't call that judge, if I can't make a decision, like a system can't make the decision, system can also be like, you know what, actually, maybe I need to go talk to Guy and be like, hey, Guy, can you review this thing that the agent wants to do before it goes and does it?
And so much of if what we're trying to do is to basically turn software into the Waymo experience, so much of it is like, how do we, as the models improve, how do we over time give them more autonomy, but with the same substrate system?
Because there's going to be certain tasks.
that you assign an agent, that you're going to say, you know what?
It's totally summarization where I'm pulling in a bunch of context.
I'm summarizing a document for you.
You should have, it's okay.
Read access to everything.
That's totally fine.
But the minute you want to go and do a high, maybe a transaction, a cost of over $500, definitely that's when a human has to say, you know what?
I don't trust agents to make decisions on my behalf over $500.
Or an organization may say, I don't trust agents to have access to customer data at all.
Like there are different trust equations.
And every person, organization depending upon the context of what the agent is who's using it what things it's re asking will have a different equate trust equation about what they think is okay for them yeah yeah interesting so really what you want is you want the the identity I really like this identity plus authorization bundle to be task-based.
I'm performing a task, this task should have a set of permissions.
So I think within that world, it feels there are two, simplifying a little bit, two ways in which agents run.
One is an agent as in an agentic workflow.
And so I'm running it, and so I can choose.
Sometimes it's doing broad things, sometimes it's doing narrow things.
But I think within that world, it feels quite manageable to say, I'm giving it authorization.
We'll come back a little bit to how do I define which permissions it should have.
That is sort of a hard problem.
But at least I know this bundle, this process here that is executing, it's kind of executing the same thing or this assigned action again and again.
And then I've got my Cloud Code or Codex or Gemini that I'm sort of running locally.
And I don't know, probably in my reality or Cloud that I'm running on my desktop, It doesn't do one thing.
I do one thing and then I come back and say, hey, I've got these other ones.
And I oftentimes just sort of run it in one long session that I walk around.
And if I just approve of things, like, okay, I just performed an action and said, can I delete this file and delete this file?
And then it's like, fine, okay, delete all.
Yes, always approve.
And then I come along and do something else and that goes away.
Is that a lost cause?
It's like, hey, guy, just stop using the agent like that.
Use it in a more methodical fashion and delete that?
Or is there a better model for how to handle?
There's definitely a better model.
What we want to get to is a world where agents, you can assign agent a task.
A task may be something, hey, do, like, survey the internet and every day come back to me or survey all of my assets, all of my inbox and come back to me and tell me.
what happened, right?
And that's a long-lived process where you definitely don't want to every morning wake up and have to click a consent screen, right?
You actually just like, I've assigned you, I've delegated authority to you to perform things on my behalf and work.
In order for me to delegate to this agent, and that agent actually, and this is where identity comes in, we have to be able to identify the agent, right?
So it's like, I've given FUBAR agent.
for this task, this authority.
And when I signed a different task, I wanted to give it different authority.
But that's the first basis.
It's like, this is why we talk about identity is, okay, well, in order to give something your authority, to do something on your behalf, you both have to be able to identify that thing.
And then the thing that the downstream systems that are saying, hey, is this random request that's coming into my system, does it have the permissions?
Like, has it been given the authority to do the thing it's asking to do?
Well, I have to both know, oh, Guy did in fact give FUBAR access to do this thing, but I have to actually be able to identify both FUBAR and Guy.
And certainly those systems want to treat an access request or a request based from Guy differently than they do from FUBAR.
Because when you think, I love to give the example of like credit card chargebacks here.
Because if you ask your agent to perform a transaction on your behalf, and then you say, hold up a second, I didn't give it.
access to do that.
How does the intermediary be like, well, actually, no, we have a record, in fact, that you did tell FUBAR to go and do this thing, and then you said it could spend up to $500, and it did do that thing.
So we're actually not going to process that chargeback, because you did do it.
With today's identity systems, with what we built in the last generation, you can't differentiate between, well, did Guy give FUBAR that access for this specific task, or a different task, or...
Where's Hubar in the mix?
None of that existed because they actually didn't have to build that for last generation security posture.
Now we do.
Yeah.
So I guess kind of echoing back a little bit, we'll get a little bit to solutions.
I'm hearing three levels here.
One is...
separate kind of me from my agent.
So use identities that are specific for that agent.
Two is have a set of authorization that is aligned to the task that you've just given the agent.
And I guess three, which relates a little bit to the two, is if you're within, like the second one is easy when you've defined the task up front and it's not a long-lived agent.
But when it's a long-lived agent, am I right in understanding that you're saying there's another kind of bucket of like ephemeral entity, the sort of entity that comes along, which is what is the current task being done?
Exactly.
That is like kind of like gathered out of the moment in time, the last few messages, whatever it is, you know, the last message that the user has provided, whatever it is.
And I guess that type of activity.
You know, it really isn't a place in which the human will engage.
So that probably needs to itself be more kind of inferred or decided.
Is that right?
That's right, yeah.
The first one and the second one are a scale problem of a thing that we had before.
We had a system.
We gave the system a task.
We had to give it an entity.
We had to give it a permission set.
But this third one, that's a new creature.
Totally.
And if you were to go read...
current literature, you'll find that what you and I are talking about, like I think task is very understandable for us to think about.
It's like, oh yeah, I assigned this thing a job or a task to go do and I went and did it on behalf and maybe that task repeats every 30 days or it takes a long time to do that task.
In literature, it's called a mission.
It's like often in standards that are starting to emerge, it's started as a concept of a mission.
And a mission is over time as users or other people give assigned work for these things to do.
You're going to think about here are the missions or the quests I have assigned to this thing.
And I, as a user, will update what that mission is as we learn things.
And really what that mission is is about describing the user's intent as a concrete thing.
It's like I intend for this agent to be able to complete this type of task.
And that allows another system, like an authorization system, to understand, hey, this user or this company, right?
Somebody has assigned a mission to this agent.
That mission is something I can measure their access requests against and say, is this aligned with human intent?
So that gives us a way to like think about how the concept of an agent's identity and the tasks they're working on travels across systems, right?
Which is the issue that doesn't exist at all today is if you go to ABOS and you ask your agent to talk to ABOS on your behalf, ABOS has actually no way to know whether what action that the agent is performing was aligned with what your initial request was at all.
And so part of this is like we have this new concept in delegation is this what is it that this thing has been assigned to do so that I can then judge whether the thing it's asking to do is aligned with the thing it was assigned to do.
So we have human identities, we have non-human identities, and is there now a mission identity?
There is.
And typically, you can think of these concepts of inside identity, there's been this concept of session for a long time, right?
It's like I log into a website that creates a session, often from, you know, 1990 to 2000 era web, it's a cookie in your browser, and that represents some session, and that session helps identify who you are.
And now it's not just a session isn't just...
who you are, it's who are you acting on behalf of, and it is also for what purpose.
And that's the three layers that we now have to think about.
And for that purpose gives you access to do what things.
And those are the layers of complexity.
And if you think of it from that perspective, that's how the layer of the complexity of identity systems that agents force for us to be able to solve a lot of these safety concerns across the system.
Yeah.
Okay, cool.
I love the search and analogy because It's something you can kind of relate to on it.
And sessions are interesting because sessions are things that they might get invalidated and require a new one for a variety of triggers.
Most common time, you know, like it's been idle for a while or maybe just, you know, sort of sitting there.
Sometimes it's an action that has been performed that kind of requires a re-authentication and a variety of those.
So maybe let's sort of go into, indeed, a little bit of the solution landscape on it.
So what are the types of sort of tools or new capabilities that are out there?
Kikart is kind of one of those on it.
But give us a little bit of the families of ways to tackle this sort of new challenge.
Yeah, I think there are many different sort of solutions on market that kind of message to this type of thing.
But I think let's step back and think about what are the new technologies or protocols that are emerging to start solving this.
And then we can kind of discuss about like different ways.
So I think there's really...
If I'm sitting in the chair as a security person, I'm thinking about two things.
One I'm thinking is about how do I find my shadow agents or my shadow idea?
It's always a conversation.
Security is what are the things that are happening that I don't know about, right?
So I can quantify.
Security and agents are obsessed with shadows.
Shadows.
It's like, yeah, can I see a shadow?
Is a user doing something I didn't intend or is a system misconfigured or whatever, right?
This is governance and there's a lot of money made in governance and security, which is quantifying effectively risk.
And then there's the golden path.
And in all security solutions, in all dynamics, you always have, hey, here is how we're going to find all the risk.
Well, once you've identified risk, because a lot of the risk is not people doing the wrong thing.
They don't have the wrong attention.
They just don't know how to do the right thing that is the secure pathway.
And then you have your solutions that are one of the secure pathways.
And so you always, in most markets and in most problem spaces, you have, let's go find and quantify all the risk.
And then you have.
okay, here's the place we go.
And now over time, as markets consolidate, they often tend to be the same thing.
Move them from the shadow to the road.
Exactly.
And the road is typically the infrastructure part, right?
And we saw that with the rise of social on the web, with the rise of OAuth, things like Auth0 come along and made it really easy for developers to build social login on their website, user management, which turned out to be a really hard problem.
And so a lot of people, that's why that market exists.
And then, of course, we had for internal workflow, we had things like Okta that rose, and it made it really easy.
have a golden pathway for me to log into stuff.
And then you, of course, had all your governance function out of the kms.
These are all kind of examples of places where you would sort of centrally define your sort of identity, your authentication, like your system, but then you'd be able to kind of plug that in to many places.
And even with the rise of cloud, we had things like HashiCorp Vault and Terraform that allowed me to configure IAM systems or put a place for me to store long-lived secrets.
And so much of the last era was about where do I, where's the golden path?
Now, with the change to, with the rise of agents, agents basically break a lot of assumptions of how all those things work together because they kind of work across different systems.
They can work on behalf of your customers.
They can work on behalf of yourself.
They can just be pieces of code that are running in your stack, you know, maintaining your software factory, deploying, debugging things.
You have all these different interactions that are no longer human-driven, but they do exist.
And how do you manage that?
But the fundamental issue is what are the new technologies or techniques that are coming out to help do the session mission per task thing?
And so in OAuth, you have some movement there that's trying to take over OAuth.
Some of the stuff that actually just came out was called cross-app access.
It solves some of the problem with cohesion, but it doesn't solve all things.
So that's IDJAG for those who are watching.
And then on...
There's a net new protocol called Agent Auth written by Descartes, who is a net new approach on a protocol to try and solve these mission, session, orientation, and loop, loop, loop, loop, loop, secrets.
So those are some of the protocols that are emerging.
And then the different approaches today are how do I find and quantify what risk I have, whether it's on my endpoint, my production stack, or my cloud accounts.
And then you sort of have your goal path.
things of how do I actually enable my developers or my customers or my employees to be able to find, build and use agents successfully in sort of the golden path.
Okay, so let me kind of echo back a little bit of that.
So like the OAuth, so you have the sort of broader challenges.
One of the projects around OAuth, it's about sort of allowing agents, identifying as agents, not sort of masquerading as humans to use OAuth.
Today, I guess we would have all seen, hey, it ran the login, it sort of opened up your browser, you're kind of clicking a thing on it.
This is you authenticating as a human and then giving that key now to the agent.
Instead, can we sort of create a protocol?
that allows the agents to sort of authenticate as it, as an agent, and sort of have the appropriate.
Okay, so that makes sense.
And that's like a bit more of a sort of like a technical path with some of the correct identity, but it doesn't solve the mission sort of identity problem that we talked about before.
I guess the sort of the second bucket is more around that sort of mission identity.
Exactly.
And for the mission identity, like where is the point in time in which...
and who is involved in saying, fine, there's a mission, you've done it, but what are the permissions that are allowed over here?
It seems untenable that that would be a human that will come along every time and say, okay, fine, I figured out that what you're trying to do is compose an email, you'll have these permissions versus you're optimizing a database, so maybe you are allowed to modify an index.
Exactly.
I think there's two parts to this.
One is everybody...
individuals and companies, more companies and individuals are going to have things that you say, you know, no agent can do this without me being involved, right?
For me personally, it's probably spending over a certain amount of money or deleting data.
Those are like, if you're deleting, I want to make that decision because I care.
Or if you're sending an email, I actually do care deeply.
And those are easy because those are not mission decisions.
Those are like wide decisions.
Yeah, they're just ground rules.
Now, when it comes to mission decisions, this is really where patterns like Elm as a judge start to emerge because you're using a reasoning engine to reason about whether something's reasonable.
And then...
ostensibly you basically based on does the system think this is reasonable?
Okay, if it's not reasonable now who decides what we do as a result?
Is that no, absolutely not because it's hit some deterministic guide rule.
We say no, we'd never let delete.
Oh, it's trying to do X, right?
Should this go to the security team?
The security team then has like a system that reviews it or should actually go back to the person that's operating on behalf of and says, hey, this agent tried to do this thing.
Is this aligned with what you were trying to get done, right?
And the biggest challenge we have today when it comes to agentic security is how do we actually not end up with consent fatigue, right?
Like the worst part about the yes, no, allow, always ducked dialogue is you just click yes because I'm not going to read it, right?
And that's always been one of the biggest challenges in security is how do I have a security system that only sounds the alarm when appropriate?
When it's relevant.
Exactly.
Otherwise, you lose all the signal.
So the mission...
mission componentry, one part of it is getting all the protocols and the functionality in place so that you can sort of federate out what is it that this person said this thing's actually supposed to be doing.
And then the second component is the system around that that can actually make judgment calls.
And the better the system around it is at making judgment calls, the more like the less interrupts the users will have, right?
And the lower risk profile decision we made.
And that's more trust and a pathway to higher autonomy.
Yeah, yeah.
Makes sense.
Okay, so you have to do that.
So, again, agents all the way down, you know, something into it.
So you need, though, the infrastructure.
We have these two open protocols that, I guess, are forming, right?
Like standards take a moment.
Yes.
And then you have, I guess, kind of this sort of new concept, which is you have these missions.
You have to give them an identity.
which is already like a little bit hard to sort of identify where that is.
But then also you need to figure out what is the authorization to get them?
What are the permissions, which will be a subset of your overall agent identity permissions?
So what are the, let's sort of get down then to the tools themselves that are available, right?
If I am building agents and I'm sold, you know, like this is a problem, this is a concern.
I have this.
What are the tools available to me?
Yeah, you know, today, there's this big battle in the ecosystem that I'm sure Guy has talked to about.
Somewhere there's this battle between CLI versus MCP, right?
And so we kind of have, you know, you have CLI tools, which very much have not, don't have any really auth system built into them.
And then you have MCP, which the nice thing about MCP is it comes with a box with like OAuth support.
So in order to be an MCP, you have to have OAuth support.
And that OAuth support gives a pathway for saying, does this thing actually support some of the concepts that I talked about, right?
There's two broad ecosystems where there's solutions that only work for MCP and then there's some solutions that only work for CLIs.
And the question really is, is that sufficient?
Because what we know is there's a set of agents, computer-reuse agents, specifically coding agents, that CLI tools are their bread and butter.
They're just really good at it.
And that makes them fast.
And it's one of the reasons that like Opus and GPT-5-2, Opus 4.5, GPT-5-2.
really were the breakthrough models on these computer use things and led us to a new level of autonomy.
And then you have sort of MCP only.
And the question is to think about what is the agent, what type of tools is the agent need to have access to?
And what type of agent should I have running my ecosystem to do that?
And how do I integrate that?
If it's an agent that is operating inside my company, I probably want that integrated with my IDP.
And I want it, but...
I want to think with IDP slightly differently for agents and for users because they're actually slightly different problem statements, broadly speaking.
And then the tools on the market tend to be like an agentic IDP solution.
There's some tools in the market that look like an MCP gateway, which is a common topic, very much designed for MCPs.
It's a giant proxy.
And there's other things that are designed specifically for solving this sort of agent to agent.
communication in a federated manner.
And those are the two landscape solutions at the moment.
And then, of course, you have your traditional last generation vendors, like your privileged access management.
That was a very hot topic still.
How do I give a human access to Postgres running in my Amazon or my GCP?
Very big, important problem.
Things like a CyberArk that was bought by Palo is a good example of that.
And those are sort of the buckets.
And then, of course, you have your...
I'm building an agent that someone uses and how does my agent or my MCP or whatever allow users to authenticate so they can carry down identity and access.
And those are the broad buckets of problems.
So everything that you describe right now is very like enterprise solutions for it.
So in the organization, you figure out how do I represent agent identities in my IDP?
How do I sort of systematically control access to my systems by routing?
kind of a blessing, some sort of access grantor somewhere in it and then having it be accessed via CLI or MCP and run along.
So those are very like...
enterprise-wide.
Are the solutions all, like, some of the problems that you've described are things that I might, as an individual or as a team, also say, well, within my sort of processes that I'm running here, I want some sort of mission identity, mission permission, definitions on it.
Are there solutions that are also, like, working within a...
within that resolution?
I mean, certainly that's something we're trying to do with Keycard, trying to empower teams to be able to just quickly and easily pick up agents, but also quickly and easily build their own agents where they're not constrained, whether it's MCP or CLI or a specific scale.
We're trying to build it across.
And so we sort of look at it's actually not MCP and CLI, it's both, but it's also not...
Pam, it's all three combined and how you bring these different identities, these different postures into one system that's really easy to adopt and build with is how we think about the problem and that's where we're coming from.
And, you know, I think the challenge...
Tell us a little bit more about that, which is how would you...
So if you were to use keycard, you know, what does that entail?
You know, if I'm...
Well, I guess you sort of choose right whether that's sort of like if I'm a you know the big boss kind of a CTO kind of in the system or if I'm a developer, but no What does it sort of feel like you know, like what am I doing?
Yeah, absolutely So with the way we've architected our solution is if I'm you know using cloud code and we give access some things I download the key card CLI I run Claude or Cursor or Pi or insert your harness of choice, your keycard.
We agree with the hook system.
Then you basically tell keycard, hey, this agent can access these things.
And it could be a set of MCPs or it could be a set of CLI tools or tool calls on my behalf.
And then we make the, from that point on, no longer do you actually have to, yes, no, allow, always consent dialogue.
Keycard can make those determinations for you.
And then you get to say, you know what, if it's a delete.
I should probably review.
And that thing, whether that thing's running on my local device or if it's running in a sandbox someplace or it's cloud, it works the same way across all.
So one insertion point to allow your agent to evolve into a software factory and have autonomy.
And then if you're on the flip side, I'm trying to build a service, I'm trying to build an agent or a tool that agents can talk to with the latest, greatest protocols.
We don't have any identity expert.
You can use your SDKs, which...
then allow you to build those types of things that your agents can interact with.
In your system.
And so in that context, you are providing a means of some sort of central definition of logic, I guess, or sort of like the decision making.
And then you are connecting that.
Exactly.
The two value propositions are one, hey, here's like a smart engine that can make good decisions around who should approach what and is able to take your input.
And the second is...
uh hey i can handle the proliferation of agents you have many many agents you want the same kind of logic applied uh at various places exactly and then i i'm at and from there connect that up to like some the parent system of you know how does a how does sort of a central platform team convey down some of those decisions into sort of individual developer desktops.
Exactly.
So how does, you know, we really are focused on how do we enable that individual developer to find lots of success, then how do we let them graduate from like that to a team of people going together independent of the harness, right?
Access what resources and what circumstance and over time, how does that give sort of that centralized security team, the platform team, both the enablement function of how do I roll this out across the entire organization, but also how does that security team get the confidence to say, you know what, we can say yes to this high degrees of autonomy because we feel like we have the security in place that we require to do it.
Yeah.
If you're enjoying the podcast and want us to continue to bring you the very best content, please do us a favor and hit that subscribe button.
It really does make a difference and lets us continue to improve the quality of our guests and build an even better product for you.
All right, back to the episode.
And so, cool.
So I love that and I love the sort of the dev taste of sort of a bunch of the sort of the keycard stuff on it.
And it is, you know, like I'm a believer in the bottom up, although it's not necessarily bottom up, but in that sort of developer experience, clearly also the world.
has a lot of sort of a passion for central control systems that come along.
And I guess that's the tension that sort of plays out.
Neither is like right or wrong.
It's just about what is the emphasis at a different time?
How much do you indeed kind of define the guardrails in a broad sense?
But I think a key takeaway, you know, there are many, many, many kind of interesting things in kind of all this description, and thanks for outlining that.
But this notion of these mission identities and...
agentically decided permission set for that.
And then from there, the ability to define those, enforce them, probably observe them, improve them over time, look around them, enforce them.
All of those are probably evolutions of a system over time.
But that core new mission identity and permissions are sort of a new entity.
Exactly.
That's the final thing that we're focused on.
a key card is how do you understand what agents are doing?
How do you allow agents to do things without having to artisanally define all this strict long-lived policy?
And that's why you get there by being able to describe high level.
Like, you know what?
These are the situations where I'm really not okay with an agent doing something.
For me, it's a lot about deletion.
And in all other circumstances, I'm okay with a system making that judgment call on my behalf, but whether it's allowed.
And that's how we can have this sort of high degree of, how we can move towards higher degrees of autonomy without bad downstream things happening.
And one of the biggest challenges with that, talking to a lot of in the enterprise, we're using individual devs is, this is great.
Conceptually, it's great, but how do I roll this out?
And that's where high-level policy...
combined with the LM as a judge feature helps people see, oh, okay, so I'm not sitting there artisanally defining hundreds and hundreds and hundreds of lines of window policy files, which was what we learned, I think, a lot of security tools in the last generation is that that's where deployment went and failed.
Yeah, yeah, yeah, because it's not like...
When it came to humans, we were good at the authorization.
This was like a bad problem.
And I think the reality of many aspects of technology is that problems that were a nuisance, but we can kind of get by with in the pre-agent era, but they were not great.
The best teams handled them.
Those are now intolerable in the agent era.
I often say to people that the best practices of cloud are now base requirements for agents and we certainly see those sandboxes and cloud environments and everything and that's still true.
We're good before but the same was true for like waterfall to cloud.
It's true as well.
Yes.
So I guess kind of before we close off here, I'll ask you to do one foolish thing, which is predict the future.
I love it.
I love to predict the future.
I do this all the time.
Yeah.
So, I mean, one aspect of it is with all this identity and evolutions of it, you know, what is the transition period to it and what is immediately carrying all that.
But if we leapfrog all of that and we say like three years from now, it feels like a lifetime away kind of in AI timelines.
What do you think will be the sort of the state of...
of the ecosystem when it comes to how do we define these identities?
Yeah, I think there's a couple things.
One is, first and foremost, new protocols will actually have been deployed, right?
And so right now, we're really sitting on last generations, like OAuth, like implementations, and it turns out most of them were not very good.
And we're seeing a lot of that when, you know, you go use an MCP from some of your favorite providers, you're like, well, why does this not work the way that I actually thought it would work?
Why does this require all this?
I think...
I think the future of the internet and such, agents will make everything feel pluggable and interoperability will be incredibly important.
And you'll see lots of companies really want to, because they want to have an agent-forward experience, they'll really make interoperability across agent clients like a high story, which means that most people will be focused on actually building up net new auth components to support this.
And that will then, from an engine perspective, make actually pulling a bunch of tools together so much easier and so much better.
I think that on the flip side, what we'll see is specifically in the enterprise, we're going to see people move where there used to be a lot of silos and those silos are driven by how hard it was to write policy to less silos and higher degrees of productivity and higher degrees of context sharing.
Both because there's huge promise, but also because the identity and access systems will upgrade to the point where it allows that interoperability in the enterprise will allow these things to communicate to each other while the security team will have the things that they need to say.
to keep the company secure, which has often been part of the reason that those systems didn't connect, is they didn't have a good way to actually manage information sharing.
Yeah, this is like a very optimistic view of the future.
I was like, you know, the protocols will be like, it's not a given that standards will be defined in three years, and that sort of the system will do it.
So that is definitely sort of the aspiration, which is these systems will evolve.
And I guess kind of the driver is the belief that it's just like agents are making a sufficiently forcing function that we have no option but to solve it.
Exactly.
And that's certainly been the history of Identity and Access for the last 30 years.
It's not the consumer that has really forced the evolution.
It's excluding online shopping with TLS.
It really has been the enterprise that has driven the requirement because what they want is a productivity gain.
So they have the security requirements.
And they go out and say to all their buyers, you really need, you have to implement this.
Like for me to keep spending my $25 million with you.
And of course the vendors say, well, we're not turning that money away.
We really need that revenue.
So we're going to go implement it.
And also because all of our enterprise folks are asking for it.
And I think what's unique about this era of agents specifically is we're seeing agents at work.
be adopted much faster with much higher degrees of ROI than agents at home.
And that's an inversion of some things we've seen previously, but it's certainly true now.
And so I think as a result of that, that will force the security stack, the next generation security stack to evolve much faster than I would have typically suggested.
I think that's a good, I think I relate to that.
Maybe it's a little bit optimistic on it, but I think nothing is better.
It's a strong forcing function to do that.
It is definitely well fueled from a VC domain of it in terms of funding the transition, probably because of this sort of urgency.
Exactly.
Yeah.
Ian, thanks a lot for coming in, demystifying, helping us understand identity on it.
Looking forward to seeing a key card and in general, this world mature for it.
So thanks a lot for coming in.
Thanks for having me.
me.
And if you're interested in Keycard, you can find us at keycard.ai and we'd be happy to show you a demo and help you see how you can adopt coding agents and build your own agents at scale.
Very cool.
And thanks everybody for tuning in and I hope you join us for the next one.
The AI Native Dev is brought to you by TESL, the package manager for skills and context.
Your hosts are Guy Pajani and me, Simon Maple.
Our producer is Tom Dowler.
The AI Native Dev is not just a podcast, it's a community and we host monthly meetups at the TESL offices in central London.
Visit tesl.io forward slash community to learn more and I hope to see you there.