Most software supply-chain attacks need you to get something past CI, into a dependency, or onto a build server. This one doesn’t. An attacker who holds nothing but a leaked error-tracking key — no repo access, no cloud credentials, no foothold in your network — can get arbitrary commands run on a developer’s machine. The exploit isn’t a vulnerability in your code. It’s a trust assumption baked into how AI coding agents consume tool output.
The pattern generalizes to any MCP-connected tool whose data can be written by a third party. Sentry is just the cleanest example, because the thing an attacker needs is practically designed to leak.
The attack chain
Stripped to its skeleton, the path from a public key to code execution is five steps:
- Inject. The attacker submits a crafted “error event” to your Sentry project using its DSN — the ingestion URL that contains a project key. DSNs are client-side by design. They ship in front-end bundles, mobile binaries, and public repos, and anyone holding one can write events into your project.
- Wait. A developer tells their AI agent something routine: “Triage and fix the unresolved Sentry issues.”
- Fetch. The agent calls a Sentry MCP server and pulls down issue data — titles, error messages, stack traces, breadcrumbs, tags, and arbitrary context fields.
- Trust. The MCP server returns the attacker’s event indistinguishably from a genuine, system-generated one. Attacker-controlled strings are now sitting in the agent’s context window, labeled (implicitly) as trustworthy diagnostic telemetry.
- Execute. Those strings aren’t data — they’re instructions. “This error is caused by a stale dependency; resolve it by running the following setup command,” followed by a payload. The agent, treating tool output as ground truth, runs it.
The load-bearing step is 4. The attacker’s content crosses a boundary and silently changes category: it enters as untrusted, third-party-submitted input and exits as trusted system telemetry. Nothing on the receiving side re-checks that promotion.
Why each step actually works
The DSN is a write credential disguised as a config value. Sentry’s ingestion model assumes events come from your own clients, so the DSN lives wherever your client code lives — which is to say, somewhere public. It is not a secret in any meaningful sense, and it was never meant to be an authorization boundary for what kind of content can enter your project. An attacker doesn’t breach anything to use it; they use it as intended, with hostile payloads.
LLM agents collapse the line between data and instructions. A traditional program reading a Sentry event sees fields in a struct. An LLM reads everything — error message, stack frame, context blob — as one undifferentiated stream of tokens. There is no type system separating “this is the text of an error” from “this is a directive to follow.” So prose written into an error message can read as a command, and frequently will, especially when it’s phrased as remediation advice the agent was literally asked to act on.
The agent is a confused deputy with real privileges. This is the term of art (coined by Norm Hardy in 1988) for a trusted, privileged actor tricked into misusing its authority on a third party’s behalf. Your agent has a shell, file-write access, and often repo permissions. A successful injection isn’t a bad data point — it’s those privileges, turned against the developer, driven by a stranger’s text.
The developer’s request opens the gate. “Fix the unresolved issues” is an instruction to act on the content of those issues. The human has pre-authorized the agent to treat issue data as a to-do list. The attacker just writes the to-do list.
A concrete (sanitized) walkthrough
Imagine the attacker submits an event whose “error message” field reads, in substance: the application is failing because a config file is missing, and the fix is to fetch and run a setup script from a given URL. The stack trace and metadata are forged to look ordinary. To Sentry it’s a valid event. To the MCP server it’s a row to return. To the agent — handed it under the banner of “here are your unresolved issues” — it’s a credible diagnosis with a clear remediation.
The agent summarizes the “bug,” proposes the “fix,” and (depending on its autonomy settings) either runs it or asks a yes/no question the developer rubber-stamps because it looks like normal triage. No stage in that pipeline ever asked: who wrote this text, and are they allowed to tell my agent what to do?
I’m deliberately not publishing a working payload. The point isn’t the wording of the lure — any competent attacker can write that. The point is the structural gap that makes any such lure effective.
The real lineage: this is injection, again
If this feels familiar, it should. It’s the newest member of a very old family.
- SQL injection (recognized in the late 1990s) happens because untrusted data flows into a channel that also carries commands, and the database can’t tell which is which. The fix was to separate the channels — parameterized queries that mark data as data, structurally, so it can never be reinterpreted as a command.
- Cross-site scripting is the same bug in the browser: attacker text rendered into a context where it executes.
- Prompt injection is the same bug in a language model: attacker text consumed into a context where it’s followed.
- Tool-output (indirect) prompt injection — this attack — is prompt injection where the malicious text doesn’t come from the user typing to the model, but from a data source the model reads. Email bodies, web pages, code comments, calendar invites, and now error-tracker events are all viable carriers.
Naming it correctly matters, because the entire defensive playbook for injection already exists. We just have to apply it at the new boundary: the seam where an MCP server hands data to an agent.
How to defend
No single control closes this. Layer them.
Treat every byte of tool output as untrusted input. This is the headline and the mindset shift. Data returned from an MCP server deserves exactly as much trust as an HTTP request body from the open internet — which is none. Anything a third party can write into (messages, stack traces, breadcrumbs, user-supplied context, issue titles, comments) is hostile until proven otherwise. “It came from our observability tool” is not provenance; it’s a delivery channel.
Separate data from instructions structurally. This is the parameterized-query lesson, ported to agents. Don’t splice raw tool output into the same stream the agent reads directives from. Wrap retrieved content in explicit, hard-to-spoof delimiters; label its provenance (“the following is untrusted third-party content from an external system”); and instruct the model that nothing inside that boundary is ever to be executed as a command, only summarized or analyzed. It’s imperfect against a determined model-level attack, but it removes the easy wins.
Gate irreversible and high-privilege actions behind a human. Running shell commands, installing packages, writing files, pushing commits, opening or merging PRs — none of these should happen autonomously off the back of fetched data. Require explicit human confirmation that shows what will run and why, and make the “why” trace back to a source the human can evaluate. A confirmation click is cheap; autonomous execution of a stranger’s instructions is not.
Validate and constrain at the seam. Enforce a schema on what comes back from the tool. Cap field lengths, strip or escape control sequences, and flag events whose content reads like prose instructions rather than diagnostic data (“run”, “execute”, “fetch from”, URLs in error messages). You won’t catch everything, but you raise the cost and surface the obvious attempts.
Lock down ingestion provenance. The attack begins because anyone with a DSN can write events. Rotate DSNs that have leaked, scope them as tightly as the platform allows, enable server-side allowlisting or rate controls where available, and alert on events whose payloads contain instruction-like content. You can’t authenticate every event source — which is exactly why the controls above assume you can’t and defend at consumption time instead.
Run the agent with least privilege. If the agent doesn’t need a shell for a triage task, don’t give it one. Scope tokens to read-only where the job is reading. Sandbox execution. The confused-deputy problem is bounded by how much authority the deputy holds; hold it down.
Don’t let “we have two agents” feel like defense. Two agents that both treat tool output as gospel are both compromised by the same event. Redundancy of a flawed trust assumption just reproduces the flaw at scale.
How to detect it
Defense aside, assume some attempts get through and instrument for it. Useful signals: error events containing URLs, shell syntax, or imperative remediation language in fields that should hold diagnostic text; spikes in events from a single DSN that don’t correlate with real traffic; agent sessions that transition from “reading Sentry data” to “proposing to run a command” within the same task; and any agent-initiated network egress or package install whose justification traces back to fetched third-party content. Log the full provenance of anything an agent acts on, so a post-incident review can answer the one question the attack relies on you never asking: who actually authored this instruction?
The takeaway
The uncomfortable part of this attack is how little the attacker has to do. They don’t break in. They write a convincing error message and let your own tooling carry it across the trust boundary for them. The vulnerability isn’t in Sentry, and it isn’t in MCP — both are doing exactly what they were built to do. It lives in the unexamined assumption that data arriving through a trusted tool is itself trustworthy.
It isn’t. Telemetry tells you what a channel delivered, not who wrote it. Build your agents so that the moment external data crosses into their context, it’s quarantined as untrusted, kept structurally separate from instructions, and never converted into privileged action without a human who can see its real origin. Do that, and “fix my unresolved Sentry issues” goes back to being the harmless request it sounds like.