Your Sentry Errors Can Now Hack Your AI Coding Agent
A fake bug report can now hijack Claude Code, Cursor, and Codex. The attack requires only a public Sentry DSN and a carefully crafted Markdown payload. Everything else happens through a normal AI-assisted development workflow.
Researchers are calling it Agentjacking. The exploit matters because it exposes a deeper limitation. Current AI coding agents don’t reliably distinguish between trusted tool output and attacker-controlled data, even when explicitly instructed to do so.
How the Agentjacking Attack Works
Most teams running AI coding agents have them wired into MCP servers for tools like Sentry. The workflow is simple. An error fires in production, the agent pulls it through MCP, you tell it to fix the unresolved issues, and it does. That’s the whole pitch of agentic dev tooling: less context-switching, faster triage.
Tenet Security’s Threat Labs team (Ron Bobrov, Barak Sternberg, and Nevo Poran) found the flaw sitting inside that convenience.
A Sentry DSN is the credential used to submit error events to a project, and it’s intentionally public. Most websites running Sentry expose it in their frontend JavaScript because it’s write-only and was never designed to be a secret. That changed once AI coding agents began reading and acting on the data anyone could submit.
Step-by-Step: Inside the Agentjacking Attack
- Find a DSN. Inspect any site’s JS bundle, or run a Censys or GitHub search for ingest.sentry.io. Tenet found 2,388 organizations exposed this way, 71 of them in the Tranco top-1M sites.
- POST a fake error. No auth needed beyond the DSN. The attacker controls the message, stack trace, tags, breadcrumbs, everything. Sentry accepts it and treats it like a real crash report.
- Inject Markdown. The payload renders as a ## Resolution block – headings, code fences, the works – visually identical to Sentry’s own system template once it hits the MCP response.
- Wait for the ask. A developer tells their agent to triage the Sentry issue. Completely ordinary request.
- The agent runs it. It reads the fake “Resolution,” executes the embedded npx command, and the attacker’s code runs with the developer’s full local privileges: AWS keys, GitHub tokens, SSH agent sockets, whatever else is sitting in that environment.
The attacker never touches the victim’s infrastructure. They touch Sentry. Sentry’s MCP server does the rest.
How Effective Is Agentjacking?
Tenet tested against 100+ real organizations under controlled conditions:
- An 85% exploitation success rate across Claude Code, Cursor, and Codex
- A Fortune 100 company, roughly $250B, had an agent execute the payload
- Confirmed hits across finance, healthcare, government, and critical infrastructure in 30+ countries
- Sandboxed CI agents got hit too, even with network restrictions enabled (CODEX_SANDBOX_NETWORK_DISABLED), because the payload doesn’t need a network path in – it rides through data the agent was already told to read
That last one is the part that should worry people more than the headline number. Containment is the standard answer to untrusted execution: sandbox it, restrict the network, assume the blast radius is capped. Turns out none of that matters if the malicious instruction shows up as data inside a channel the agent already trusts. The agent still reads it and still decides to act on it. And the blast radius ends up being whatever credentials happen to be sitting in that box at the time.
Why Prompting Doesn’t Stop Agentjacking
Tenet also tried the obvious fix: system prompts telling the agent to treat MCP output as untrusted and never run commands without confirmation.
The agents ran the payload anyway 85% of the time. That’s the same number as before, instructions or no instructions.
Forget the Sentry hole for a second, this is the finding that matters. Models don’t apply the same skepticism to a tool response that they apply to a message someone actually typed. A reply from an MCP server looks like a trusted system output structurally, even when its contents started life as an anonymous POST request an hour earlier. You can’t fix that by wording the system prompt better. It’s how the model weighs one input channel against another, and that’s not a knob you turn from outside.
How Sentry Responded to the Agentjacking Disclosure
Tenet disclosed the issue to Sentry, which acknowledged it the same day and described the vulnerability as “technically not defensible” at the architectural level. The initial mitigation was a global content filter that blocks the published payload. That helps against a known exploit, but the underlying issue remains: an AI agent still has no reliable way to distinguish trusted tool output from attacker-controlled content.
Why Agentjacking Is Bigger Than Sentry
Sentry’s MCP server does exactly what it’s supposed to: surface error data. The flaw is the trust boundary between any externally-writable data source and an agent that treats tool output as authoritative.
Swap Sentry for Linear, GitHub Issues, Slack, Jira, or PagerDuty, and the attack looks identical. Anywhere a stranger can write content that eventually lands in your agent’s context window is a candidate vector. Sentry just gives the cleanest demo, since its ingest endpoint is intentionally open to anyone holding a DSN.
How to Defend Against Agentjacking
Prompt-layer fixes failed in testing, so the practical mitigations sit at the infrastructure layer instead:
- Rotate and proxy DSNs. Route through a server-side relay instead of leaving them exposed in client bundles where anyone can read them.
- Require human approval before consequential actions: package installs, shell commands, anything triggered by content the agent pulled from a tool rather than typed by a person.
- Audit every MCP integration for whether it can return externally-influenced data, and treat those as untrusted input by default, not system data.
- Scope agent credentials tightly. The actual damage in Tenet’s tests came from whatever was sitting in the environment: AWS keys, GitHub OAuth tokens, SSH sockets. An agent that can’t reach a credential can’t leak it.
Tenet also open-sourced agent-jackstop, drop-in hardening configs for Cursor and Claude Code aimed at this exact attack class, if you want a starting point.
The Trust Problem Behind Agentjacking
Tenet defines this vulnerability as the “Authorized Intent Chain,” a sequence where every individual action is technically legitimate. The initial POST request to Sentry, the agent’s outbound communication, and the utilization of developer credentials all mirror standard operational traffic. Consequently, this attack bypasses traditional security frameworks: including EDR, WAF, IAM, and firewall – because no single step in the process is unauthorized. Security protocols are designed to detect malicious behavior, yet they remain blind to malicious intent within an authorized workflow.
Current security paradigms lack a mechanism to address an authorized agent performing harmful actions based on deceptive data. This structural gap persists because models do not yet possess the inherent skepticism a human developer applies when encountering a suspicious bug report. Until AI agents can critically evaluate their inputs, connecting an agent to any externally-writable data source, whether Sentry today or another collaborative platform tomorrow, presents a critical and unmitigated risk to organizational security.
A note on the numbers: the 2,388-org count, the 85% success rate, and the Fortune 100 detail all come from Tenet’s own research, and Tenet sells an agent-security product. The mechanism itself is corroborated independently by The Hacker News, Infosecurity Magazine, and the Cloud Security Alliance, but the specific stats haven’t been independently replicated. Worth keeping in mind before treating them as settled fact.
