The Agentic AI Security Testing Gap: 176 Probes, Three Protocol Layers, and a Cliff Where Coverage Should Be

By Neal Bridges

There is a pattern in security that repeats every time a new technology layer gets adopted faster than the tooling can follow. We saw it with cloud infrastructure between 2014 and 2018. We saw it with containers from 2016 to 2020. We saw it again with Kubernetes from 2018 to 2022. Each time, the adoption curve outpaced the security testing curve by two to three years. Organizations deployed production infrastructure they could not meaningfully assess, and attackers noticed the gap before defenders closed it.

We are in that gap right now with agentic AI. And the distance between what is deployed and what can be tested is wider than any of those previous cycles.

The Three-Layer Attack Surface Nobody Is Testing End-to-End

Agentic AI in 2026 is not the chatbot integration layer of 2024. The production deployment architecture for modern agentic systems looks something like this:

An LLM sits at the center of the stack. Connected to it are MCP servers, Anthropic's Model Context Protocol, which expose tools, data sources, and system operations to the model through a standardized JSON-RPC interface. Around that, A2A agents, Google's Agent-to-Agent protocol, enable multiple AI agents to discover each other, communicate, delegate tasks, and coordinate work across trust boundaries.

This is not one attack surface. It is three, layered on top of each other, with trust boundaries that most security teams have not mapped and most security tools were not designed to assess.

I am the CISO at Query.AI. The environment I am responsible for runs agentic AI in production: MCP servers, A2A agent communication, LLM-powered workflows integrated into operational security tooling. When I sat down to assess this stack, I expected to find rough edges in the tooling landscape. What I found was a structural gap that no combination of existing tools could close.

What Exists Today and Where It Falls Short

LLM scanning is the most mature layer by a significant margin. NVIDIA's Garak provides 176 probes across 36 modules, with coverage mapped to the OWASP LLM Top 10. It is a well-architected tool. Its plugin system for generators, probes, and detectors is genuinely well-designed. But Garak was built to assess standalone LLMs. It probes model behavior through direct prompt interaction. It does not model the attack path that runs through tool invocations, resource access, or agent-to-agent message passing. When the LLM is embedded in an agentic workflow, the attack surface extends well beyond what Garak's generators can reach.

MCP scanning has a few entrants doing important work. Invariant Labs' mcp-scan provides passive analysis: tool poisoning detection, prompt injection pattern matching, cross-origin checks, rug pull detection, toxic flow analysis, and schema validation. It is useful as a static analysis layer. But it was built before HTTP Streamable transport became the production standard for MCP, and before the OWASP MCP Top 10 was published. It does not do active probing. When I needed to fire payloads at MCP tool endpoints, observing how they responded to SQL injection through JSON-RPC tool arguments, command injection via parameter manipulation, path traversal through resource URIs, and SSRF attempts leveraging the server's network position, I was writing those probes myself.

A2A scanning has Cisco's a2a-scanner, which provides spec compliance checking, YARA rule matching, heuristic vulnerability detection, and endpoint analysis. For what it covers, it is solidly built. But it does not fingerprint the underlying agent framework, does not verify whether advertised capabilities match actual behavior, and does not probe for the A2A-specific attack vectors that researchers have been documenting: agent card spoofing, task state hijacking, cross-agent prompt injection through message passing, and capability mismatch exploitation.

The cross-protocol gap is the most consequential problem. No existing tool models the attack chain that moves laterally from LLM prompt injection, through MCP tool exploitation, to A2A agent compromise. That is the attack path that matters in production agentic deployments. That is the path a sophisticated adversary would take. And as of February 2026, it is the one nobody was testing.

The Numbers That Made Me Start Building

When I inventoried the probe coverage available to me across the full agentic stack, the picture was stark.

LLM layer: 176 probes via Garak. Mature, approximately 8 out of 10 in terms of industry readiness for what it covers.

MCP layer: 16 active probes in a custom deep scanner I had started building, supplemented by passive analysis from mcp-scan. Approximately 5 out of 10 readiness. The OWASP MCP Top 10 had been published, but the tooling to test against it with active payloads barely existed.

A2A layer: Zero probes that I owned and could customize for my threat model. Entirely dependent on Cisco's external tooling for compliance checking, which I could not extend to cover the protocol-specific attack vectors I needed to assess.

176 probes for LLMs. 16 for MCP. Zero for A2A that I could own.

That is not a gap. That is a cliff.

I started mapping NVIDIA Garak's probe taxonomy against MCP and A2A attack surfaces to understand cross-protocol applicability. The analysis revealed that roughly 51 probes, about 29 percent of Garak's library, are directly applicable to MCP with protocol-level adaptation. About 35, roughly 20 percent, apply to A2A. The remaining 51 percent are LLM-specific: training data replay, glitch token analysis, content safety boundaries, and hallucination detection, with no meaningful equivalent in the agent protocol layers.

But the more significant finding was that MCP and A2A each have protocol-specific attack surfaces that no LLM scanner was designed to address. For MCP: tool poisoning, SSRF through tool arguments, OAuth confused deputy attacks, sampling exploitation, and encoding bypass variants that deliver injection payloads through base64, ROT13, hex, and Unicode transformations of tool parameters. For A2A: agent card spoofing, capability mismatch exploitation, task state manipulation, and cross-agent injection through the message passing layer.

These attack vectors require net-new probes. Not adaptations of existing ones.

The target probe state I set: 322 across all three protocols. That meant writing 50-plus new probes from scratch and adapting another 80-plus from Garak's existing modules to operate in agentic protocol contexts.

What I Built and How

Over the past several months, working with Claude Opus 4.6 and OpenAI Codex as development accelerants, I have been building a testing framework that treats LLM, MCP, and A2A as a unified attack surface. The architecture required forking existing open-source scanning tools and extending them with protocol-aware generators, probes, and detectors that understand JSON-RPC tool invocation semantics, Agent Card capability enumeration, and cross-protocol trust relationships.

I had to build fingerprinting capabilities for MCP servers and A2A agents that simply did not exist. Before you can meaningfully test an agentic system, you need to understand what you are looking at: what tools are exposed, what capabilities are advertised versus actually implemented, what framework is running underneath, and how the trust relationships between agents and servers are configured. Think of it as the reconnaissance layer that traditional network scanning has had for decades, but for the agentic protocol landscape.

I had to construct a system that does not just find individual vulnerabilities but captures the methodology an attacker, or an automated agent, would use to chain findings across the full kill chain: from initial reconnaissance through exploitation to lateral movement between protocol layers.

This is not a vendor pitch. I have a full-time job. I built this because the environment I am responsible for required assessment capabilities that did not exist, and waiting for the vendor market to mature was not an option I had.

Why This Matters Beyond My Environment

Every organization deploying agentic AI in production is sitting on the same unassessed attack surface. Most do not know it yet. The ones that do know it are either waiting for vendors to catch up, or quietly building internal tooling and custom assessment processes the same way I did.

The regulatory pressure makes the timeline concrete. The EU AI Act's high-risk system requirements take effect August 2, 2026. That is less than six months from today. If your AI systems touch biometrics, critical infrastructure, education, employment, law enforcement, or democratic processes, you will need to demonstrate risk management systems, technical documentation, and post-market monitoring. "We scanned the LLM" will not be a sufficient answer when the attack surface includes the tools, agents, and protocols the LLM connects to.

Penalties for non-compliance reach up to 35 million EUR or 7 percent of global annual turnover for prohibited practices. Finland already has an active national enforcer as of January 2026. The enforcement machinery is not theoretical.

The question for security leaders is not whether agentic AI needs security testing. The question is whether you can produce evidence that you have tested it against the attack vectors that actually exist in these protocol stacks.

What Comes Next in This Series

Over the next several weeks, I am going to write about what I built, how I built it, and where the gaps still are. I will cover the probe parity problem in technical detail, the architectural decision to fork Garak, how I built fingerprinting for protocols that had no fingerprinting tools, a methodology capture system that goes beyond vulnerability scanning, and what the EU AI Act actually requires in terms of agentic AI security evidence.

If you are a security leader staring at MCP servers and A2A agents in production and wondering how to assess them, this series is for you. If you are building agentic AI systems and wondering what the security implications look like from the defender's perspective, this series is also for you.

First technical deep-dive drops next Tuesday.