All posts
Unproven Execution

Agentjacking: Sentry MCP as an Unproven Execution Path

Tenet Security showed a public Sentry DSN can plant fake errors that hijack Claude Code, Cursor, and Codex through the Sentry MCP server

Securityv0 Intelligence Team OWASP: ASI05 sv0 finding: unproven_execution
agentjacking sentry mcp prompt-injection ai-coding-agents unproven-execution

The Incident

On June 12, 2026, Tenet Security publicly disclosed agentjacking, a class of attack in which an unauthenticated stranger uses a target’s public Sentry DSN to POST a fake error event whose message and context fields carry markdown-formatted prompt-injection payloads. When a developer subsequently asks an AI coding agent — Claude Code, Cursor, or Codex — wired to the Sentry MCP server to triage open issues, the agent renders the planted event as trusted system output and runs the attacker’s commands on the developer’s workstation. Tenet identified 2,388 organizations with injectable DSNs, 71 of them in the Tranco top one million, and reported an 85% exploitation rate against the three tested agents. Confirmed victim categories include a Fortune 500 whose parent capitalization exceeds $250 billion and a hosting provider valued above $2 billion.

No CVE has been assigned: the issue is a design-level interaction between Sentry’s intentionally public DSN and the Sentry MCP server’s pass-through rendering, not a single vulnerable build. Tenet disclosed to Sentry on June 3, 2026; Sentry acknowledged the same day, called platform-layer defense “technically not defensible,” and shipped a global content filter against the specific proof-of-concept payload string while deferring root remediation to model vendors. The accessible blast radius on a developer workstation includes environment variables, AWS keys, GitHub tokens, git credentials, and private repository URLs — the secrets the agent would naturally have to read while pretending to fix a bug.

MITRE ATT&CK coverage: T1059 (Command and Scripting Interpreter), T1552 (Unsecured Credentials), T1078 (Valid Accounts).

The Authority Path That Failed

The identity carrying execution authority at the moment of failure was the developer’s local shell session, exercised by the AI coding agent acting on the developer’s behalf. That identity held the full developer scope: ability to read environment variables, fetch credentials from ~/.aws, read GitHub tokens from the git credential helper, and execute arbitrary shell commands. What the developer intended the agent to exercise was a much narrower slice: read a Sentry issue, propose a fix, hand back a diff. The agent silently widened its exercised scope to “run whatever an anonymous POST embedded in a Sentry event message” because the MCP tool channel was treated as privileged, server-supplied context rather than as untrusted user input.

The trust anchor that failed first was the composition itself. The Sentry DSN is publicly embedded in frontend JavaScript by design — Sentry treats authentication at ingestion as architecturally infeasible. The Sentry MCP server then re-emits attacker-controlled event fields into the agent’s tool-output channel without provenance labeling. The deploying operator — the developer — never authored, signed off on, or even named the path “Sentry tool channel → Bash tool” as a permitted composition. Sentry’s own quote concedes that platform-side defense is not on offer, which leaves exactly one place where the gate can live: the agent’s runtime authority record. If that record never proved the Sentry-MCP-to-shell hop, the hop was unproven the moment the agent started.

SecurityV0 Perspective

This is a textbook unproven_execution finding (ASI05). An AI coding agent whose tool manifest includes both an MCP data tool with a write-public input domain and an OS-level execution tool has, by composition, attached a code-execution path that was never explicitly authorized by the deploying operator. The OWASP ASI05 pattern is “framework/agent executes code or attaches a code-execution tool that was never explicitly authorized” — the Sentry-MCP-plus-shell pairing is that pattern at the agent-configuration layer rather than at the framework default-flag layer of the Langflow CSV Agent precedent.

The evidence pack SecurityV0 would produce names the agent identity, the resolved tool manifest at startup (Sentry MCP server, Bash/exec tool, file-read tool), the provenance level of each tool’s input domain (Sentry: write-public, no authentication at ingestion), and the absence of an operator-signed authorization for the composition. Pre-incident, that pack answers: “did the operator ever prove this agent was allowed to act on Sentry tool output as if it were code-execution input?” Post-incident, the same pack scopes the forensic question: which agent sessions ran against which DSN, what commands were issued, and which secrets on disk were within reach at the moment of each session. The 2,388-org number is the scale signal; the Tenet quote from Sentry — “technically not defensible” — is the wedge that puts the burden squarely on the agent’s runtime composition record, where SecurityV0 lives.

What To Do

  • Inventory every agent that wires the Sentry MCP server next to a shell, exec, or file-write tool. Treat that pairing as an unproven execution path until the operator has signed off on it specifically. For Claude Code, Cursor, and Codex, review the active MCP server list per workspace and disable Sentry until a sanitization layer is in place.
  • Strip or quote markdown and tool-call grammar in MCP outputs before they reach the agent. Configure your MCP gateway or proxy to escape backticks, fenced code blocks, and instruction-like phrasing from third-party data sources, and label every field with its provenance level so the agent has a defensible reason to refuse the content.
  • Rotate any DSN that has ever been embedded in frontend JavaScript before the MCP gateway is in place. Treat published DSNs as compromised input channels; rotate them under a project-scoped key with rate limits, and consider IP allowlisting on the Sentry ingestion endpoint where Sentry supports it.
  • Tighten the developer-workstation blast radius before the agent reads a single Sentry event. Move AWS credentials behind aws sso login short-lived sessions instead of ~/.aws/credentials, store GitHub tokens in the system keychain rather than the plaintext git credential helper, and unset env vars that the agent does not need for the current task before launching it.
  • Capture and retain agent tool-call traces for every Sentry-MCP-enabled session. At minimum, log the MCP request, the raw MCP response, the agent’s chain-of-thought decision to call a tool, and the executed command — kept long enough to support an incident review, so a future “did the agent run something it should not have” question has a deterministic answer.

Sources

All posts