BlueRadius Research
AI Agent Security Report 2026
The New Enterprise Identity Attack Surface
AI agents now authenticate, hold privileges, call tools, and act on their own. That makes them a new kind of enterprise identity, one that can reason about how to use its access. This report synthesizes the strongest public evidence and an original dataset of 21 documented cases to ask what that does to enterprise security.
Published September 2026. By BlueRadius Research.
Executive summary
For thirty years, enterprise security has sorted identities into two boxes: people, who make decisions but move at human speed, and machines, which move fast but only do what their code says. AI agents fit neither box. An agent authenticates, holds privileges, calls APIs, runs code, invokes tools, and increasingly acts without a human in the loop. Unlike a service account, it decides how to use that access, reasoning in natural language about the task in front of it.
That combination, machine-speed access with human-like decision autonomy, is the heart of the problem. A service account cannot be talked into misusing its permissions. An agent can. Untrusted text it reads, an email, a code comment, a support ticket, a web page, can carry instructions it then carries out with its own legitimate credentials. The result is a privileged identity whose behavior an outsider can influence.
To ground this, BlueRadius built a dataset of 21 publicly documented AI-agent security cases and coded each one. The findings are consistent: excessive privilege in 76%, prompt injection in 71%, and a bypass or absence of human approval in every single case. Only 19% are confirmed real-world incidents; the rest are disclosed vulnerabilities and red-team demonstrations, which means the documented risk is running ahead of documented exploitation. The window to get agent identity right is open now.
Key findings
AI agent risk in numbers
Six figures from the BlueRadius dataset of 21 documented cases. Every percentage is reproducible from the published dataset.
100%
of the documented cases either bypassed human approval or had none in the path, from zero-click exfiltration to agents ignoring an explicit instruction.
OWASP GenAI: Top 10 for Agentic Applications (2026)76%
involved excessive agent privilege: the agent operated with developer, user, or production-level access far broader than the task required.
CISA + Five Eyes: Careful Adoption of Agentic AI Services71%
involved prompt injection, most of it indirect, where untrusted data the agent read carried the instructions it then obeyed.
OWASP GenAI: Top 10 for Agentic Applications (2026)81%
fit the lethal-trifecta pattern: injection, plus an outbound tool or channel, plus broad standing privilege in one agent.
Invariant Labs: GitHub MCP toxic-agent flow29%
involved the Model Context Protocol, the connective tissue between agents and enterprise tools, a boundary barely two years old.
Model Context Protocol: Authorization specification19%
were confirmed real-world incidents. The rest were disclosed vulnerabilities or red-team demonstrations: documented risk is running ahead of documented exploitation.
Anthropic: Disrupting an AI-orchestrated espionage campaignWhat the documented cases have in common
Share of the 21 documented AI-agent security cases exhibiting each characteristic. Strict counts; partial cases excluded. Reproducible from cases.csv.
Source: OWASP GenAI: Top 10 for Agentic Applications (2026). BlueRadius dataset (n=21); mapped against OWASP Top 10 for Agentic Applications
The core concept
The agent identity problem
Why an AI agent is not a service account with a language model bolted on, and why that changes its risk profile.
Every identity model an enterprise already runs, human accounts, service accounts, workload identities, was built on an assumption: either the identity has judgment and moves at human speed, or it has no judgment and only executes fixed code. AI agents break the assumption. They reason like a human and act like a machine.
The technical consequence is specific, not a slogan. A traditional service account is deterministic: given the same inputs it does the same thing, and the only way to change its behavior is to change its code. An agent is non-deterministic and instruction-following: its behavior is shaped at run time by whatever text enters its context, including text from untrusted sources. So the agent inherits the fast, broad, standing access of a machine identity, and layers on a decision process that an attacker can reach through ordinary content. That is a genuinely new risk characteristic, and it is why our dataset shows prompt injection and excessive privilege travelling together.
| Characteristic | Human identity | Service account | Workload identity | AI agent identity |
|---|---|---|---|---|
| Decision-making | Human judgment | None (fixed code) | None (fixed code) | Dynamic LLM reasoning |
| Behavior | Variable, intentional | Deterministic | Deterministic | Non-deterministic, prompt-steerable |
| Autonomy | Self-directed | Scripted / triggered | Scripted / triggered | Semi-autonomous, goal-seeking |
| Initiates its own actions | Yes | No | No | Yes, and reasons about how to use its privileges |
| Steerable by untrusted input | Social engineering (slow, human-paced) | No | No | Yes, prompt injection, at machine speed |
| Typical privilege | Role-scoped, periodically reviewed | Often over-provisioned, rarely reviewed | Scoped to a workload | Often inherits the user's, or runs broad |
| Memory / context | Human memory | Stateless | Stateless | Persistent and poisonable |
| Auditability | Attributed to a person | Attributed to the account | Attributed to the workload | Often ambiguous: agent, or the user it acts as? |
BlueRadius model, informed by NIST/NCCoE agent identity work, Microsoft Entra Agent ID, Google Agent Identity, and AWS AgentCore Identity (see sources).
The dataset
Inside the 21 cases
Our original contribution is not new incident data. It is a coded, sourced dataset of what has actually been documented, with the classifications kept honest.
We collected publicly documented AI-agent security cases from 2024 to 2026 and included a case only when a real, retrievable primary source described it: a researcher writeup, a CVE or advisory, a vendor disclosure, or a threat-intelligence report. Each case was coded for its failure characteristics and, critically, for what kind of evidence it is.
That last distinction matters more than any single percentage. A laboratory demonstration on a prepared repository is not a breach. A patched CVE with no confirmed exploitation is not a breach. Blurring the three is how AI security coverage loses credibility, so we keep them separate everywhere the numbers appear. In this set, 48% are disclosed vulnerabilities, 33% are red-team demonstrations, and 19% are confirmed real-world incidents.
The full dataset, including every source URL and the calculation script, is published so any figure here can be reproduced or challenged.
What kind of evidence is this, really?
The 21 cases by evidence type. Documented risk currently exceeds documented in-the-wild exploitation.
Source: Anthropic: Disrupting an AI-orchestrated espionage campaign. BlueRadius dataset (n=21)
BlueRadius taxonomy
How agent security actually fails
Not a renamed framework. These categories were derived by coding the dataset, then cross-checked against OWASP, NCSC, and CISA guidance.
Excessive agent privilege
76% of casesThe agent holds far more access than its task needs, so any successful manipulation inherits a large blast radius. The single most common condition in the dataset.
Indirect prompt injection as access bypass
71% of casesUntrusted data the agent reads (an email, an issue, a web page, a document) carries instructions it obeys, turning legitimate privilege against its owner.
Credential and secret exposure
33% of casesAgents hold, request, or leak tokens, keys, and passwords, from OTP theft in a browser agent to standing production credentials.
Insecure MCP and tool integration
29% of casesTool poisoning, impersonated or malicious servers, and command-injection in agent tooling. A new integration boundary that is still hardening.
Unbounded autonomy and approval bypass
100% of casesAuto-run, auto-approve, or an agent overriding an explicit human instruction. No case in the set had effective, enforced human oversight at the decisive step.
Agent identity confusion and weak attribution
cross-cuttingWhen an agent acts as the user, logs cannot cleanly separate the agent's decision from the human's intent, breaking accountability and non-repudiation.
The dominant real-world shape is the "lethal trifecta": an agent that can be reached by untrusted input, holds broad standing privilege, and has an outbound tool or channel to act through. It appears in 81% of the dataset. Removing any one leg, narrowing the privilege, isolating untrusted input, or gating the outbound action, breaks the chain. That is where the controls below concentrate.
The integration boundary
Why MCP changes the attack surface
The Model Context Protocol is how agents plug into enterprise tools and data. It is not inherently insecure, but it is a new trust boundary, and it sits in a place traditional security has never had to defend.
MCP standardizes how an AI client connects to servers that expose tools, resources, and prompts. Enterprises adopt it because it turns every integration into a common interface, and the major model providers now support it. The 2026 specification carries a real authorization model built on OAuth 2.1: servers must validate that a token was issued specifically for them, and token pass-through is explicitly forbidden.
The problem is that MCP collapses trust boundaries that traditional software keeps apart, and the model sits across all of them. There are four, and the 2025 to 2026 research shows attacks at every one:
Tool definitions are input to the model
A tool's name and description are injected into the model's context as instruction-bearing text. A server author can hide directives there that the user never sees. This is tool poisoning, first demonstrated against Cursor in April 2025.
Tool output is untrusted data in the reasoning loop
Even with fully trusted tools, the data an agent reads can carry instructions it obeys. The GitHub MCP demonstration steered an agent into leaking private repositories, without compromising the MCP server itself. It is an architecture problem, not a bug.
OAuth answers the wrong question
The authorization layer rigorously decides whether a token may call a server. It says nothing about whether the model should invoke a given tool with a given argument. A perfectly authorized token can still be driven to exfiltrate data.
The transport reaches the host
Local MCP servers run as child processes with the developer's privileges and read credentials from the environment. Config-to-command execution and an unauthenticated local proxy reachable by DNS rebinding turned this into real RCE (CVE-2025-49596, CVSS 9.4).
Source: Model Context Protocol: Security best practices. See also academic measurement of 67,057 MCP servers finding 833 vulnerable (arXiv:2510.16558)
How access is granted
Two answers to who the agent is
The industry has split on the most basic question: does an agent get its own identity, or does it act as the user? Both models are shipping in 2026, and most enterprises are running neither cleanly yet.
The agent gets its own identity
The cloud providers now issue each agent a first-class, governed identity. Microsoft Entra Agent ID makes agents identity accounts distinct from service principals, each with a human sponsor. Google gives each agent a SPIFFE-based cryptographic identity with a 24-hour certificate and tokens bound to it. AWS Bedrock AgentCore issues per-agent workload identities backed by a token vault. This is the model NIST, CISA, and NCSC all point toward: a unique, attested, short-lived identity per agent.
The agent acts as the user
The model and tooling layer takes the opposite approach. Anthropic, OpenAI, and Cloudflare have agents act on behalf of the signed-in user through delegated OAuth 2.1, inheriting that person's existing permissions. It is simpler and it respects source-system access, but it also means the agent is only as contained as the user is over-permissioned, and attribution blurs: the logs show the user, not the agent's decision.
The reality underneath both is messier. Vendor data puts non-human identities at anywhere from roughly 20 to more than 100 for every human, GitGuardian counted 28.65 million secrets leaked to public repositories in 2025, and stolen credentials remain the single most common way a breach begins. First-class agent identity is a mostly-2026 capability, and adoption has not caught up: most agents today still run on inherited user permissions or shared service-account credentials.
Sources: Microsoft, Google, AWS, Anthropic, GitGuardian, CyberArk. NHI ratios are vendor-reported and span a wide range; cite the range, not one figure.
The response taking shape
What the standards bodies now say
Through 2026 the guidance converged fast, and it converged on identity.
Treat agents as identities, not anonymous automation
The February 2026 concept paper argues AI agents should be identifiable entities in enterprise identity systems, with authorization via OAuth and policy-based access control, and logging that traces every action back to the agent and to the human who delegated it.
NIST / NCCoE: Software and AI Agent Identity and Authorization (concept paper)Least privilege, human oversight, per-agent identity
The joint guidance names privilege escalation and accountability gaps among its core risks and calls for progressive rollout, no broad access, continuous monitoring of agent behavior, and a verified, short-lived identity for each agent.
CISA + Five Eyes: Careful Adoption of Agentic AI ServicesA unique identity and the shortest-lived credentials
Every agent should get its own identity that differentiates it from humans, hold only the permissions the task needs with credentials of the shortest possible lifetime, and be monitored as a form of user activity.
UK NCSC: Managing the cyber risk of agentic AIIdentity and privilege abuse is a top-tier agent risk
The 2026 Top 10 for Agentic Applications lists Identity and Privilege Abuse as a category in its own right, alongside tool misuse, agentic supply-chain risk, and rogue agents.
OWASP GenAI: Top 10 for Agentic Applications (2026)Response
What security leaders should do
Priorities that follow from the evidence, mapped to disciplines you already run.
Methodology
Research integrity and methodology
How this report was built, and its limits, stated plainly so any figure can be checked against its source.
The dataset and how cases were coded
A case was included only when a real, retrievable primary source documented it: a researcher writeup, a CVE or advisory, a vendor disclosure, or a threat-intelligence report. Twenty-one cases met that bar. Each was coded for failure characteristics and classified as a real-world incident, a disclosed vulnerability, or a red-team demonstration. These are kept separate wherever numbers appear.
How the statistics are calculated
Every percentage uses strict counts over the 21 cases; ambiguous or partial classifications are excluded from headline figures rather than rounded up. No percentages are blended across sources. Vendor figures for non-human identity are attributed to their source, labeled as telemetry or survey, and the identity-to-human ratio is given as a range because published figures vary widely.
Known limitations
The sample is small and describes what has been publicly documented, not the full universe of agent deployments; it skews toward well-instrumented vendors and active researchers. Documented cases lag real exploitation in both directions. Where a source could not be verified to primary-source standard, the case was excluded rather than estimated.
Findings in this report represent analysis of the cited public data and an original BlueRadius dataset, not a proprietary survey of organizations. BlueRadius did not survey organizations.
BlueRadius analyzed publicly available cybersecurity research, vulnerability disclosures, incident reports, and standards guidance from the sources identified in this report, and compiled an original dataset of documented AI-agent security cases. Data analysis and report development were supported by automated and AI-assisted tools, with findings reviewed by BlueRadius for accuracy and cybersecurity context.
Cite this research
This report is free to cite and link. No permission is required for reasonable citation. Please attribute to BlueRadius Research and link to the report.
BlueRadius. "AI Agent Security Report 2026: The New Enterprise Identity Attack Surface." BlueRadius Research, 2026. https://blueradius.io/research/ai-agent-security-report-2026
References
Data sources and references
Every figure on this page is traceable to one of the following primary sources.
About BlueRadius
Govern the identities you cannot see
BlueRadius is a practitioner-led cybersecurity practice. We help mid-market and regulated organizations run security programs that hold up under scrutiny, including the AI-agent and non-human-identity risk this report describes.
Related from BlueRadius
Securing AI Agents
The practitioner guide that pairs with this research
AI Cybersecurity Incident Report
Observed AI-related incidents and trends
Slopsquatting
The agent supply-chain risk hiding in AI-suggested code
Shadow AI
The AI your company is running without tracking
Third-Party Cyber Risk Report
Agents are third-party risk with a new front door
AI Governance Services
Where controls like these get built into how you use AI