The Identity Layer Nobody Built

We have spent two years and a staggering amount of money teaching models not to get fooled. I want to argue that this was mostly the wrong fight.

Here is what finally convinced me. I was reviewing an agent deployment where the credential handling looked, on paper, airtight. The secrets lived in a proper vault, encrypted at rest, encrypted on the wire, never written to the agent's own state. And it did not matter. The agent had a general-purpose tool with wide reach, and the moment a credential had to be used it was resolved into plaintext in a process that tool could read. A single injected instruction, hidden in a document the agent ingested, was enough to turn that reach into an exfiltration path. The vault did everything right. It just could not help once the secret had to go to work.

In my experience building AI systems at scale, the failures that actually hurt you are almost never the ones you were staring at. We were all staring at the prompt. The damage was happening one layer down, at the question of what a fooled agent is actually allowed to touch.

So let me make the case plainly. Prompt injection is the number one risk in AI security, it is going to stay number one, and no filter you buy will ever change that. The useful question is not how to stop the model from being fooled. It is how little an attacker gets when it inevitably is. That is an identity and authorization problem, and it is the layer almost nobody has actually built.

The Model Will Be Fooled

Start with the uncomfortable fact that anchors everything else. When OWASP published the 2026 edition of its Top 10 for LLM Applications in August, prompt injection was still sitting at number one, the slot it has held in every edition the project has ever produced OWASP LLM Top 10 2026. The 2026 scope was widened specifically to account for agents, adding language about cross-modal attacks, persistent memory, and what OWASP calls agentic blast radius OWASP LLM Top 10 2026. In the same cycle, Excessive Agency, which is just a precise way of saying an agent can take consequential actions, jumped from sixth to third OWASP LLM Top 10 2026.

Why does injection never get dethroned? Because there is no architectural fix at the layer everyone is defending. A language model cannot reliably separate instructions from data. Every piece of text it reads, a document, an email, a web page, a tool description, is a potential instruction, and the model has no robust way to decide which text it should obey and which it should merely process OWASP Top 10 Risks For Agentic Applications. Filtering raises the odds you catch a given malicious string. It does not change the fact that the model will eventually be fooled.

There is a strange statistical tell buried in the OWASP data that I keep coming back to. The 2026 list was rebuilt on an evidence base of 7,714 real incidents, and prompt injection held the top spot despite a comparatively thin public incident record OWASP Top 10 for LLM 2026. OWASP has a name for why. They call it the defense effect. Organizations spend so heavily blocking injection that successful blocks are never written up as incidents, so the public record undercounts the real base rate OWASP 2026 LLM Top 10. The attacks you see in the news are the failures. The spend is enormous and the risk is still there, just quieter.

A Vault Cannot Protect a Secret in Use

Let me sit with the mechanism that I think the whole industry keeps glossing over, because it is where the real exposure lives.

Credential vaults are good, genuinely good, at two of the three states a secret can be in. They protect a secret at rest, encrypted in storage, and they protect it in transit, encrypted on the wire. Most agent platforms now ship exactly this, and store the credential by reference so the raw secret never sits in the agent's own state. On paper that is serious security engineering. The problem is the third state, and it is the one that matters most for an agent.

A credential has to become plaintext to be used. There is no way around it. The moment an agent actually calls a downstream service, the secret is resolved into a usable, readable form inside a running process. In-use protection is a separate problem, and the vault does not solve it. If any tool the agent can invoke, a shell, a file reader, a code interpreter, can see that process memory, the vault was never really in the fight. It protected the secret right up until the instant the secret had to work.

Now layer the injection problem on top. The agent cannot reliably tell a legitimate instruction from a malicious one, so you have to assume an attacker can, sooner or later, get the agent to run a command of their choosing. If that command runs with broad reach, a general-purpose shell, a tool with wide filesystem or network access, then the attacker inherits whatever that tool can touch, including a freshly resolved credential sitting in plaintext. The determining factor is not whether the injection slipped past a filter. It is what the compromised tool was allowed to reach.

This is the sentence I wish every team building agents would tape to their monitor. The attacker's blast radius is bounded by the tool's reach, not by the model's judgment. Read that again. Not the model's judgment. The tool's reach. And the credential most worth stealing is rarely the end user's own session token. It is the long-lived service account the agent uses to talk to its backends, authority the person invoking the agent never personally had. A single over-scoped service credential, resolved into memory and readable by an over-powered tool, is the whole ballgame.

The uncomfortable confirmation is that the frameworks are not closing this gap on their own. An audit of three widely used agent frameworks checked them against a set of basic containment principles and found no native compliance in any of them, with memory integrity, the property that would stop a tool from reading another component's secrets, absent across all three. The containment layer is not merely weak. In the default building blocks most teams reach for, it is simply not there.

This Is Already Happening in the Wild

If that sounds like a lab exercise, here is the one that should bother you more, because it was real traffic.

In July 2026, Zscaler's ThreatLabz documented two live campaigns using indirect prompt injection against AI agents, one a payment scam and one a typosquatting operation impersonating a crypto platform Indirect Prompt Injection in Web Content. The first dressed itself up as documentation for a Python library and told any coding agent that landed on it that it needed to buy a three dollar API license key to fix an error, then walked the agent through paying an attacker's crypto wallet Indirect Prompt Injection in Web Content. The malicious instructions were hidden off-screen with CSS so a human reviewer saw clean documentation while scrapers and agents saw the payload Indirect Prompt Injection in Web Content.

And it worked. Across 26 models tested, four actually executed the fraudulent payment Indirect Prompt Injection in Web Content. Now, you could read that as good news. Twenty-two models resisted. But look at what separated the ones that caused harm from the ones that did not. It was not better judgment that saved the day. It was that Zscaler had deliberately run the agent with no spending limits to measure the maximum exploitation surface Indirect Prompt Injection in Web Content. A payment cap would have bounded the loss to near nothing no matter which model was driving and no matter whether the injection parsed. That is an authorization control, not a text filter.

I will admit I am not fully convinced the industry has even noticed the pattern yet. We keep reporting these incidents as model failures, as if the fix is a smarter model. The PocketOS case from April 2026 is the one that makes the point without any injection at all. An agent with write access to a production database and no human confirmation step was given a perfectly legitimate task and permanently deleted a production table The OWASP Agentic Top 10, explained. No attacker. No malicious prompt. Just an agent with more reach than it should have had and nothing standing between it and an irreversible action.

The Tool Layer Widens the Hole

The Model Context Protocol has become the standard way agents discover and call external tools, and it is worth understanding because it introduces an attack surface that older threat models simply do not describe MCP attack surface.

The sharpest example is almost funny once you see it. In MCP, a tool advertises itself with a description field, and the agent reads that description to decide how to use the tool. That description is unsanitized text. A malicious server can embed instructions inside what looks like innocent help text, and the agent will follow them with no user ever seeing it happen CSA research note: MCP tool poisoning. The help text is the injection vector. And in September 2026 the official MCP Python SDK disclosed a flaw that let a malicious server trick a client into handing over the OAuth credentials it uses to log into a real service MCP Python SDK Flaw.

There is a genuinely counterintuitive finding here too. When researchers benchmarked tool-poisoning attacks, they found that more capable models were often more susceptible, not less, because the attack exploits exactly the instruction-following ability that makes those models good Tool Poisoning Attack benchmark. Attack success hit 72.8 percent against one capable model. Think about what that means for the roadmap. Making the model smarter can make this particular problem worse. You cannot buy your way out at the model layer.

We Are Defending the Wrong Layer

Put the cases side by side and the pattern is impossible to miss. In every single one, the consequence was set at the identity and authorization layer, not the text layer.

In the credential case, the determining factor was that a broad-reach tool ran in the same memory as a resolved, long-lived service credential. In the Zscaler case, it was that the agent had unconstrained payment authority. In the PocketOS case, it was write access to production with no confirmation gate. Not one of these outcomes turned on whether a filter caught the malicious string. Every one of them turned on what the agent could reach after it was already compromised.

This is the contrarian position I have landed on, and I hold it with some conviction. Prompt-injection filtering is largely theater. I do not mean it is useless. I mean it is pointed at a target that cannot be eliminated, and the money we pour into it is money we are not spending on the thing that actually bounds the damage. The real unsolved problem is containment. Can a compromised agent reach secrets, tokens, and privileged actions at all? That is a question of identity and least privilege, scoping each agent's credentials and tool reach so that a successful injection, which you should treat as inevitable, buys the attacker as little as possible.

Microsoft, to its credit, names the gap directly. Without a first-class identity model, explicit scoping, and enforceable authorization, agents accumulate excessive permissions and end up operating outside their intended boundaries Least privilege for AI agents. That sentence describes the layer the industry has been talking about and has not actually built.

What This Means If You Are Building Agents

If you take one thing from this, let it be a reordering of where your effort goes. Here is how I would approach it.

Treat every agent as a principal with its own scoped identity

An agent should have a first-class identity, not borrow a human's or share an operator's. Microsoft's Entra Agent ID work is built around exactly this, giving agents a dedicated identity type so they can be governed, authenticated, and authorized like any other principal Agent identity concepts. The model deliberately prevents users and admins from consenting to the most powerful permissions on an agent's behalf, so an agent cannot quietly accumulate the authority to escalate Authorization in Entra Agent ID.

Prefer delegated access, and scope the tools before you ship

Where you can, give the agent delegated access so it can never exceed what the invoking user is already allowed to do, and for background automation use app-only access with the smallest possible permission set. The hard-won lesson across platforms is that the right controls often exist but are off by default. Tool scoping is frequently something you opt into at invoke time, easy to miss if you do not know to go looking for it, so the dangerous wide-open configuration is the one most teams get simply by not touching anything. Off by default is the same as absent for most teams.

Put hard authorization gates on irreversible actions

Spending, deletion, and privileged writes should sit behind caps and human confirmation that live outside the model entirely. The Zscaler agents moved real money because nothing but the model stood between the injection and the payment. A spending limit would have made the exact same injection a non-event. Design so that the worst an injected instruction can do is bounded by a control the model cannot talk its way past.

None of this is exotic. It is the least-privilege discipline security engineers have practiced for decades, applied to a new kind of principal. The reason it feels hard is that we got excited about agent capability first and are retrofitting the authorization model second.

The Honest Part: Even the Right Layer Is Unfinished

I want to end with a caveat, because I distrust any security argument that ends too cleanly, and this one does not deserve to.

Containment is the right layer, but it is genuinely unsolved at its edges, and that is precisely why it is the interesting frontier. Vaults protect credentials at rest and in transit but not in use, and any secret the agent actually uses has to become plaintext in a process its tools may be able to read. There is a real tension between flexibility and safety, because a general-purpose tool like a shell is valuable exactly because it can reach anything the runtime can, and scoping it down to prevent exfiltration strips away the flexibility that justified using it in the first place. And an agent endpoint that does not require authentication is a reachable, unauthenticated surface that an attacker can simply find and enumerate. None of these have clean, settled answers yet.

So I am not claiming the identity layer is a solved thing we have all neglected to switch on. I am claiming something a little more pointed. The industry has standardized the vocabulary of agent identity and least privilege, the OWASP categories, the Entra Agent ID concepts, far faster than it has shipped containment that actually holds when an agent is compromised. We have the words. We mostly do not have the walls.

The title of this piece is a small provocation, and I mean it as one. The identity layer is not literally unbuilt. But measured against the confidence with which we are deploying agents into production with real credentials and real reach, it might as well be. We spent two years trying to make the model impossible to fool. The next two should go to making a fooled model harmless. That is the layer that decides whether any of this is safe, and it is the one still waiting to be built.

Key Takeaways