By A new attack class disclosed yesterday lets anyone with your Sentry project ID take over your AI coding agent — no phishing, no malware, no prior server access. Tenet Security named it agentjacking, achieved an 85% success rate hijacking Claude Code, Cursor, and Codex in controlled tests across 100+ organizations, and found 2,388 companies already exposed. If you use Sentry and an AI coding agent, you are in scope.
How the Attack Works
Sentry Data Source Names — DSNs — are write-only credentials that Sentry explicitly documents as safe to embed in public browser JavaScript. That design decision made sense before AI coding agents existed. It no longer does.
The attack chain is deceptively simple. An attacker finds your Sentry DSN — a five-minute task via GitHub search or your site’s browser console — and POSTs a crafted “error event” to Sentry’s ingest endpoint. No OAuth, no API key beyond the DSN itself. Sentry accepts the payload and stores it identically to a legitimate application error.
The injected event contains a fake “Resolution” section in carefully formatted markdown — visually indistinguishable from Sentry’s own system templates. That section includes a shell command. When you ask your AI coding agent to “fix unresolved Sentry issues,” it queries Sentry via MCP, receives the injected event alongside your real errors, reads the embedded “fix,” and executes it. With your system privileges. As you.
Tenet documented the full chain in six stages, each technically trivial. The total prerequisite: a DSN that appears in public code. That’s it.
Why Every Defense You Have Misses It
Tenet tested the attack against EDR, web application firewalls, IAM controls, and VPN — none caught it. The reason is structural: the agent performed only authorized operations using the developer’s own credentials. There was no policy violation. No anomaly threshold was crossed. The agent did exactly what it was asked to do.
This is the part that makes agentjacking different from a typical exploit. There is no vulnerability in the classic sense. Sentry accepted a valid write. The MCP server returned accurate data. The agent executed an instruction it received from a trusted tool. The attack lives entirely in the logic layer — between what the system is supposed to do and what an attacker can make it do by speaking the system’s own language.
Sentry’s Response: A Content Filter, Not a Fix
Tenet disclosed the issue to Sentry on June 3, 2026. Sentry acknowledged it, called it “technically not defensible,” and pointed to model vendors running middleware. It subsequently deployed a content filter blocking the specific payload string used in the published proof of concept.
That is not a fix. A content filter blocks a known string; a slightly modified payload sidesteps it immediately. The underlying architectural issue — any party with a DSN can inject arbitrary content into a surface that AI agents treat as authoritative — remains open. Sentry passed responsibility upstream. That responsibility now lands on you.
This Is Bigger Than Sentry
Tenet’s finding is not a Sentry bug. It is a threat model failure that applies to every MCP server that surfaces data from external or user-controlled inputs. GitHub Issues MCP, Linear MCP, Jira MCP, PagerDuty MCP, any log aggregation MCP — they all carry the same attack surface. Anyone who can write to those systems can inject instructions into your AI agent’s context.
As Tenet put it: “The flaw is not in Sentry alone — it is in how agents handle any outside data. The same risk runs through support tickets, GitHub issues, and documentation.” The Cloud Security Alliance reached the same conclusion in its research note published the same day.
Expect this to expand. Agentjacking is a class, not a CVE.
What You Should Do Right Now
- Audit and rotate exposed DSNs. Search your public GitHub repositories and browser JavaScript bundles for Sentry DSNs. Rotate any that appear in public-facing code. Use Sentry’s server-side relay to proxy error reporting and keep the DSN off the client entirely.
- Audit your MCP server connections. Identify which MCP servers your coding agents can reach. Flag any that surface data originating from external or user-controlled inputs — Sentry, GitHub Issues, Linear, Jira, log aggregators. That is your attack surface.
- Disable the Sentry MCP integration if you are not actively using it to drive agent workflows. The operational convenience does not offset the risk at this time.
- Require human approval before agent execution. In Claude Code, Cursor, and Codex, enable confirmation prompts for any command sourced from MCP-retrieved content. Force the agent to surface the action and wait for your approval before running it.
- Apply least-privilege to agent environments. Agents should not run with root access, service-role credentials, or admin keys. Create dedicated service accounts with the minimum permissions necessary. When an agent gets hijacked, least privilege determines how much damage the attacker can do.
Sentry declined to fix the root cause. The model vendors are not obligated to catch every variation. The only reliable control point is the one you own: your agent’s runtime configuration and the trust level you grant to MCP-retrieved data.
Treat all external MCP data as untrusted. Verify before you execute.
