For AI Agents, Identity Is the Hub. Everything Else Is a Spoke

A law firm recently sent us an AI security evaluation worksheet. Nineteen weighted domains, carefully scored, framework-mapped, clearly the product of real work. Prompt and output DLP carried 8% of the total. Behavioral monitoring, 7%. Agent workflow governance, 7%. Knowing which AI agents exist in the environment carried 6%.

They weighted what an agent says more heavily than whether it exists at all.

I see a lot of these. The demos, the written responses, and the follow-up calls with the engineers who will actually run whatever gets bought. That worksheet is not an outlier, but the pattern.

The contradiction sits inside the same file. Page one instructs evaluators to complete the visibility coverage sheet before scoring anything else. The instinct was right, but the math overruled it.

A credit union took a sharper approach. Its RFI told vendors that strong answers would explain how their platform correlates data, identity, and action, linking a specific identity to a specific action on specific data rather than treating the three in isolation. That is the right question, and most evaluations never get near it.

What the RFI leaves open is who owns the answer. It covers three categories of tools, which is reasonable, because governing what an employee pastes into a chatbot is a different discipline than governing what an autonomous agent does with a service account. But correlation is not something three vendors each deliver a third of. Somebody has to own the spine. Identity is the only layer present in all three: every piece of data touched and every action taken has an identity attached to it.

Both of these are sophisticated buyers doing careful work. Both are buying controls for a population nobody has counted, to govern access nobody has mapped.

The misdiagnosis

The prevailing belief is that AI agents can be secured by watching what goes in and what comes out. Filter the prompt, inspect the response, flag the anomaly, and contain the risk. That belief is comfortable because it maps onto tools security teams already own. It also arrives a step too late.

Think about how you onboard a new employee. Nobody secures a new hire by monitoring their conversations. You decide what the job requires, grant that access and nothing more, review it when the role changes, and revoke it the day they leave. Thirty years of settled practice for people, and we are skipping all of it for software that acts on its own.

By the time an agent processes a prompt, every consequential decision has already been made. Someone created it. Someone handed it credentials. Someone wired it into a repository, a CRM, or a production database. The prompt decides what an agent tries, but access decides what it can do.

The data is not subtle. IBM's 2025 Cost of a Data Breach report found that 13% of organizations suffered a breach of an AI model or application, and 97% of those organizations lacked proper AI access controls. OWASP moved Excessive Agency up its 2025 Top 10 for LLM applications and split it into three root causes: too much functionality, too many permissions, and too much autonomy. Every one of those is an identity problem wearing a different label.

We already ran this experiment

Fifteen years ago, the industry faced the same question about the cloud and took the long way to the answer.

The first wave was configuration scanning. Find the open S3 bucket and close the misconfigured security group. The second wave was workload protection. Both were necessary, but neither was enough, because attackers kept walking in through legitimate credentials with illegitimate reach. Gartner finally named the missing layer in 2020, coining Cloud Infrastructure Entitlement Management for a category built around one question: who can access what, and do they ever use it?

Capital One is the cleanest illustration. In 2019, an attacker exploited a server-side request forgery flaw in a misconfigured web application firewall. That is a configuration failure, and configuration scanning is designed to catch it. What turned it into 106 million exposed records was the IAM role attached to the compromised instance, which carried permissions far beyond anything the application needed. The exploit was worth one EC2 instance. The entitlement was worth 106 million records.

Different technology this time, but the same sequence, with far less runway to correct it.

Blast radius is a function of access

Prompt-layer defenses are worth building, but they are not worth building first, and they cannot carry the weight alone.

In December 2025, the UK's National Cyber Security Centre published an assessment concluding that prompt injection may never be fully mitigated the way SQL injection was, because language models are inherently confusable deputies operating on probability rather than deterministic syntax. OpenAI's public position is that prompt injection is a form of social engineering unlikely to ever be fully solved. When the organizations building these models tell you filtering will not reach zero, filtering cannot be the plan.

Fire codes work the same way. Sprinklers are needed, and every building has them. But the first thing the code does is limit how much combustible material you can store in one room, because the honest assumption is that something will eventually ignite. Security has a version of this. We stopped designing around "keep the credential safe" and started designing around "assume leak," because leaks were inevitable and blast radius was the only variable we could control. Agents need the same move. Assume injection. Prompt defenses are the sprinklers, but access control is the fuel limit.

We uncover things like this all the time: a coding agent on a Windows endpoint, running with every permission check bypassed, surfaced through endpoint telemetry. It is not in an inventory. It went through no approval process, and on paper, nobody owns it. And it can write files, run shell commands, and invoke tools without asking anyone first.

Finding it is the easy part. What comes back with it is the point: the engineer it belongs to, the credentials it holds, and every system those credentials open. One injected instruction or one poisoned dependency, and that list stops describing what the agent can reach and starts describing what an attacker just inherited.

And no prompt filter would have caught it, because prompt filters only inspect the agents you already know about.

Identity is the hub

One of our customers framed this better than our marketing team has: treat it like hub-and-spoke. Identity is the hub. DLP, prompt defense, data classification, and red teaming are spokes.

The point isn't that the spokes are optional. It's that they cannot turn without the hub. A DLP policy for AI agents needs to know which agents exist and what data they can reach. A prompt defense that fires needs an accountable owner on the other end of the alert. Data classification can tell you which stores hold sensitive material and still not tell you which agents are quietly authorized to read them.

To be clear: least privilege caps how much damage an agent can do. It will not stop an agent from misusing access it legitimately holds, and for data an agent is supposed to touch, you still need content controls. If your immediate exposure is employees pasting client data into consumer chatbots, that is a different threat model with a different first move, and you should make it.

Identity governance contains damage rather than preventing it. Prompt injection will eventually succeed, and very little in a standard security stack is built to notice when it does. What decides how bad that day gets is narrower than most teams expect: what credentials the agent holds, what those credentials reach, and how fast you can cut them off. Answer those three in advance and a compromised agent is an incident you can scope. Leave them unanswered and a single injected instruction has a clear run at everything that the agent touches.

But when the risk is autonomous software holding credentials and acting on your systems, discovery, ownership, and access come first. Everything after that is enforcement with something to enforce against.

Start with five questions

You don't need a strategy document to begin. You need answers to five questions, and you need them continuously rather than once a quarter.

1. What agents and non-human identities exist in our environment?
2. Who owns them?
3. What can each of them reach?
4. What is each one actually supposed to do? 
5. And when one steps outside that, can we do anything about it?

The first three are discovery-focused. The last two are where governance starts, because intent is what turns an inventory into a policy. An agent built to summarize support tickets and an agent built to push code have different legitimate footprints. You don't establish that by asking someone to declare it. You establish it from what the agent already shows you: the permissions it holds, the tools it calls, the data it reads, and the instructions it runs on. Once intent is established, enforcement stops being philosophical and becomes an access decision you can actually make.

Ask your own team the first question this week. Not what they think the number is. What they can show you. If nobody can produce that list by Friday, the other four are guesswork. 

An agent you have never inventoried is an identity that is over-permissioned. You just haven't met it yet.

‍