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.

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

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"
    }
  }
}

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 prompts on, and use the /permissions allow-list to whitelist only safe, specific commands rather than blanket approval.
• Cline: leave “auto-approve” unchecked for command execution. Auto-approving read-only file ops is reasonable; auto-approving the terminal is the foot-gun.

Yes, per-command approval is slower. That friction is the entire defense. This is the same principle behind knowing when to trust an AI suggestion at all — the human stays in the loop precisely at the step that can hurt you.

3. Lock down the DSN and scan for leaks

Even with no MCP server, an exposed DSN lets anyone pollute your error data and stage this attack against teammates who do use MCP. Treat the DSN as a thing to manage, not a thing to forget:

# Find DSNs committed to your repo before an attacker does.
git grep -nE 'ingest\.sentry\.io|sentry_key=' $(git rev-list --all) | head
# Also check GitHub code search and Censys for your org's DSN strings.

Rotate any DSN that has appeared in public search, keep DSNs in environment variables rather than hard-coded, add DSN patterns to your pre-commit secret scanning, and — as a backstop — have your network or CASB policy alert on outbound POSTs from AI-agent processes to hosts outside an allow-list. This pairs well with the free local scanners we covered in AI coding security 2026.

A realistic failure I watched for in my own setup

The trap I almost walked into: I had the Sentry MCP server connected in Cursor and “auto-run terminal” enabled, because triaging prod errors and immediately patching them felt like a clean loop. That combination is exactly the exposed quadrant in the table above. The fix took two minutes — flip auto-run to “ask,” and move Sentry triage into a read-only agent profile with no terminal tool. I lost nothing real; the agent still reads errors and proposes fixes, it just can’t silently run a command that arrived inside one.

The general lesson outlives Sentry. The moment any MCP server returns text that originated outside your control — an issue tracker, a web-fetch tool, a shared doc, a CI log — that text can carry instructions. The question to ask of every MCP integration is not “is this source reputable?” but “what’s the worst command my agent could run if this source were hostile, and can it run that command without me?”

How worried should you be?

If you don’t connect error trackers to your agent and you don’t run in auto-execute mode, your exposure to this specific vector is low. If you triage production through MCP and let the agent run commands unattended — the setup a lot of teams adopted precisely because it’s productive — you were in the 85%.

Your setup	Risk today	First move
MCP + auto-run shell	High	Disable auto-run now, then audit MCP servers
MCP, manual approval	Moderate	Sandbox Sentry MCP to read-only; keep approving commands
No MCP, public DSN	Low (but DSN abusable)	Rotate/scope DSN, secret-scan repo
No MCP, no agent shell	Minimal	Stay the course; watch for the next injection class

This is the cost of the agentic convenience we keep buying. Every capability you grant an agent — read my errors, run my shell, reach my network — is also a capability an attacker can borrow if they can get one sentence of text in front of the model. Agentjacking is the proof of concept; the architecture that allowed it is everywhere.

FAQ

Is this a vulnerability in Cursor, Claude Code, or Cline specifically? No. It’s a flaw in the trust model shared by every agent that feeds MCP tool output back to the model as if it were trusted context. The named tools are where it was demonstrated, not the only ones affected.

Did Sentry fix it? Not at the root. Per Tenet’s disclosure, Sentry called the class “technically not defensible” at the platform level and deployed a content filter for specific payload strings. Treat that as partial and bypassable, not a fix.

If my DSN is already public, do I need to rotate it? The DSN is write-only and meant to be public, so rotation doesn’t “fix” exposure on its own — but rotating plus scoping limits who can inject events using your current key, and forces attackers to re-scrape. Combine it with disabling the Sentry MCP server and turning off auto-run.

Does turning off auto-run really stop it? It stops the execution step, which is where the harm is. The injected text can still appear in your agent’s context, but if every shell command needs your approval, you get a chance to reject an unfamiliar command before it runs. That human checkpoint is the single highest-leverage control here.

Is local-only AI coding safer from this? The model running locally vs. in the cloud doesn’t matter — the attack rides MCP data, not the model host. What matters is whether your agent reads externally-influenced data and whether it can run commands unattended. A local model with auto-run on is just as exposed.

Sources

• Agentjacking: a fake bug report can hijack your AI coding agent — Tenet Security
• CSA Research Note: Agentjacking MCP Sentry Injection (June 12, 2026) — Cloud Security Alliance
• Agentjacking Attack Tricks AI Coding Agents Into Running Malicious Code — The Hacker News
• New Agentjacking Attack Hijacks Your AI Coding Agent — Cybersecurity News
• New “Agentjacking” Attacks Could Hijack AI Coding Agents — Infosecurity Magazine
• Agentjacking AI Coding Agent Attack: 2,388 Orgs Exposed — Decryption Digest

Last updated June 17, 2026. Security details and vendor responses change quickly; verify the current state of the Sentry MCP integration and your agent’s permission settings before relying on any mitigation above.