Agentjacking: When Your AI Coding Agent Becomes the Insider Threat

Over the past few weeks, a quiet vulnerability has been exploited not in code, but in the trust between human developers and their AI coding assistants. The attack vector? A public error tracking system and a protocol designed to connect agents to tools. At DEF CON 34, researchers from Tenet Security demonstrated how an attacker can turn a developer's Sentry account into a weapon against their own AI agent. The numbers are sobering: 2,388 public Sentry DSNs, 71 among the top 1 million websites, and 27% of Fortune 1000 companies potentially exposed through Cloudflare's MCP integration. This is not a theoretical risk—it's an attack chain that works with 85% success rate in controlled tests. Three years ago, the crypto world learned that oracles could be manipulated. Today, the lesson is that any data source an agent trusts can be a vector. I've spent years auditing the trust assumptions in smart contracts, and the same principle applies here: when you connect an agent to external data without verifying the integrity of that data, you are building on sand. The attack is called Agentjacking, and it exploits the Model Context Protocol (MCP) that allows AI coding agents like Cursor and Claude Code to read from and write to tools like Sentry, a popular error monitoring platform. The protocol is designed for convenience, but it carries a hidden cost: it treats all data from a tool as context, not as potentially malicious instructions. The attack chain is elegant in its simplicity. Step one: scan for public Sentry DSNs—these are essentially API keys that allow anyone to send error events to a project. Step two: POST a crafted error event containing a markdown-formatted 'fix' that instructs the agent to install a malicious npm package. Step three: wait for a developer to ask their AI coding agent to debug a Sentry issue. The agent reads the error, treats the 'fix' as a legitimate instruction, and executes it. The malicious package then steals credentials stored on the developer's machine—AWS keys, GitHub OAuth tokens, npm registry tokens, and more. Based on my audit experience, this is a textbook example of a composability vulnerability: two individually sound designs—Sentry's open ingestion endpoint and MCP's data-as-context—create a gap when combined. The root cause is not a bug in Sentry or in the AI model. It is an architectural gap: the agent cannot distinguish between data and instructions in the context it receives from a tool. This is the same class of problem as SQL injection, but at a semantic level. From my work on the 2026 AI-Agent Accountability Protocol, I know that the only reliable remedy is to treat all tool outputs as untrusted until verified. But that is easier said than done in a production environment where speed matters. Sentry's response was to deploy a content filter—a blacklist of specific payload strings. That is like putting a band-aid on a wound that needs stitches. The attacker can easily obfuscate the payload. Code does not lie, only humans do. The filter is a human decision to avoid the harder fix. Tenet's own mitigation, agent-jackstop, is a drop-in configuration that enforces network egress whitelists, command approval, and subprocess-level credential protection. It reduces the blast radius but does not change the fundamental architecture: MCP data, once ingested into the agent's context, can still influence decision-making. The protocol itself needs a security extension—something that signals 'this content is data, not an instruction.' Until then, every developer running an AI coding agent with MCP access to public error tracking is a potential victim. But here is the contrarian view: the panic might be premature. The 85% success rate was achieved in a controlled test where researchers simulated the exact conditions. In the real world, the attack requires a specific chain of events: a developer must have a public DSN, must ask their agent to debug a Sentry issue, and must not review the proposed fix before executing it. Many developers do review changes. Also, the attack relies on the agent's adherence to instructions—if the agent is configured with a strong command hierarchy, it might refuse to execute npm install from a markdown block. The real blind spot is not the AI, but the human tendency to trust the machine's output. We saw this in DeFi: users trusted smart contracts without reading the code. Now we trust agents without verifying the source of their recommendations. Truth is often buried under the noise. The noise says 'AI agents are dangerous.' The truth is that the combination of open DSNs and unverified MCP data is a specific configuration risk that can be mitigated with proper security hygiene. The Agentjacking disclosure is not a reason to abandon AI coding agents. It is a reason to demand better security from the entire stack. The next narrative will be about MCP security standards, signed error envelopes, and agent-level sandboxing. As the market moves from 'AI can code' to 'AI can code safely,' the projects that prioritize trust with transparent verification will win. Silence speaks louder than hype. The quiet work of building secure foundations will define the next phase of adoption.