TL;DR
AI agent security now ranks as the biggest barrier to scaling agentic systems. Through 2026, attackers went after agent tooling, protocols, and supply chains rather than the models themselves. Containment fails more often than most teams expect, though the controls that work already exist.
What changed in agent risk during 2026?
Agents gained real authority this year, and attackers followed them in. Instead of targeting models, intruders went after the tools, protocols, and packages that agents depend on.
Agents stopped acting as demos and started acting as staff. They read email, open tickets, query databases, and ship code. Attackers noticed the shift. Notably, the new targets sit outside the model: the plumbing, the registries, and the config files nobody reviews.
Cloud Security Alliance research puts the share of organizations reporting at least one agent-caused incident at 65%. Sensitive data showed up in 61% of those cases. Operational disruption followed in 43%, and 35% carried a direct financial loss. Meanwhile, McKinsey found 72% of enterprise leaders naming cybersecurity as a top blocker to scaling agents.
Adoption ran well ahead of control. Around 81% of teams moved past planning on agent projects, yet only 14.4% send every agent through security or IT approval. On average, teams monitor just 47.1% of the agents they run. In short, half the fleet operates with no logging and no owner. Healthcare fared worst, with 92.7% of organizations reporting a confirmed or suspected agent incident.
How do attackers compromise an AI agent?
They feed it instructions hidden inside content it already trusts. Three routes dominate: prompt injection, exposed tooling, and poisoned supply chains.
Prompt injection arrives as ordinary data
Few injections look like an attack. Instead, the payload rides inside a calendar invite, a GitHub issue title, a support ticket, or a web page the agent reads on your behalf. Multi-turn versions work best. Researchers recorded success rates near 92% across eight open-weight models during 2025 and 2026, steering systems toward unsafe actions over several polite turns.
Zenity Labs showed the pattern. A calendar invite landing in an inbox hijacked a browser agent, with no click from the user. Similarly, one malicious GitHub issue title kicked off a chain that ended with a backdoored npm package reaching more than five million users. Notably, neither attack required a password or a software flaw.
Tools and protocols make softer targets
Agents act through tools, so whoever controls the tool layer inherits the agent's permissions. Trend Micro found 492 Model Context Protocol servers sitting on the public internet with no authentication. Meanwhile, Microsoft patched an Azure DevOps MCP authentication bypass that handed over API keys and tokens at CVSS 9.1. For example, a single exposed endpoint gives an attacker the same reach as the agent that trusts it.
Check Point Research also demonstrated remote code execution against a coding agent through poisoned repository configuration files. In each case the attacker never touched the model. Rather, they took the plumbing, then let the agent finish the job with credentials it already held.
Notably, buyers have started asking about agent supply chains during vendor review. Security questionnaires now cover which registries an agent pulls from, how new tools get approved, and who signs off on each integration.
Supply chain poisoning scales fastest
Agents install skills, packages, and models from public registries, which hands attackers enormous leverage. During the ClawHavoc campaign, researchers traced 1,184 malicious packages to 12 publisher accounts. A single uploader accounted for 677 of them. At peak, one in five packages in that ecosystem carried something hostile. Consequently, one poisoned package could reach every team that installed it.
Training data shares the weakness. For example, 250 poisoned documents can plant a backdoor that fires only on a trigger phrase, while general performance looks normal. Standard evaluation misses it. Provenance gaps make the problem worse, since models pass through conversion, quantization, and fine-tuning pipelines where small tampering survives every hop.
Why can't most teams contain a misbehaving agent?
Because the agent does what its permissions allow, so nothing looks broken. Most teams also lack any switch that stops an agent mid-task.
Trouble starts when permissions stretch far past the job. The table below shows how few teams can scope, attribute, or halt the agents they run.
| Capability | Organizations |
|---|---|
| Cannot enforce purpose limits on an agent | 63% |
| Cannot terminate a misbehaving agent | 60% |
| Still rely on shared API keys between agents | 45.6% |
| Treat agents as distinct identities | 21.9% |
| Treat agents as insiders for risk purposes | 19% |
For example, a compromised research agent once slipped hidden instructions into output that a financial agent then consumed, which triggered trades nobody approved. That cascade needed no human error, only trust between two systems. Similarly, an autonomous red-team agent breached one consultancy's internal AI platform within two hours, without any pre-provisioned credentials.
The same gaps cost far more at national scale. Between December 2025 and January 2026, agent-directed attacks on Mexican federal and state systems exposed 195 million taxpayer records and moved 150GB of data out the door. Attackers then walked laterally across agencies using access the agents held.
Most teams also lack the people to close the gap. Roughly 78% of organizations run without dedicated AI security staff, so responsibility lands on application security teams who inherited a problem nobody trained them for. Consequently, analysts expect agent governance tooling to more than triple its share of security spend by 2029.
What controls actually reduce the risk?
AI agent security starts with visibility, then narrows authority to the smallest workable scope. Seven controls cover most of the exposure.
We build agent workflows for clients every week, and we start every build with this list.
- Inventory every agent. Count coding assistants, support copilots, document processors, and any vendor tool holding an OAuth grant into your systems.
- Give each agent its own identity. Shared keys destroy attribution. Short-lived tokens, issued per task and retired on completion, remove standing privilege.
- Put limits at the data layer. Scope what an agent can reach, rather than what it asks for.
- Sandbox the tools. Block destructive verbs by default, then allow them for one named task.
- Keep a human on irreversible steps. Deleting records, moving money, and changing security settings all deserve a second signature.
- Control egress. Segment sensitive feeds so a hijacked agent has nowhere useful to send anything.
- Rotate plaintext credentials. Agent config files hold keys in the clear far more often than teams expect.
The NIST AI Risk Management Framework lines up well with that list. Additionally, it gives security teams vocabulary their auditors accept, which shortens the budget conversation.
What are regulators doing about it?
They moved fast in 2026. NIST launched a dedicated agent standards program in February, and its draft guidance already treats least privilege as a baseline.
Three workstreams sit under that program: a governance layer, a control overlay for SP 800-53 covering single-agent and multi-agent deployments, and a concept paper on agent identity and authorization. Specifically, the identity work proposes extending OAuth 2.0 to cover non-human principals, which finally treats an agent as its own actor.
NIST also drafted a Cyber AI Profile that frames agents as possible attack vehicles rather than mere targets. It describes agents as capable of running reconnaissance, exploitation, credential harvesting, and lateral movement on their own. Accordingly, the draft presents least privilege and continuous authentication as baseline requirements. Anyone fluent in the Cybersecurity Framework will recognize the structure.
Binding rules will take time. Still, procurement moves faster than legislation. Federal contractors, financial firms, and healthcare providers already field questions about agent controls during vendor review. Consequently, teams that build governance now will answer from evidence rather than intent.
How should a business start this week?
Start AI agent security with one agent that touches customer data, rather than the whole fleet. Answer four questions about it, then repeat.
Ask who owns it, what it can reach, what it must never do, and how you switch it off in a hurry. Most teams stall on the last two, which points at the real work.
Scan your own environment next: check for /mcp and /sse paths, then look for any 0.0.0.0 bindings that expose an agent server to the internet. Rotate any key sitting in plaintext config. Also pin the versions of the servers and skills your agents load, then add those config paths to code review.
Finally, run a tabletop exercise where an agent turns hostile and somebody has to stop it. The OECD AI principles back this approach, calling for mechanisms that supersede or deactivate systems drifting outside intended use.
This work adds days to a rollout, not months. Agents earn their keep when they act with real authority, so we set the boundaries before we hand over the keys. Meanwhile, teams that wait will inherit somebody else's incident report.
