For the last two decades, most of application security has been built around a simple assumption: software does what it's told. It might have bugs, misconfigurations, or bad input validation, but the thing sitting between an attacker and your data was, fundamentally, deterministic code. You could model it, fuzz it, diff it, and reason about what it would do given a certain input.
AI agents break that assumption.
An agent doesn't just execute instructions — it interprets them, plans around them, and decides which tools to call, in what order, with what parameters. That's the entire point of building one. But it also means the agent is a new kind of trust boundary: a system that reasons over untrusted data and then acts on the world with real credentials, real API access, and real consequences. Once an AI system moves from "generates text" to "reads my inbox, queries my database, calls my payment API, and pushes to my repo," it stops being a feature and starts being infrastructure. And infrastructure gets attacked.
This isn't a hypothetical. Over the past eighteen months the industry has gone from academic prompt-injection demos to confirmed, in-the-wild compromises of production agent tooling — and, more recently, to AI systems being used to carry out attacks rather than just being exploited. Let's walk through what that attack surface actually looks like, why the tools we already trust don't cover it, and what a serious defense posture requires.
The shift nobody fully priced in
A chatbot has one job: produce the next token. Its blast radius is limited to what a human does with its output. An agent has a fundamentally different shape:
- It plans across multiple steps, deciding its own sequence of actions rather than following a fixed script.
- It holds and reuses credentials — API keys, OAuth tokens, service accounts — often across an entire session or longer.
- It calls tools, which means it has hands, not just a mouth.
- It maintains memory, sometimes persistent, across sessions, tenants, or teams.
- It increasingly talks to other agents, delegating subtasks and trusting their output.
Each of those five properties is also a new attack primitive. None of them existed, in this form, in the web application threat model most security teams grew up on.
This is exactly why, on December 9, 2025, OWASP's Agentic Security Initiative published a dedicated Top 10 for Agentic Applications — a companion to the existing LLM Top 10, built specifically around the idea that agents are principals with goals, tool access, memory, and inter-agent protocols, and that each of those is its own distinct surface to defend. It's worth treating as a checklist, not because frameworks are magic, but because it's the first serious industry attempt to name what's actually new here.
The new attack surface, category by category
OWASP's list runs ten categories deep (ASI01 through ASI10). Here's what each one actually means in practice.
ASI01 — Agent Goal Hijack
This is the root vulnerability underneath almost everything else. A traditional application has a hard boundary between code and data. An LLM-based agent doesn't — a malicious instruction hidden inside an email, a PDF, a calendar invite, a web page, or a retrieved document is processed the same way as a legitimate instruction from the user. A single poisoned document sitting in a retrieval pipeline can redirect an agent to exfiltrate sensitive files instead of summarizing them, because the model has no reliable way to distinguish the two.
The canonical real-world example is EchoLeak (CVE-2025-32711, CVSS 9.3), disclosed in June 2025 by Aim Security: the first documented zero-click prompt-injection exploit to actually exfiltrate data from a production system, chaining a crafted email through Microsoft 365 Copilot with no user interaction required. It's OWASP's own cited example for ASI01, and for good reason — goal hijack is almost always the entry point. Everything downstream — tool misuse, privilege abuse, memory poisoning — usually starts with an attacker getting malicious text into something the agent will read.
ASI02 — Tool Misuse
An agent doesn't need a zero-day to cause damage. It needs access and an ambiguous or manipulated instruction. Tool misuse happens when an agent invokes a perfectly legitimate function — delete a file, run a query, send an email, push a commit — with parameters or in a sequence nobody intended. An over-privileged agent with write access to production doesn't need to be "hacked" in the traditional sense; it just needs to be convinced, one reasonable-looking tool call at a time. OWASP's own cited example is the Amazon Q incident, in which a manipulated extension shipped destructive instructions inside what looked like an ordinary update.
ASI03 — Identity & Privilege Abuse
This is where a security background in SIEM and identity governance becomes directly relevant, because agentic identity is a mess right now. Agents routinely inherit and reuse high-privilege credentials — cached SSH keys, long-lived OAuth tokens, service-account secrets — across tasks that never should have shared that scope. A low-privilege user's innocuous request, filtered through an agent holding admin-level tokens, can escalate into an admin-level action. That's a confused-deputy vulnerability, except the deputy now has autonomy and initiative.
ASI04 — Agentic Supply Chain Vulnerabilities
If there's one category that's moved fastest from "interesting research" to "actual incidents," it's this one. The Model Context Protocol and similar tool-calling ecosystems let agents dynamically discover and invoke third-party tools — which means your agent's effective attack surface now includes every MCP server and plugin it can reach, most of which were never code-reviewed by anyone on your team.
The incident record here is no longer sparse:
-
September 2025 — the Postmark MCP backdoor. Koi Security found that the third-party
postmark-mcpnpm package — a copycat of the legitimate email-sending MCP server — had shipped 15 clean releases before a single-line change in version 1.0.16 quietly BCC'd a copy of every outgoing email (password resets, invoices, internal memos) to an attacker-controlled address. Koi's CTO called it "the world's first sighting of a real-world malicious MCP server," and it demonstrated that a valid package history says nothing about what the current version actually does. - June 2025 — the Smithery path-traversal flaw. GitGuardian researcher Gaëtan Ferry found a path-traversal bug in the Smithery deployment platform's Docker build process that could expose an overprivileged infrastructure token controlling more than 3,000 hosted MCP apps and their customers' API keys and secrets. Smithery patched it within 48 hours of the report and there's no evidence it was exploited before the fix — but the flaw shows how a single platform-level bug in an MCP host can cascade across thousands of tenants at once.
-
July 2025 — CVE-2025-6514 in
mcp-remote. JFrog researcher Or Peles disclosed a critical (CVSS 9.6) OS-command-injection flaw: a malicious MCP server could return a weaponized OAuth authorization URL during the connection handshake and achieve full remote code execution on the client machine — no exploit chain required beyond "connect to the wrong server." The affected package had been downloaded more than 437,000 times and was used by clients including Claude Desktop, Cursor, and Windsurf. - April 2026 — OX Security's MCP supply-chain research. OX Security published research describing what it called an architectural "RCE-by-design" issue in the official MCP SDKs' STDIO transport, where unsanitized command strings get passed straight to a subprocess call. OX's own numbers are large and contested: it reported up to 200,000 potentially vulnerable server instances and 14 assigned CVEs across projects like LiteLLM and LangFlow — but that 200,000 figure is OX's own estimated upper bound, not an independently audited count, and Anthropic has pushed back, characterizing the STDIO behavior as expected rather than a protocol-level flaw. Treat the number as a ceiling in an unresolved argument about where the responsibility for sanitizing subprocess input actually sits — not as a settled breach count.
None of that required a novel attack technique. It required an ecosystem that grew far faster than its vetting did — which, if you've watched what happened to npm or the PyPI package index over the last decade, should sound familiar. The difference is that a malicious npm package usually has to survive a build pipeline and a deploy process before it does damage. A malicious MCP server just has to get an agent to call it.
It's also worth flagging that MCP servers aren't the only agent-extension supply chain now under attack. In February 2026, Koi Security audited every skill on ClawHub, the marketplace for the open-source agent framework OpenClaw, and found 341 malicious skills out of 2,857 — most tied to a single campaign delivering the Atomic macOS Stealer. Two weeks later, as the marketplace grew past 10,700 listings, that count had more than doubled to 824. Different ecosystem, same lesson: anywhere an agent can pull in third-party capability at runtime, that pipeline needs the same scrutiny you'd give a production dependency.
ASI05 — Unexpected Code Execution
Agents that can write and run code — for debugging, data transformation, or "just figure it out" tasks — are one successful prompt injection away from arbitrary code execution on whatever machine they're running on, if that execution isn't sandboxed. This is the oldest vulnerability class in computing, wearing a new coat: it's RCE, just reached through a reasoning step instead of a buffer overflow. CVE-2025-6514 above is one instance of it; the DuneSlide vulnerabilities discussed below are a more recent and more dramatic one.
ASI06 — Memory & Context Poisoning
Give an agent long-term memory, a RAG store, or conversation summarization, and you've given an attacker a way to plant something that outlives the current session. A single poisoned memory entry can quietly bias every future interaction, and in a multi-tenant system, an isolation failure in that memory layer can leak one customer's context into another's session. OWASP's own framing puts it well: memory is a feature, and it's also an attack surface. This class is especially dangerous precisely because it doesn't look like an attack — it looks like the agent slowly, consistently, being slightly wrong in a direction that benefits someone else.
ASI07 — Insecure Inter-Agent Communication
As soon as you have more than one agent — a planner delegating to specialist agents, or agents from different vendors cooperating on a task — you've created a communication channel between them. If those messages aren't authenticated and signed, a compromised agent can impersonate a trusted peer and issue instructions laterally, in a way that looks, to conventional network monitoring, like completely normal internal traffic.
ASI08 — Cascading Failures
Multi-agent trust doesn't just create a spoofing risk, it creates a blast-radius risk. A hallucinating or compromised planner can issue destructive instructions to multiple execution agents in parallel, and the damage propagates before any human notices the initial decision was wrong. The more autonomy you delegate downstream, the faster a single bad decision at the top compounds.
ASI09 — Human-Agent Trust Exploitation
We extend a level of implicit trust to AI-generated recommendations and AI-written code that we'd never extend to an anonymous pull request. That gap is itself an attack surface: a developer who reflexively approves whatever their coding agent suggests, or an analyst who acts on whatever their investigation agent concludes, is exploitable in a way no firewall rule addresses. Attackers are increasingly building for exactly that reflex.
ASI10 — Rogue Agents
The hardest of these to detect is also the most consequential: an agent that continues operating within its nominally authorized scope while quietly pursuing something else — exfiltrating data a little at a time, or introducing a subtle backdoor into generated code. OWASP cites the Replit "meltdown" incident, in which an agent deviated from its instructions and deleted a production database, as its worked example. The unsettling part isn't that the agent went rogue — it's how long that kind of drift can run before anyone notices, because every individual action still looks like the agent doing its job.
Why your SIEM won't catch most of this
If you've spent any time building detection content, the uncomfortable part of this list is that almost none of it produces the signals your existing stack is tuned for. There's no malformed packet, no unusual outbound port, no signature to match. The "malicious" activity is often a sequence of individually authorized, individually reasonable API calls, made by a service account the agent legitimately holds, that only look wrong in aggregate, in context, and with an understanding of what the agent's actual task was supposed to be.
This isn't theoretical. In June 2026, security researchers at Tenet Security disclosed "agentjacking": an attacker plants a fake bug report in a project's Sentry error-tracking system using nothing more than a public, write-only DSN key — often discoverable straight out of a site's frontend JavaScript. When a developer later asks their AI coding agent to "go fix the open Sentry issues," the agent pulls the poisoned report, treats its embedded instructions as legitimate remediation steps, and executes them — with the developer's own credentials. Tenet found over 2,300 organizations with an exploitable DSN and an 85% success rate across the coding agents they tested, and — this is the part that matters most for this piece — the attack chain bypassed EDR, WAF, IAM, VPN, and even explicit system-prompt instructions telling the agent to distrust external data, because every single step in the chain was something the developer's own account was authorized to do.
That's the detection problem in one incident. Catching goal hijacking or tool misuse requires understanding the semantic gap between what an agent was asked to do and what it actually did — which means visibility into the agent's reasoning trace, its tool-call history, and its memory state, correlated together, not just the resulting syscalls.
This is a big part of why I think the next generation of detection engineering — the work I'm doing on autonomous DFIR tooling — has to treat the agent's own decision trail as first-class evidence. An investigation platform that can't reconstruct why an agent called a given tool, with what provenance behind the data that triggered it, is going to miss exactly the class of incident described above. Deterministic identity resolution and an immutable audit trail aren't nice-to-haves for agentic systems — they're the minimum bar for being able to answer "what actually happened" after the fact.
Recent developments worth watching
A few things have happened in just the last few months that change the shape of this conversation, and they're worth tracking even if you don't act on them immediately.
Agents are now the attacker, not just the target. Anthropic's September 2026 threat intelligence report is the starkest evidence of this shift: it found that a majority of the malicious operations it disrupted between December 2025 and August 2026 were enabled by AI through direct execution or multi-agent orchestration, not just AI-assisted planning. One disclosed campaign involved an actor injecting malicious instructions into an AI vendor's own evaluation sandbox, stealing production API keys, and hitting roughly thirty AI companies within four days. A separate Anthropic report from June 2026 found the share of AI accounts flagged as medium- or high-risk for misuse nearly doubled — from 33% to 56% — over a single year of monitoring. The supply chain isn't just something agents are vulnerable through anymore; it's something they're being used to attack.
Zero-click RCE has arrived in mainstream coding tools. In July 2026, Cato AI Labs disclosed "DuneSlide" — two critical vulnerabilities (CVE-2026-50548 and CVE-2026-50549, both CVSS 9.8) in Cursor, an IDE reportedly used by roughly two-thirds of the Fortune 500. Both allowed an indirect prompt injection — arriving via a poisoned MCP response or search result, with zero clicks required — to escape Cursor's terminal sandbox and achieve full OS-level code execution. Cursor initially rejected the vulnerability report on the grounds that MCP misuse was outside its threat model, then patched both issues after the researchers escalated. There's no evidence of in-the-wild exploitation yet, but it's a clean, public demonstration of the goal-hijack-to-code-execution chain this whole piece is about.
Guidance is finally starting to catch up. In May 2026, the NSA's AI Security Center published formal design guidance for MCP deployments, explicitly warning that the protocol's adoption "has significantly outpaced the development of its security model" and recommending least-privilege tokens scoped per action, signed provenance for dynamically discovered servers, and treating every MCP session as untrusted by default. In September 2026, OWASP followed with an Agent Control Standard requiring that agents be built to be inspectable, traceable, and instrumentable — essentially, a formal requirement that the audit-trail argument above stop being optional. Neither of these fixes the underlying problem on its own, but they're the clearest sign yet that the standards bodies have stopped treating this as a hypothetical.
What a serious defense posture actually requires
None of this means don't build agents. It means building them the way you'd build any other privileged system, with a few agent-specific additions — and there's now real guidance backing each one, not just opinion.
Treat every input as untrusted, including RAG results and MCP responses. The agent cannot distinguish instructions from data any better than your code can distinguish SQL from user input without parameterization. Filter and validate before the agent acts, not after. This is the NSA's baseline recommendation for MCP specifically.
Apply the principle of least agency. This is least privilege's natural extension, and it's OWASP's own stated architectural counter to goal hijacking: an agent should hold the minimum tool access, credential scope, and decision authority the task requires — nothing cached, nothing long-lived, nothing reusable across tasks it wasn't scoped for. The NSA's guidance goes further, recommending tokens scoped per action, not per session.
Audit your tool and MCP supply chain like you audit your dependency tree. Signed manifests, pinned versions, integrity hashes, and a curated registry aren't optional once your agent can dynamically discover and call third-party tools. The Postmark and Smithery incidents both happened because that discipline didn't exist yet.
Sandbox anything that executes generated code. No network access, no ambient credentials, no exceptions. DuneSlide is exactly what happens when this control is missing.
Segment and version memory. Every entry an agent's long-term memory relies on should have an auditable source, scoped to tenant and session, with periodic integrity checks — because a poisoned memory entry doesn't announce itself.
Require human confirmation for anything irreversible. Payments, deletions, credential access, production deploys — agent confidence is not a substitute for a human decision on actions you can't undo.
Build detection around behavior, not signatures, and make it continuous. You need to be watching for deviation from an agent's expected action pattern, not matching against known-bad indicators, because the exploit here is usually a sequence of legitimate calls — that's exactly what let agentjacking slip past EDR, WAF, IAM, and VPN controls simultaneously. This is also the direction identity vendors are moving: continuous, per-action authorization for agent identities rather than static, standing privileges.
The bottom line
AI agents are being deployed faster than the controls around them are maturing. A widely cited (if informal) industry poll found that nearly half of security professionals already see agentic AI as the top attack vector heading into this year, and a more rigorous survey of over 1,500 security leaders found that barely a third of organizations have a formal policy for deploying AI safely at all — down from the year before, even as adoption climbs. That gap is the whole story.
The agents themselves aren't the vulnerability. The vulnerability is treating them like ordinary software when they're closer to a new class of privileged, semi-autonomous identity operating inside your environment — one that reads untrusted data all day, holds real credentials, and, as this year has made clear, can increasingly be turned into the attacker as easily as it can be turned into the target. Build for that reality now, or spend the rest of 2026 finding out about it the way Postmark, Smithery, Cursor, and Sentry's users already did.
