Spanly Spanly
· Tim Quinteiro

Agentjacking: when your telemetry becomes a prompt-injection vector

Researchers turned a public Sentry DSN into remote code execution by hiding shell commands in an error report. How agentjacking works, why no single tool can filter it away, and how MCP observability surfaces the read-to-exec pivot it leaves behind.

  • mcp
  • security
  • prompt-injection
  • agentjacking

A developer asks their coding agent to debug a production error. The agent pulls the error from Sentry through an MCP server, reads the suggested fix, and runs it. The fix was written by an attacker, and the command shipped the developer’s AWS keys out the door. No exploit and no malware, just a string in a log the agent trusted.

That is agentjacking. The attack is narrow. The class of problem behind it is not.

The Sentry attack

In June 2026, Tenet Security demonstrated agentjacking via Sentry DSN injection. A Sentry DSN is a write-only credential meant to be public; it ships in frontend code so browsers can report errors. Tenet found 2,388 organizations with exposed DSNs, which is DSNs working as designed.

Using that public write access, they POSTed a fake error event with shell commands hidden in its Resolution field, formatted to read like Sentry’s own remediation advice. When a developer later asked their agent to debug, the agent fetched the error through an MCP server, treated it as authoritative, and ran the command under the developer’s credentials. Across more than 100 agent instances against Claude Code, Cursor, and Codex, this worked about 85 percent of the time, reaching environment variables, AWS keys, GitHub tokens, and repository URLs. The agent runs as the developer, so EDR, WAF, and IAM see a trusted user running a trusted tool.

Bigger than one tool

Sentry shipped a filter for the demonstrated payload. The risk does not live in any one product, though. It lives in the agent’s assumption that tool output carries the same authority as its operator’s instructions. Sentry was only the first carrier demonstrated. The same shape works through any tool that relays third-party-writable content: a support desk whose tickets customers write, an issue tracker with outside comments, an analytics tool surfacing user request strings, a web-fetch tool relaying the open internet.

The next carrier will be a different tool and the next payload a rephrase of the last. A defense tuned per tool and per payload always trails the attack. It has to sit where every tool’s output reaches the agent, which is the MCP protocol.

How Spanly surfaces it

Agentjacking is hard to stop at the model, but it leaves an obvious trace. The signature is a pivot: a read or fetch tool returns external content, and the same session immediately makes an exec, shell, or write call built from it. Untrusted content in, privileged action out, two calls apart.

That sequence is what Spanly records. It captures MCP traffic at the transport layer: every tool call, its arguments, the response, the client, and the session. The read-to-exec pivot is not a metric you build, it is the raw sequence of calls in a session, captured the moment you put Spanly in front of your server. Endpoint and network tools see an ordinary command. A manifest scan sees ordinary tools. The pivot is visible only at the protocol layer.

Some of it shows up before runtime. Spanly’s MCP scanner already flags tool poisoning, deceptive naming, shadowing, embedded secrets, and weak auth. Agentjacking adds one question to ask of any tool: does it relay third-party-writable content as output? A Sentry-style errors tool does, and that is a property of the manifest, not of any single request.

Spanly MCP scan results, with the indirect prompt-injection surface check expanded to show two tools that relay third-party content to the model

A scan of a support-desk MCP server. The prompt-injection surface check flags fetch_issue and get_error, the tools that hand outside content straight to the model.

What to do

There is no single fix. Treat tool output as data and never as instructions, which is a prompt and agent-design problem; Tenet published hardening for Cursor and Claude Code. Scope credentials and gate privileged actions so a successful injection has a small blast radius. And watch the protocol, because some injections will land and the read-to-exec pivot needs to be on record when they do.

Agentjacking is a new name for an old problem: injection, a tool that relays attacker-writable content, and an agent willing to act on it. You cannot filter your way out. Treat every tool’s output as untrusted, and keep a protocol-level record of what your agents do with it.

Keep reading

Tim