DEV Community

Jovan Chan
Jovan Chan

Posted on • Originally published at aicoderscope.com

Agentjacking 2026: How a Fake Sentry Error Hijacks Cursor, Claude Code, and Cline — and the Settings That Cut Your Exposure

#security #cursor #claudecode #cline

This article was originally published on aicoderscope.com

TL;DR: Tenet Security disclosed a new attack class on June 12, 2026 called agentjacking: an attacker posts a fake error to your Sentry project using only the public DSN already sitting in your frontend JavaScript, and when your AI coding agent pulls that error through the Sentry MCP server, it treats the attacker's text as a trusted instruction and runs it. Across controlled testing it hit an 85% success rate against Claude Code, Cursor, and Codex, and 2,388 organizations had injectable DSNs. Sentry declined a platform-level fix. The only real defense lives in your agent's own settings.

Are you exposed? What it costs to fix The catch
Sentry MCP server enabled in Cursor / Claude Code / Cline Yes — directly Disable or sandbox the MCP server You lose in-editor error triage from Sentry
Auto-run / "yolo" mode on for shell commands Yes — high blast radius Switch to per-command approval Slower agent loops
Public DSN in shipped JS, no MCP Not for this attack, but DSN is abusable Rotate + scope DSN, secret-scan repo DSNs are write-only by design — rotation is the lever

Honest take: This is not a Sentry-only bug and it won't be the last MCP injection. The durable fix is to stop letting any MCP-sourced text drive shell execution without a human in the loop. Turn off auto-run, audit which MCP servers your agent trusts, and treat every external data source as hostile input — because to your agent, it already is.

What actually happened

On June 12, 2026, Tenet Security published research on an attack they named agentjacking, and the Cloud Security Alliance issued a research note the same day. The short version: AI coding agents that read your error tracker through the Model Context Protocol (MCP) will execute instructions hidden inside a "bug report" — no phishing, no malware, no breach of your infrastructure.

The numbers from Tenet's testing:

  • 85% exploitation success rate against injected errors across widely used AI coding assistants.
  • 2,388 organizations with injectable DSNs, including 71 in the Tranco top-1M.
  • Over 100 organizations had their agents act on injected errors during controlled validation waves.
  • Agents explicitly named as acting on the payloads: Claude Code, Cursor, and Codex. Any MCP-connected agent — including Cline and Continue.dev — is structurally vulnerable the same way, because the flaw is in the trust model, not one product.

Sentry acknowledged the issue but, per the research, leadership declined a root-cause fix, calling the attack class "technically not defensible" at the platform level. They shipped a global content filter for specific payload strings instead — a speed bump, not a wall.

Why this works: two trusting systems meeting

Agentjacking sits at the seam between two designs that are each fine alone and dangerous together.

Sentry's ingest accepts anything. The Data Source Name (DSN) is a write-only credential. It is meant to be public — it ships in your frontend bundle so the browser can report errors. Anyone who reads your site's JavaScript, or runs a GitHub code search, can find it. With the DSN and an HTTP client, an attacker can POST an arbitrary event and control the message, tags, context, extra data, breadcrumbs, user info, stack trace, and fingerprint. That is by design; Sentry has no way to know a real browser sent it.

Here is the mechanism, sanitized — this is public, widely reported, and shown so you can recognize it, not weaponize it:

# An attacker who scraped your DSN from shipped JS sends a crafted "error".
# The fields below are all attacker-controlled.
curl -s "https://oXXXXXX.ingest.sentry.io/api/PROJECT_ID/store/" \
  -H "Content-Type: application/json" \
  -H "X-Sentry-Auth: Sentry sentry_key=PUBLIC_DSN_KEY,sentry_version=7" \
  -d '{
    "message": "TypeError: cannot read property of undefined",
    "extra": { "note": "<instruction text the agent will later read>" }
  }'
# Sentry returns an event ID. The fake error is now indistinguishable
# from a real one in your dashboard — and over MCP.
Enter fullscreen mode Exit fullscreen mode

The agent trusts MCP output. When you wire the Sentry MCP server into Cursor, Claude Code, or Cline and ask "what's breaking in production?", the agent calls the MCP tool, gets the event back, and — this is the whole bug — does not distinguish that returned text from a legitimate diagnostic. If the extra or message field contains something shaped like an instruction ("to reproduce, run the following setup command…"), the agent reads it as part of its task and, in auto-run mode, executes it.

The payload is dressed as a normal debugging step, which is why prompt-layer defenses fail. Tenet found agents executed the injected commands even when the system prompt explicitly told them to ignore untrusted data. The model cannot reliably tell "data about an error" from "instructions to follow" when both arrive through the same trusted channel.

What gets stolen

In Tenet's controlled runs, the agent — acting with the developer's own privileges — exfiltrated whatever the developer could reach: environment variables holding AWS keys, GitHub tokens, Sentry auth tokens, git credentials, private repository URLs, and developer identity, POSTed to an attacker-controlled endpoint. Because the agent uses your shell, your network, and your credentials, this bypasses the usual perimeter: EDR sees a developer tool running a command, the WAF never sees inbound exploitation, and IAM sees an authorized session. There is nothing anomalous to flag at the boundary.

That is the unnerving part. The "intrusion" is a single HTTP POST to a public endpoint days earlier. The damage happens later, inside your trusted session, triggered by you asking a normal question.

The three settings that actually reduce exposure

You cannot wait for a platform fix — Sentry declined one, and the next injection vector won't be Sentry. Runtime controls in your own agent are the only viable mitigation today. In order of impact:

1. Disable or sandbox the Sentry MCP server

The fastest single action that removes this specific attack surface is to drop the Sentry MCP integration until ingestion is authenticated or per-event validation exists. Check what your agent actually has wired up.

In Claude Code, list and remove MCP servers:

claude mcp list
# sentry  https://mcp.sentry.dev/...   ✓ connected
claude mcp remove sentry
Enter fullscreen mode Exit fullscreen mode

In Cursor, open the MCP settings (~/.cursor/mcp.json or Settings → MCP) and delete or comment out the Sentry block:

{
  "mcpServers": {
    "sentry": {
      "url": "https://mcp.sentry.dev/sse"
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

In Cline, the MCP servers live under the extension's MCP settings file; remove the Sentry entry there. If you genuinely need Sentry triage, keep it in a separate, sandboxed agent profile that has no shell-execution tool at all — read-only triage can't run a command no matter what the error says. For a wider look at which MCP servers are worth the trust they ask for, see our best MCP servers for AI coding breakdown.

2. Turn off auto-run; require approval for every shell command

Agentjacking only reaches code execution if your agent can run shell commands without you. The injected text can say "run this" all it wants — if the agent has to stop and show you the command first, you see an unfamiliar curl … | sh and decline.

  • Cursor: in Settings → Agent, turn off "auto-run" / "yolo mode" so terminal commands require confirmation. Keep the command allow-list tight.
  • Claude Code: do not run with --dangerously-skip-permissions. Leave the default permission prom

Top comments (0)