Hook
Imagine you are a developer debugging a production outage. Your AI coding agent, Claude Code or Cursor, is connected to Sentry via MCP, pulling error logs to help you trace the root cause. The agent reads a stack trace, sees a markdown-formatted "fix suggestion" embedded in the error details, and executes it. Within seconds, a malicious npm package is installed on your machine, and all your AWS keys, GitHub tokens, and Docker registry credentials are exfiltrated. You didn't click a malicious link. You didn't install a shady plugin. You just asked your AI to help you fix a bug. This is not a hypothetical — it is the exact attack chain demonstrated at DEF CON 34 by Tenet Security, and it reveals a fundamental architectural flaw in how AI agents trust external data sources.
Context
The attack, dubbed "Agentjacking," leverages the intersection of two legitimate design decisions. First, Sentry, the popular error monitoring platform, accepts error events via a public ingestion endpoint using a DSN (Data Source Name) — a public key that allows any client to send data to your project. Second, AI coding agents integrate with Sentry through the Model Context Protocol (MCP), a standard for connecting agents to external tools like databases, file systems, or monitoring services. The MCP integration allows the agent to fetch Sentry issues as context for debugging. The problem is that the agent cannot distinguish between data and instructions in that context. When an attacker sends a malicious error event containing a markdown-based fix suggestion, the agent interprets it as a command — not as data. The result is a stealthy, high-impact supply chain attack on the developer's machine.
Tenet's research, presented at DEF CON 34, found 2,388 publicly discoverable Sentry DSNs across organizations, including 71 in the Tranco top 1 million websites and roughly 27% of Fortune 1000 companies exposed through Cloudflare's MCP integration. In controlled tests across 100+ organizations, the attack achieved an 85% success rate — meaning that in 85% of cases, a developer using an AI coding agent with Sentry MCP would execute the malicious payload without realizing it.
Core Insight: The Architecture of Trust Betrayal
Let me walk you through the attack chain, because it is the clearest demonstration of why "code is only as strong as the trust it protects." The chain has six stages, and each one is technically mundane — it is the combination that creates the weapon.
Stage 1: Discovery — The attacker scans public repositories, leaked config files, or exposed environment variables to find a valid Sentry DSN. This is trivially easy: DSNs are public keys, often checked into code by accident or exposed in CI/CD logs.
Stage 2: Poisoning — The attacker sends a POST request to Sentry's ingestion endpoint with a crafted error event. The event includes a stack trace and a markdown-formatted "fix" that looks like a legitimate Sentry suggestion. But the markdown contains an embedded command: npm install agentjack-malicious-package. Sentry's endpoint accepts any request with a valid DSN — no authentication beyond the DSN itself.
Stage 3: Trigger — The developer, working on a real bug, asks their AI agent to "check Sentry for recent errors." The agent queries Sentry via MCP, fetches the most recent issues, and includes the attacker's poisoned error event in its context.
Stage 4: Execution — The agent's reasoning engine processes the markdown. It sees the "fix suggestion" as a recommended action. Because the agent is trained to assist with debugging, it treats the markdown as a legitimate instruction. It executes the command — npm install — inside the developer's shell.
Stage 5: Payload — The malicious package runs a post-install script that reads sensitive files: ~/.aws/credentials, ~/.ssh/id_rsa, ~/.npmrc, and environment variables containing tokens. It sends all data to the attacker's server.
Stage 6: Exfiltration — The attacker now has valid credentials for the developer's cloud accounts, code repositories, and package registries. They can inject backdoors into production code, steal proprietary data, or pivot to other systems.
This attack is a specific variant of indirect prompt injection — a well-known vulnerability class where an attacker injects malicious instructions into data that the model consumes. But here, the injection vector is not a website or a document — it is the error monitoring pipeline that developers inherently trust. "Trust isn't compiled, verified, and shared" — it is implicitly given to any tool that passes data into the agent's context window.
Technical Depth: Why Mitigations Are Band-Aids
Sentry's response to the disclosure was to deploy a content filter targeting specific payload strings. This is reactive, not preventative. Attackers can easily bypass a string blacklist by encoding the payload, splitting the command, or using a different package name. The root cause remains: the MCP integration treats all data from Sentry as equally trustworthy, and the model has no mechanism to distinguish between a crash report and a malicious instruction.
Tenet released agent-jackstop, an open-source tool that provides client-side hardening: network egress whitelists, command execution approval prompts, subprocess-level credential isolation, and treating all tool output as untrusted. While these are effective mitigations, they do not change the architectural reality: once data enters the agent's context, it can influence decisions. The agent-jackstop tool is a "drop-in" configuration for Cursor and Claude Code, supporting both personal and MDM enterprise deployment. But it is a stopgap, not a cure.
The deeper issue is that the MCP protocol itself has no concept of content trust level. When an agent calls a tool, it receives raw data. The protocol does not require the tool to declare whether the data is from a public source, whether it has been sanitized, or whether it contains executable instructions. This is a protocol-level gap that will need to be addressed in future MCP specifications — perhaps through a security extension that adds metadata tags for "instruction intent" or "trust boundary."
Contrarian Angle: The Pragmatism Test
Let me challenge my own narrative. Is this attack really as dangerous as it sounds? The 85% success rate comes from controlled tests where developers were actively debugging Sentry issues. In a real-world scenario, the attacker must first trick the developer into asking the agent to check Sentry — or wait for a natural bug-fixing session. This requires a trigger event, which adds uncertainty. Additionally, the attacker must find a valid DSN that is actively used by a developer with an MCP-connected agent. Not all Sentry users have MCP integrations. The 2,388 exposed DSNs is a large number, but the actual number of vulnerable machines is likely smaller.
Furthermore, the attack requires the developer to execute the command without noticing. If the agent displays the command in a terminal or requires a confirmation (as some tools do), the attack fails. However, many AI coding agents execute shell commands silently or with minimal user interaction, especially when the user trusts the agent's judgment. The attack exploits that trust.
Another angle: Tenet's disclosure has a dual purpose. It genuinely identifies a serious vulnerability, but it also serves as a marketing tool for agent-jackstop and their enterprise security consulting. This is common in the security research community, but it means we should evaluate the severity with a healthy skepticism. The "85% success rate" is not independently verified, and the controlled test conditions may not reflect real-world complexity.
Nevertheless, the architectural flaw is real. The attack chain is logically sound and technically replicable. The combination of public ingestion endpoints, MCP data flow, and implicit trust in tool output is a design pattern that will repeat across many AI integrations. This is not a Sentry bug — it is a systemic vulnerability in the way we connect AI agents to external data sources.
Takeaway: The Bridge Between Data and Instructions
We are building a world where AI agents read our emails, check our databases, monitor our errors, and execute our commands. The trust we place in these agents is not just in the model — it is in the entire pipeline of data sources that feed into the model's context. "Bridges aren't built by removing the river — they are built by designing traffic rules that keep everyone safe." In this case, the river is the data flow, and the traffic rules are the trust boundaries between data and instructions.
The immediate takeaway for developers and security teams is clear: disable MCP integrations for any tool that accepts public data unless you have verified the data source. Use agent-jackstop or similar tools. Implement network egress whitelists so that even if a malicious command is executed, it cannot phone home. But the long-term takeaway is for the entire AI ecosystem: we need protocol-level separation of data and instructions, content trust tagging, and agent-side enforcement of execution policies. Without these, Agentjacking is not an isolated incident — it is a preview of the future of AI supply chain attacks.
"Code is only as strong as the trust it protects." Today, that trust is broken. Tomorrow, we have a choice to rebuild it with better architecture.