Identity Threat Detection for AI Agent Identities

AI agents need to be treated as a new category of identity distinct from the accounts security teams already know how to manage. Agents combine delegation, autonomy, and the ability to spawn sub-agents with their own permissions, a structural combination no existing identity and access management system was built to represent.

A Structurally Different Kind of Identity

A human user acts under continuous human judgment. A person decides to act in that moment, and every click, login, and approval traces back to that decision. A service account sits at the other end of the spectrum: it runs a fixed job, the same API call or batch process, day after day, with no judgment involved at all. An AI agent does neither. It makes decisions in real time, adjusts what it does based on the task in front of it, and often holds authority that reaches further than whoever granted it ever intended.

That gap gets wider once agents start spawning other agents. A single agent can create sub-agents that inherit its permissions or get a narrower slice of them, and each of those sub-agents can do the same thing again. A chain of principals, several layers deep, emerges that no current framework has a coherent way to track or even name.

Compare that to a service account, which behaves predictably enough that a security team can build a baseline around it. An agent can't be pinned down that way. It might need write access to a production database to finish one task, then just read-only access to a CRM system for the next. Permission use shifts with context, so the "normal" that anomaly detection depends on never holds still.

The identity standards built over the last two decades, OAuth, OpenID Connect, SAML, all assume a stable, predictable principal on the other end of the transaction. The Cloud Security Alliance's research on agentic identity is blunt about the mismatch: agents are neither stable nor predictable, so frameworks built on that assumption don't transfer cleanly. That's part of why the AIUC-1 Q2 2026 update split agent identity and agent access management into two separate control domains. You need different technical mechanisms to authenticate an agent than to govern what it's allowed to do.

The consequence that matters for everything that follows: because agents are a different kind of principal, the threat models built for human users and service accounts don't just underperform against agent-driven attacks. They miss entire categories of them.

MCP as the primary attack surface for agent identities

Most of those missed attacks happen through one protocol. The Model Context Protocol is the dominant way agents connect to external tools, APIs, and data sources, so the way MCP is built shapes almost everything about how agent identity gets attacked.

The problem sits in the middle of the connection. An MCP server sits between the agent and the tool it's trying to use, and it has no built-in way to check that the agent presenting credentials is actually the agent it claims to be. It can't tell a legitimately acting agent apart from one that's been hijacked. That gap is a hole at the center of how the protocol decides who gets to do what.

The exposure isn't limited to internal systems, either. A Trend Micro internet scan found hundreds of MCP servers on the public internet with no authentication and no encryption at all, and a follow-up count found the number had nearly tripled. A meaningful share of the agent identity attack surface is open to anyone on the internet by default because that's how a meaningful share of deployments were set up.

The credential handling failures compound it. Datadog research cited audits that turned up thousands of exposed API keys and passwords, all traced back to insecure MCP credential handling. Put the two findings together: servers with no authentication, sitting in public, holding thousands of live credentials. That's the surface the rest of this piece is built on.

The four attack classes that specifically exploit agent identity properties

Tool description poisoning is one of four primary attack classes catalogued in the MCP-38 threat taxonomy, documented in the CSA's AIUC-1 Q2 2026 research note. It works by corrupting the description an agent reads to decide how to use a tool, so the agent's own reasoning becomes the delivery mechanism for the attack. None of this requires stealing a password. It requires manipulating what the agent believes it's supposed to do, so that permissions the agent legitimately holds get used in ways nobody authorized.

With indirect prompt injection, this can happen mid-task, while no one is watching. Malicious instructions get embedded in whatever a tool hands back to the agent, a webpage, a document, an email, an API response, and those instructions redirect what the agent does next, with no human operator seeing or approving the redirect. Penligent's AI Agent Security guide puts the mechanism precisely: the attacker isn't compromising the model itself, they're compromising the agent's decision environment. A webpage looks like data to the human user, but to the model reading it, that same webpage is instructions.

This isn't a hypothetical risk sitting in a research paper somewhere. HackerOne logged a surge of prompt-injection reports running more than five times the baseline, so you can see this attack class active in production systems right now. Microsoft's disclosure of CVE-2026-26030 and CVE-2026-25592 in Semantic Kernel illustrates how unsafe interaction between model-controlled data and agent tools can escalate from prompt influence to code execution. And because an agent's own actions generate new information that becomes new context for its next decision, these attacks chain. One action produces output, that output becomes input, and so the agent takes another action based on it. Ordinary applications don't work this way, and the security tools built for ordinary applications have no model for a chain like that.

The confused-deputy problem exploits a different property: delegated authority itself. When an agent holds an active connection to something valuable, a production database with write access, an ERP system, a financial platform, and that agent gets compromised through prompt injection or network access, the attacker inherits everything the agent was trusted with. No credential store needs to be touched at all. The MCP server has no way to verify where the request actually originated, so the agent ends up laundering unauthorized intent through credentials that were authorized all along.

The scale of this gap is visible in survey data. The 2026 CISO AI Risk Report, cited by Practical DevSecOps, found that a large majority of security leaders lack full visibility into their AI identities, that most organizations don't enforce access policies for those identities, and that most AI systems already have access to core business platforms, ERP, CRM, financial systems, while very few of those organizations govern that access with any real rigor.

Parasitic tool chaining moves the attack sideways. A compromised tool redirects the agent to call other tools outside its approved workflow, turning permission to use one tool into a pivot point for reaching tools the agent was never meant to touch. OX Security's April 2026 disclosure of a systemic vulnerability across Anthropic's MCP implementations in Python, TypeScript, Java, and Rust showed how wide this can run across a single ecosystem. The entry point for a lot of this is depressingly mundane: 9 out of 11 major MCP directories and community hubs accepted and published a typosquatted malicious package with no automated security review, no source-code analysis, and no publisher verification. OWASP has since formalized this as its own category, ASI04, agentic supply-chain vulnerabilities, covering compromised MCP servers directly, and the AIUC-1 Q2 2026 update responded by making third-party access monitoring mandatory and extending tool-call validation to explicitly cover MCP servers.

The Claude Code RCE from February 2026, disclosed by Check Point Research, shows where this attack class ends up in practice: remote code execution through a poisoned repository configuration file, leading to API key exfiltration. Anthropic patched the issue across Claude Code 1.0.111+ and 2.0.65+, covering CVE-2025-59536 for the RCE and CVE-2026-21852 for the key exfiltration.

Four attack classes, one shared mechanism: each one takes a property that makes agents useful, delegation, autonomy, the ability to chain tool calls, and turns it into the thing that makes the attack work.

Why conventional detection tools miss these attacks

Behavioral baselining is the backbone of most identity threat detection, and it depends on a principal whose behavior stays roughly the same over time. If a user normally touches a handful of systems and suddenly touches dozens, that looks anomalous. If a service account always calls the same endpoint and suddenly calls a new one, that looks anomalous. An agent whose access pattern is supposed to vary from one task to the next can't be baselined this way at all, because the variation is the design, not the anomaly.

Delegation makes the gap worse. Existing IAM tools can see that agent-A called tool-X. They have no way to see that agent-A was acting under delegation from user-B, who only granted that delegation for a specific task. Without that context, a confused-deputy exploit just looks like an authorized call going through an authorized channel, because it is one.

The logs these systems produce don't help much either. Agentic systems generate records that are hard to parse, and the decisions behind those records happen through processes that are difficult to inspect from the outside. When something goes wrong, the damage is concrete: files get altered, access controls change, audit trails get deleted. But to reconstruct how it happened, you need tracing built for this specific problem, not general-purpose log review.

Penligent's guide frames the detection gap as five questions a security team needs to answer continuously: what information can influence the agent, what can it access, what actions can it take, under whose authority, and what stops a compromised agent from turning influence into real damage. Conventional SIEM and UEBA tools weren't built to answer any of these, because none of them were designed around a principal that delegates, adapts, and spawns other principals.

The OWASP Agent Control Standard, released September 1, 2026, makes this explicit: production agents need to be inspectable, traceable, instrumentable, and subject to runtime policy enforcement. The absence of those properties is the detection gap itself, not a configuration problem waiting on a patch.

Some practitioners argue the fix is simpler than a new control framework: extend OAuth 2.0, SPIFFE, and OIDC federation far enough and the gap closes. The CSA's response cuts against that directly. Those standards were built around stable, predictable principals, so stretching them to cover dynamic, multi-level delegation and context-dependent permissions changes what kind of problem is being solved.

What effective detection for agent identities must cover

Closing this gap takes four capabilities that have no real counterpart in conventional identity threat detection: visibility into the full delegation chain, validation of tool-call intent, real-time detection of behavior that drifts from an agent's registered business purpose, and tamper-proof tracing of every action an agent takes.

If you want every tool call traceable back to the human who originated the delegation, you need visibility through every sub-agent that sat in between, including the identity of whichever agent made the immediate call. The Five Eyes guidance on "Careful Adoption of Agentic AI Services," published May 1, 2026, by CISA, the NSA, Australia's ASD ACSC, the Canadian Centre for Cyber Security, NCSC-NZ, and NCSC-UK, recommends giving each agent a verified, cryptographically secured identity and issuing it short-lived credentials. That architecture makes delegation-chain attribution possible.

Just-in-time credential issuance is the mechanism that makes this work in practice. An agent authenticates using its workload identity, receives credentials scoped narrowly to the task at hand, and holds nothing of value once the task ends. That collapses the window during which a confused-deputy exploit can do any damage, because there's no standing credential sitting around waiting to be inherited by an attacker.

Before a privileged operation runs, you need to check the action being requested against the agent's registered business purpose. That single check catches tool-description poisoning and parasitic chaining at the moment they happen, by flagging actions that are technically authorized but don't belong in the current context.

The CSA's Runtime Identity Governance model, known as RIG, builds all of this into one continuous process. It evaluates an agent's identity, its delegation chain, its intent, its context, and its behavior continuously throughout its operational life, including after it's first provisioned. That continuous evaluation is the structural answer to the problem this piece opened with: agents don't hold still long enough for a one-time check to mean much. Detection has to move at the same pace the agent does, for as long as the agent keeps acting.