Every developer running a coding agent has hit the same wall. The agent asks permission, you click "always allow," and from that point nobody really knows what it is authorized to do. MCP servers made it dramatically easier to plug tools into agents, and they brought OAuth along for the ride, but the authorization model underneath was designed for a world where a human sat behind every request. That gap is where the next generation of agent security is being built.

Ian Livingstone is co-founder and CEO of Keycard, which is building identity and access infrastructure for AI agents. He joined Guy Podjarny on the AI Native Dev podcast to explain why identity, a topic he cheerfully describes as a snoozefest for most of the last decade, has become the foundational question for anyone who wants agents to operate with real autonomy.

The feature and the bug are the same thing

Livingstone's framing of the core problem is unusually clean. Agents are built on a probabilistic distribution, and the thing that makes them useful is precisely the thing that makes them dangerous. "The feature is that it can reason and it can guess over large amounts of data, and that it is non-deterministic. That's the feature. The bug from a security perspective is that it's non-deterministic, and that is still the feature. So the feature and the bug are the same," he explained.

That symmetry rules out a whole class of solutions. You cannot make an agent deterministic without destroying the reason you deployed it. What you can do is put hard boundaries around the space it operates in. Livingstone drew a useful line between two kinds of control: non-deterministic controls, which bias a model away from bad outcomes, and deterministic ones, which make certain outcomes structurally impossible. Safety work lives in the first category. Identity and access live in the second. This is a large part of why sandboxing has become so popular so quickly, he noted: a business needs to be able to say the worst case has been removed from the equation, not merely made less likely.

What agent identity actually means

Agent identity is the practice of establishing which agent is making a request, who that agent is acting on behalf of, and what it has been authorized to do for the specific task at hand. It differs from traditional identity because permissions are scoped to a job rather than granted permanently to an account, and because the requesting party is non-deterministic rather than a trusted human.

That last clause carries most of the weight. Livingstone pointed out that the cloud era largely got away with solving authentication and treating authorization as an afterthought, because identifying a person was usually enough. "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." The human on the other end has a reputation to protect, a job to lose, and continuity from one task to the next.

The background check you cannot run on an agent

None of that transfers. An agent, as Livingstone put it, is a brand new creature every time, with different context. It is not malicious, but it also has no way to know whether what it is about to do is reasonable, and no authoritative sense of its own uncertainty. Broad standing access, which was a defensible shortcut for employees, becomes an open liability.

His favorite illustration is a credit card chargeback. You ask an agent to make a purchase, then dispute it later, claiming you never authorized that. With today's identity systems, the intermediary has no record that distinguishes what you delegated from what the agent decided. "You can't differentiate between what did Guy give Foobar that access for, this specific task or a different task, or where's Foobar in the mix? None of that existed, because we actually didn't have to build that for last generation security posture."

Practically, this suggests developers should stop thinking about agent credentials as long-lived secrets attached to a service account, and start thinking about them as scoped grants attached to a piece of work.

Mission identity and AI agent context management

The most interesting idea in the conversation is a third layer of identity that Livingstone says is emerging in the standards work: the mission. Sessions have existed since the earliest days of the web, but a session used to answer one question, which was who you are. A mission-scoped session has to answer three: who is acting, who they are acting on behalf of, and for what purpose. That third dimension is what lets a downstream system judge whether an incoming request is aligned with human intent, rather than merely permitted.

This connects directly to AI agent context management. What the agent has seen and what it has been asked to do become inputs to the access decision, not just to the model. Livingstone is candid that humans cannot weigh in on every one of these calls, which is where LLM as a judge patterns come in, backed by a small set of hard rules a person genuinely cares about. For him personally, that set is mostly deletion and spending.

The failure mode to design against is consent fatigue. "The worst part about the yes, no, allow always dialog is you just click yes, because I'm not going to read it," he observed. A security system that interrupts constantly trains people to stop reading, and then the signal is gone. Better judgment upstream means fewer interrupts, which in turn buys more autonomy.

MCP servers, CLIs, and the golden path

On tooling, Livingstone described a live split in the ecosystem. Model context protocol tools ship with OAuth support by design, which gives them a foothold for these newer concepts. CLI tools have essentially no auth story, and yet CLIs are exactly what coding agents are best at, which is part of why recent frontier models produced such a jump in autonomy. Solutions that cover only one side leave a real hole, and the emerging protocol work, including Okta's Cross App Access and Dick Hardt's Agent Auth, aims at the same target from different angles.

Looking three years out, he expects new protocols to be genuinely deployed, driven by enterprise buyers rather than consumers, and notes an inversion worth sitting with: agents at work are being adopted faster, with higher returns, than agents at home. That pressure seems likely to pull the security stack forward faster than usual. As he put it, the best practices of cloud are now the base requirements for agents.

Worth a listen if you are trying to work out how much rope to give your agents, and what has to be true before you can give them more.