The category has a name. The proof is still missing.
OWASP published its Top 10 for Agentic Applications in December 2025, and it named the territory: tool misuse, identity abuse, goal hijack, memory poisoning, unexpected code execution. If you run a security program, you may already track those acronyms. We do not claim to have named this category, and we do not want to. Naming did not make any of it true about your stack.
What is rare is not the list of risks. It is proof, per surface, per system: a fault that fires twice, a clean negative control, and an adjudication that asks whether the thing you flagged is just doing what it was built to do. The rest of this essay walks the five surfaces we test, with their OWASP tags, the published numbers that make each one real, and what verification looks like on each.
1. The MCP server (ASI02, Tool Misuse and Exploitation). Model Context Protocol servers expose your product's tools to any client that speaks the protocol. The failure mode is boring and payable: a tool call that returns real data with no credentials. It is also measurably common: an independent census of internet-facing MCP servers found 91.8 percent of 414 audited servers without OAuth, and 687 tools exposing shell execution unauthenticated [1]. The same study classifies responses the way we do, distinguishing authentication errors, structured data returns, and successful invocations without credentials. We cite that convergence gladly: one confirmation, independently arrived at. The matrix we run produces a verdict per tool: a rejection with an explicit auth error is a resistance, structured data is a finding, success with no data is neither, and we say so.
2. Identity and delegation (ASI03, Identity and Privilege Abuse). This is not a special case of the first surface, because the question is different. Surface one asks what a tool returns. This one asks with whose identity the agent acted, and the same census's OAuth finding is an identity fact, not just a tool fact: no OAuth means no principal behind the call, which is precisely the condition ASI03 names [1]. The details: the credentials your agent holds, the consent it never asked for, the tool it called as your customer while following instructions from someone else. An agent with delegated authority and no gate on the dangerous verbs is an identity problem that no per-tool matrix catches, because every individual call looks authorized. Verification here is behavioral: what the agent does when told, by whom, and what a human signed.
3. Indirect injection through carriers (ASI01, Agent Goal Hijack). Your WAF blocks a malicious request, then writes that request into a security log, word for word. Later someone asks the log review agent to "check the logs and fix what you find." The agent reads the attacker's text and obeys it, with the agent's own permissions. This is now a named attack class with a headline demonstration: GhostJacking, at DEF CON 34, succeeded in 9 of 10 attempts against a widely used coding agent under the log platform's recommended configuration, and the vulnerable setup was found in 48 organizations including six Fortune 500 companies [2]. Around it sit published instances from cloud audit logs to SOC and SIEM pipelines [3][4][5]. The firewall did its job; the job delivered the attack. We test the full chain: plant, carrier, execution, controls.
4. Agent memory and retrieval (ASI06, Memory and Context Poisoning). The knowledge your agent retrieves is written by whoever can write to the store: feedback forms, uploaded documents, chat history that gets embedded. Poisoned knowledge is worse than a stolen password, because the agent acts on it with confidence and keeps acting on it. The measured reality is uncomfortable: poisoning attacks on agent memory report success rates above 80 percent while corrupting well under one percent of the store [6]. The chain we verify is plant, persist, consume: the poison must survive retrieval, and the agent must obey it, twice, with a clean negative control.
5. Runtime isolation (ASI05, Unexpected Code Execution). Somewhere, model-written code executes. The boundary around it is a claim: this container cannot see the host, this sandbox cannot reach the network. Claims about boundaries are verifiable with a battery of read-only probes: the host's control socket, dangerous capabilities, the kernel ring, writable system paths, an egress canary. Frontier models have been shown to escape containers with exactly these misconfigurations [7]. A clean battery is a containment certificate. A dirty one is a finding no external scanner will show you, because scanners run outside the boundary they would need to be inside.
The canary that quoting cannot satisfy
Injection testing has a known open problem: when a model rejects an injection but quotes the payload while explaining its rejection, a naive grader classifies it as compromised. A 2026 paper on stage-level injection tracking states it plainly: the distinction between citing and obeying is not systematically controlled in existing evaluations [8].
Our canaries are built so the distinction cannot be faked. The instruction we plant asks the reading agent to construct a specific line by joining pieces: that line does not exist, contiguously, anywhere in the carrier. An agent that quotes the log verbatim cannot produce it. Only an agent that obeys can. That construction turns an open grading problem into a deterministic check, and it is the quiet core of every surface above: the fault we credit is the fault that had to be obeyed to exist.
Run the category yourself
We are not the first deliberately vulnerable MCP server, and we say so: Damn Vulnerable MCP Server exists, is listed in the OWASP Vulnerable Web Applications Directory next to Juice Shop, and DVAA covers the agent side [9]. Use them. What our testbed adds is not vulnerability, it is a verdict taxonomy, and its two teaching tools are caught by two different layers: an authentication error wrapped inside a successful result is rejected by the classifier itself, mechanically, before any adjudication. A public-by-design tool returning uptime is a correct classification of a real access that the adjudication layer then kills, because the tool is doing exactly what it was built to do. One layer catches what the other would let through, which is why the product has both. The sample matrix, with every verdict and its evidence, is on our site [10].
What agent-surface testing is not
It is not static analysis of manifests. It is not counting tools or listing endpoints: an census above confirmed production servers in part by listing their tools anonymously, which makes inventory the cheapest and least informative fact about an MCP deployment [1], which makes inventory the cheapest and least informative fact about an MCP deployment. And it is not the phrase "AI security" on a pricing page. Without a fault that fires twice, a clean negative control, and an adjudicator asking whether the endpoint is just doing what it was built to do, a report about agents is a report about nothing. We publish our misses with confidence intervals for the same reason.
There is one sentence underneath all five surfaces, and we owe it to the essays this one sits beside: the control that works lives outside the thing it controls. The verifier lives outside the verified. The boundary is the container's property, not the model's behavior. The mitigations that hold are outside the model. That is not a slogan; it is an architecture, it is testable, and it is the shape of everything we ship.
If any of the five surfaces exists in your stack, it can be tested the way everything we ship is tested. A human signs the scope before anything executes. That last part is not a limitation. It is the product.
engagements@naxxan.ai
Sources
1. Padilla, "Exposed by Design: A Dynamic Security Assessment of Internet-Facing MCP Servers at Scale", arXiv 2608.00150.
2. Tenet Security, GhostJacking, DEF CON 34 (2026-08-09); coverage: SC Media, Cybersecurity News, GBHackers.
3. "LogJack: Indirect Prompt Injection Through Cloud Logs", arXiv 2604.15368.
4. "Poisoning the Watchtower", arXiv 2605.24421.
5. LevelBlue SpiderLabs, "Rogue AI Agents in Your SOCs and SIEMs: Indirect Prompt Injection via Log Files".
8. "Kill-Chain Canaries: Stage-Level Tracking of Prompt Injection", arXiv 2603.28013.
9. Damn Vulnerable MCP Server, OWASP VWAD listing; Damn Vulnerable AI Agent.
10. NAXXAN MCP testbed matrix, naxxan.ai/mcp-matrix.