The ledger remembers what the hype forgets. Last week at DEF CON 34, the hype was about AI agents. But the ledger—the data trail of 2,388 exposed Sentry DSNs, 71 of which belonged to top million websites, and roughly 27% of Fortune 1000 companies linked through a single Cloudflare MCP integration—tells a different story. It tells a story of an architectural flaw, not a bug. It tells a story of how trust, when placed in the wrong variable, becomes a vector.
I’ve spent years auditing code that promises to handle assets. Now, I’m auditing code that promises to handle decisions. The attack disclosed by Tenet Security at DEF CON 34, dubbed “Agentjacking,” is not a novel vulnerability in the traditional sense. It is a combinatorial exploit chain that weaponizes the default trust an AI agent places in its data sources. This is not a model-level attack; it is a system-level integrity failure. The bug was there before the launch, embedded in the assumption that an error message is just data, not a potential instruction.
Let me break down the context. The attack targets the Model Context Protocol (MCP), the middleware layer that connects AI coding agents—like Claude Code and Cursor—to external tools. Sentry, a widely used error monitoring platform, is one such tool. Agents use MCP to query Sentry for debugging information. The attack exploits a fundamental design choice: Sentry’s ingestion endpoint accepts error reports from any source, as long as the report contains a valid DSN (Data Source Name). This is standard for error monitoring; it’s designed to be open. But when combined with an agent that reads those reports and executes “fixes” based on the content, the open door becomes a Trojan horse.
Here is the core analysis. The attack chain has six distinct stages, and I have seen patterns like this before in DeFi audits. It is a classic “cross-context injection” attack, but with a new payload. The chain is as follows: First, an attacker scans for publicly exposed Sentry DSNs—these are often leaked in client-side code, public repositories, or error logs. This is information gathering, and it is cheap. Second, the attacker sends a crafted HTTP POST request to the Sentry endpoint, containing a malicious error event. The payload is not just a stack trace; it is a markdown document that looks like a fix instruction. Third, a developer, working on a project, encounters an error. They ask their AI agent, via MCP, to fetch the Sentry issue. The agent retrieves the malicious payload. Fourth, the agent treats the markdown as a legitimate fix suggestion. The model cannot distinguish between data and instructions in this context—it is an architecture-level gap. Fifth, the agent executes the “fix,” which is often a command to install a malicious npm package or run a shell script. Sixth, the malicious package exfiltrates credentials stored on the developer’s machine: AWS keys, GitHub OAuth tokens, npm registry tokens, Docker credentials. The entire chain is automated and takes seconds.
From my experience auditing DeFi protocols, I can tell you that this is a standard “reentrancy” pattern, but in the semantic layer. The agent is the vulnerable contract, the MCP is the external call, and the Sentry data is the malicious input that modifies state. The logic gap is clear: the agent trusts the data from the tool without verifying it. The attack does not require breaking any cryptographic barriers; it exploits a design assumption. The 85% success rate cited by Tenet, based on controlled tests with over 100 organizations, is alarming but not surprising. In a real-world scenario, the success rate would be high because the developer is actively seeking the agent’s help. The agent is seen as a helper, not a security boundary.
Now, the contrarian angle. The market’s initial reaction is to focus on Sentry’s content filter as a fix. But that is a stopgap, not a solution. A content filter is a string-based blacklist for specific payloads. It is equivalent to the early days of SQL injection, where developers blocked quotes. It can be bypassed with encoding, obfuscation, or simply changing the payload structure. The real blind spot is not the payload; it is the architecture. The MCP protocol, as currently designed, has no mechanism to tag data as “trusted,” “untrusted,” or “instruction.” Every piece of data from an external tool is treated as equal context. This is a protocol-level design flaw. The second blind spot is the assumption that error monitoring systems are read-only. In reality, they are writeable by anyone with a DSN, and that DSN is often public. The third blind spot is the lack of a “human-in-the-loop” for command execution. The agent executes commands without asking for confirmation, or the confirmation is a mere formality. The root cause is not the AI model; it is the system integration.
Trust is a variable, not a constant. The industry has treated AI agents as an extension of the developer, but they are actually an extension of the network. Every line of code is a legal precedent, and every MCP integration is a potential liability. The takeaway is not that you should stop using AI agents. The takeaway is that you must audit your assumptions. The attack will evolve. The content filter will be bypassed. The agent-jackstop tool from Tenet, which adds network egress whitelists, command approval, and subprocess credential protection, is a good non-architectural mitigation. But it does not fix the root cause. The only real fix is to change the architecture: either the MCP protocol must enforce a “data vs. instruction” label, or the model must be trained to treat all tool output as untrusted until verified. Neither is trivial.
I predict that within the next six months, we will see a fork of the MCP protocol that adds a security extension layer. We will see enterprise security teams banning unmonitored MCP integrations. And we will see a new category of security products: “Agent Security Gateways” that sit between the agent and all external tools, filtering and signing data. The agents will become smarter, but the attack surface will grow. The ledger remembers that the bug was there before the launch. The question is whether we will learn from it before the next crash.


