
Bug reports are untrusted agent input
Tenet Security injected fake Sentry errors and watched coding agents execute the "resolution steps" with the developer's shell and credentials. The broken boundary: data retrieved for diagnosis became instructions.
Tenet Security published an attack this week they call agentjacking, and it deserves to reset how every team wires telemetry into coding agents. The recipe: inject a fake error event into a project's Sentry using its public DSN — the write-only credential that ships in client-side code by design. The poisoned event contains helpful-looking "resolution steps". A developer later asks their coding agent to check Sentry; the MCP server dutifully feeds the event in; the agent reads the resolution steps and executes them — on the developer's machine, with the developer's shell, holding the developer's cloud credentials.
Tenet reports finding 2,388 organizations with injectable DSNs reachable this way, and says more than 100 agents acted on injected errors in its controlled testing. I could not verify the experiment or the counts beyond Tenet's own disclosure, so hold the numbers loosely. The mechanism, though, needs no audit — any developer who has watched an agent eagerly follow a stack trace knows exactly how this works, and worse: Tenet says explicit system-prompt instructions to distrust external data did not reliably stop it.
The boundary that broke
Notice what actually failed. Not authentication — the DSN is supposed to be public. Not the MCP server — it faithfully retrieved what Sentry held. What broke is a boundary most agent setups have never drawn: the line between data retrieved for diagnosis and instructions the agent is permitted to follow.
A bug report is a hostile document. It always was — support inboxes have carried phishing for decades, and every experienced engineer reads "just run this command to fix it" from a stranger with narrowed eyes. But a human triaging Sentry brings that suspicion for free. An agent brings the opposite: it is optimized to be helpful, the poisoned event is formatted exactly like the help it wants to give, and the moment tools are attached, reading becomes doing. Telemetry, tickets, logs, code comments, README files from dependencies — anything an attacker can write and your agent will read is a command channel until proven otherwise.
The equation to internalize: retrieval plus tool authority equals execution. Whoever can write into what your agent reads holds a share of that authority.
The pattern that survives this
At work, the setup I now flag in every review is the developer who asks one agent session to "check Sentry and fix what you find" — a single context holding untrusted telemetry, shell access, and live AWS credentials. That sentence is the vulnerability. The fix is structural, not prompt-level, and Tenet's finding that distrust instructions failed is the proof: you cannot ask the model to be the boundary. The boundary has to be architecture.
Concretely, four moves. Isolate retrieval: the session that reads telemetry gets no shell and no write access — it produces a summary, nothing else. Label provenance: everything crossing into the working session arrives marked as untrusted content, quoted, never inlined as narrative. Strip active instructions: anything shaped like a command, a URL to fetch, or "steps to resolve" gets neutralized in the summary — described, not transcribed. Require a fresh trust decision: execution happens only after a human (or a separately-privileged step) approves the plan, so the leap from diagnosis to action is a decision, never a default.
That is inconvenient. It is also just the confused-deputy lesson every mature security team already knows, restated for a world where the deputy reads at machine speed.
Steal this today: list every read source your coding agents touch — error trackers, ticket systems, CI logs, dependency docs. For each, one question: who can write into this? If the answer includes anyone outside your trust boundary — and for Sentry-style public DSNs it does by design — that source never shares a session with tools that can execute. Two sessions, one seam, human in the middle.
An error report is a stranger handing your agent a note that says "run this" — sandbox the note before the agent holds the keyboard.


