The AI Agent Identity Crisis: Why Your Security Model Is Already Broken
Here's something that keeps me up at night. We've spent decades building identity and access management systems. Least privilege. Zero trust. All that good stuff. And now we're just... handing AI agents the keys to everything?
I'm not exaggerating. A recent scan at one company found 17 AI agents per employee. Seventeen. Most of the security team had no idea they existed.
What are AI agent identities, anyway?
An AI agent identity is the set of credentials (OAuth tokens, API keys, service-account bindings) that an autonomous AI system uses to act on a user's or organisation's behalf. The agent is the runtime that decides what to do; the identity is the principal it does it as. The interesting failure mode is that the identity gets created opportunistically — a developer clicks "Authorize" on an OAuth consent screen, an MCP server is added to Claude Desktop with broad scopes, a Cursor instance is granted repository access — and once created, the identity tends to outlive the use case that justified it.
Let's back up. When someone spins up an AI agent, that agent needs credentials. OAuth tokens. API keys. Repository access. Whatever it takes to actually do work. These are AI agent identities, and they're multiplying fast.
The problem? Nobody's governing them.
"We're letting things happen right now that we would have never let happen with our human employees," says Shahar Tal, CEO of Cyata. "We're letting thousands of interns run around in our production environment, and then we give them the keys to the kingdom."
That's not hyperbole. It's Tuesday.
Why can't traditional IAM and PAM handle this?
Traditional IAM splits principals into two buckets: humans (with roles, lifecycle, business-hour access) and machines (with scripts, scheduled tasks, narrow scopes). AI agents fit neither. They run 24/7 with unpredictable workloads, they chain access across systems in ways nobody anticipated when the scope was granted, and they can be manipulated through prompt injection in ways static service accounts cannot. The policy framework breaks at the categorisation step — you cannot apply a sensible policy to a class you have not modelled.
Your identity management tools were built for humans. Predictable roles. Nine to five access patterns. Maybe some service accounts doing scheduled tasks.
AI agents break all of that.
They run 24/7. They adapt their behaviour on the fly. They chain together access across multiple systems in ways nobody anticipated. Teleport CEO Ev Kontsevoy puts it bluntly: "AI agents are not human, but they also do not behave like service accounts or scripts."
So what are they? Good question. Nobody really knows yet. And that's the problem.
Traditional PAM and IAM assume identity is either human or machine. But agents exist in this weird middle ground. They're autonomous. Non-deterministic. They "want to please," as one CTO put it recently, which means they can be manipulated in ways that static service accounts can't.
How prompt injection breaks the trust model
The structural reason agents need their own identity class is that they are vulnerable to a class of attack — prompt injection — that does not apply to either humans or machine accounts. A human can be phished, but a phish requires an interactive social-engineering step. A service account follows a fixed script, so a malicious input either matches the script (and runs) or doesn't (and fails). An agent processes natural-language input and acts on it; an attacker who embeds instructions in the content the agent reads can hijack the agent's intent without ever compromising its credentials. That's why aggressive scope limitation matters more for agents than for any other identity class.
What do the numbers actually look like?
Gartner says 40% of enterprise apps will integrate with AI agents by the end of 2026. Up from 5% in 2025. That's insane growth.
Meanwhile, machine identities already outnumber human identities 82 to 1. And most organizations can't tell you which of those are AI agents versus regular service accounts.
I've talked to security teams who ran their first discovery scan and just... stared at the screen. Thousands of agent identities they didn't know existed. Some created by well-meaning employees trying to automate their workflows. Some connected to every data source in the company.
One security vendor told me they find "anywhere from one agent per employee to 17 per employee" when they scan customer environments. Engineering and R&D teams adopt fastest, but it's spreading everywhere.
Quick comparison: human vs traditional machine vs AI agent
| Property | Human user | Traditional service account | AI agent |
|---|---|---|---|
| Access pattern | Predictable, business hours | Scheduled or script-driven | 24/7, runtime-decided |
| Reaction to malicious input | Phishing-vulnerable | Fails closed if pattern mismatches | Prompt-injection-vulnerable |
| Credential rotation cadence | Quarterly or per policy | Often static for years | Should be hours/days |
| Discoverability in IAM | Strong (HRIS-driven) | Medium (often manual) | Weak (often shadow) |
| Blast radius if compromised | Bounded by role | Bounded by script scope | Bounded by tool-set + injection creativity |
Shadow AI is the new shadow IT
Remember when employees started using Dropbox and Google Docs before IT approved them? Same thing is happening with AI agents. Except the blast radius is way bigger.
Someone creates a personal ChatGPT account. Connects it to their work email. Maybe adds some MCP servers to access corporate data. Suddenly you've got an unmonitored AI agent with broad access to sensitive information.
"We are seeing a lot of shadow AI," Tal says. "Someone using a personal account for ChatGPT or Cursor or Claude Code or any of these productivity tools."
These shadow agents often get more access than they need. People create them as experiments. "Let me just connect it to everything and see what happens." Then they forget about them. Or move to a different team. Or leave the company entirely.
The agent keeps running. Still has all those tokens. Still connected to your production systems.
Real attacks are already happening
This isn't theoretical. Block found during a red team exercise that their AI coding agent could be tricked into deploying malware on employee laptops. Prompt injection. The agent wanted to be helpful, so when fed malicious instructions disguised as legitimate requests, it complied.
They fixed it. But how many companies are even looking?
Researchers have shown how AI agents with broad access can create "superuser" chains. Access this system, then that one, then another, until you've got a path to whatever you want. Exfiltrate data. Execute code. Whatever.
The agents don't know they're being manipulated. They just follow instructions. That's what they're built to do. The Moltbook breach and the DockerDash meta-context-injection vulnerability are two concrete public demonstrations of how cheap this attack is once an agent has tool access.
What actually works?
The six-step pattern below is the minimum-viable governance programme that the identity-security industry has converged on. None of it is novel security thinking — it is least-privilege, monitoring, and short-lived credentials applied to a new identity class. The hard part is not the controls; it is treating agents as a class in the first place, instead of forcing them into the human or service-account bucket where existing tooling can't see them.
Look, I'm not saying we should ban AI agents. They're genuinely useful. The productivity gains are real. But we need to treat their identities seriously. Here's what I think actually helps:
1. Discovery first. You can't secure what you don't know exists. Run a scan. Find out how many AI agents are actually operating in your environment. The number will probably shock you.
2. Treat agents as a separate identity class. Not human. Not traditional service account. Something new that needs its own policies and monitoring.
3. Apply least privilege aggressively. Just because an agent could access everything doesn't mean it should. Scope credentials to what's actually needed. Review regularly.
4. Monitor for anomalies. Agent behaviour should be somewhat predictable based on its purpose. Big deviations from normal patterns deserve investigation.
5. Expire tokens. Short-lived credentials. Force re-authentication. Don't let agent access persist forever just because someone set it up once.
6. Classify agents by risk. A coding assistant with repo access is different from an AI that can send emails or access financial data. Not all agents need the same level of scrutiny.
The CrowdStrike move
CrowdStrike just announced a $740 million acquisition of SGNL, an identity security company. The stated goal? Getting a grip on AI agent identities specifically.
That's a big bet. And it tells you where the industry thinks this is heading. It's not isolated — see the Palo Alto / CyberArk deal on the PAM side. Both moves point to the same conclusion: identity is the new perimeter for the agentic era.
The companies that figure out AI agent identity management early will have a major advantage. The ones that don't? They're running blind while autonomous systems proliferate across their networks.
My take
Honestly? This feels like 2010 again. Cloud adoption was exploding. Security teams were scrambling to adapt tools built for on-prem environments. There was this gap between what technology enabled and what security could protect.
We're in that gap right now with AI agents.
The difference is the speed. Cloud adoption took years to really hit critical mass. AI agent adoption is happening in months. Security teams don't have the luxury of slowly evolving their practices.
I think the organizations that will do best are the ones treating this as a genuine new category. Not trying to force agents into existing human or machine identity buckets. Building new frameworks from scratch.
It's uncomfortable. There's no established playbook. But waiting for one means letting ungoverned agents run loose in your environment while you figure it out.
That's a risk I wouldn't take.
Working on AI agent security? Connect on LinkedIn or check out my CV.
Key takeaways
- Agents are neither humans nor traditional service accounts — they need their own identity class, lifecycle, and policy.
- Shadow AI is the dominant exposure path: personal ChatGPT/Claude/Cursor accounts connected to corporate data sources via MCP servers.
- Machine identities now outnumber human identities by roughly 82 to 1; most organisations cannot distinguish AI agents from legacy service accounts.
- Discovery first — you cannot govern agents you do not know exist.
- Short-lived credentials and aggressive least-privilege scoping cap the blast radius of any single compromised agent.
FAQ
What is an AI agent identity?
An AI agent identity is the set of credentials (OAuth tokens, API keys, service-account bindings, repository access) that an autonomous AI system uses to act on behalf of a user or organisation. It is distinct from the underlying model — the agent is the runtime that decides which tools to call and what arguments to pass, while the identity is the principal those calls are authenticated as. Modern agentic platforms (Microsoft 365 Copilot, OpenAI Operator, Claude Code, custom MCP servers) all create or consume agent identities.
How many AI agents does a typical enterprise have?
Public reports from identity-security vendors that scan customer environments cite ranges from one agent per employee up to 17 per employee in heavily-adopted engineering and R&D teams. Most organisations cannot answer the question directly because their existing IAM tooling does not distinguish AI agents from other machine identities — those are typically lumped into the same service-account bucket, where machine identities now outnumber human identities by roughly 82 to 1.
Why can't traditional IAM handle agents?
Traditional identity governance assumes principals are either humans (predictable roles, business hours, request-driven workflows) or machine accounts (predictable scripts, scheduled tasks, narrow scopes). AI agents fit neither model — they run 24/7, adapt behaviour at runtime, chain access across systems in non-deterministic ways, and (critically) can be socially engineered through prompt injection in ways static service accounts cannot. The result is that policy frameworks designed for humans or scripts mis-classify and under-protect agents.
What is shadow AI and why is it the biggest exposure?
Shadow AI is unsanctioned use of AI agents inside an organisation — typically an employee creating a personal ChatGPT, Claude, or Cursor account and connecting it to work data through OAuth grants, MCP servers, or browser extensions. Unlike traditional shadow IT, shadow AI carries broader blast radius because a single agent often has read access to email, files, calendars, and code in one place. Identity-security vendors consistently report that shadow agents are over-permissioned and survive long after the employee who created them has moved on.
What is prompt injection and how does it relate to agent identity?
Prompt injection is an attack where malicious instructions are embedded in content the agent reads (a web page, document, email, or tool output) and the agent then executes those instructions as if they came from its legitimate user. Because the agent acts under its identity's credentials, a successful prompt injection inherits all of that identity's privileges — which is why aggressive least-privilege and credential expiry are the load-bearing controls. The attack is well-documented and has already been demonstrated against AI coding agents in red-team exercises.
What is the minimum-viable agent governance programme?
Six steps: (1) Discovery — scan for existing agent identities across SaaS, cloud, and developer tooling. (2) Classification — treat agents as a distinct identity class, not a human or machine sub-type. (3) Least privilege — scope each agent's credentials to its actual function, not the maximum convenient set. (4) Monitoring — anomaly detection on agent behaviour, with alerting on big deviations from the agent's normal pattern. (5) Token expiry — short-lived credentials with forced re-authentication. (6) Risk tiering — agents with high-impact tool access (email send, code deploy, financial transactions) get tighter policy than read-only agents.