Agentjacking: A Single Public Sentry Key Is All It Takes to Hijack Claude Code, Cursor, and Codex. Datadog, PagerDuty, and Jira Have the Same Exposure.

On June 12, 2026, Tenet Security’s Threat Labs published research that should make every developer who runs an AI coding agent with MCP integrations stop and audit their tool connections immediately. They discovered a novel attack class called “agentjacking” — injecting malicious instructions through trusted diagnostic tools to hijack AI coding agents into executing arbitrary code on developer machines.

The attack requires exactly one ingredient: a public Sentry DSN. That’s the key you can find in any website’s source code. No stolen credentials. No phishing. No zero-day. Just a write-only identifier that Sentry publishes in client-side JavaScript and that attackers can extract with a single curl command. [Tenet]

Cloud Security Alliance’s AI Safety Initiative classified agentjacking as a “novel attack class” the same day the research dropped. VentureBeat reported that Datadog, PagerDuty, and Jira have the same exposure. The scope test is brutally simple: if your AI coding agents connect to any MCP data source your developers trust — and those agents can execute shell commands — your stack has the same blind spot.

And this story got four points on HN. Four. For an attack class that compromises 85% of tested agent configurations across 2,388 organizations.

The Architecture Problem

The attack exploits a structural mismatch between two systems that were never designed to interact with each other.

System 1: Sentry’s event ingestion. Sentry accepts error events from anyone with the DSN. The DSN is public by design — it’s embedded in client-side JavaScript so the browser can report frontend errors. Anyone who views your website’s source code has your DSN. Anyone with your DSN can POST arbitrary error payloads to your Sentry project. This is not a bug. It’s the architecture.

System 2: The Sentry MCP server. Model Context Protocol servers are the bridge between AI agents and external tools. The Sentry MCP server queries your Sentry project and returns error data to the agent. The agent treats this data as trusted system output — diagnostic information from the production monitoring pipeline.

The problem: System 1 accepts untrusted input. System 2 returns that input as trusted output. The agent, caught in the middle, executes whatever instructions arrive through the diagnostic channel.

The Attack Chain

Ron Bobrov, the Tenet researcher who discovered agentjacking, described the attack in four steps:

1. Find the DSN. Search GitHub for sentry.io in public repositories, inspect any web app’s source code, or use passive reconnaissance. Tenet found 2,388 organizations with injectable DSNs through passive scanning alone. 71 of those organizations rank in the Tranco top-1M list of busiest websites.

2. Inject the error. Send a POST request to Sentry’s event ingestion endpoint with a crafted error payload. The payload contains attacker-controlled instructions disguised as error diagnostics — stack traces, breadcrumb data, exception messages that include shell commands. Any HTTP client works. curl works. No authentication beyond the DSN.

3. Wait for the agent. When the developer asks their AI coding agent to investigate a production issue — “hey Claude, check if we have any new Sentry errors in the auth service” — the agent queries the Sentry MCP server. The MCP server returns the injected error. The agent sees it as legitimate diagnostic output.

4. Execute. The agent follows the instructions embedded in the error data. It runs the attacker’s shell commands. It ships AWS keys to an attacker-controlled server. It installs persistence. The developer watches the agent work, seeing only a normal diagnostic workflow.

Tenet tested this against Claude Code, Cursor, and Codex in controlled environments across more than 100 consenting organizations. The success rate: 85%. The 15% failure cases were agents that asked for confirmation before running unfamiliar commands — not a security feature, just a configuration coincidence. The agent still received and processed the injected instructions. It just showed them to the developer first.

The Scope: It’s Not Just Sentry

Here’s the part that makes agentjacking a category rather than a bug.

Sentry is the first MCP server to be exploited this way, but the attack pattern generalizes to any MCP-connected data source that accepts external input. VentureBeat’s analysis identified the same exposure in:

• Datadog MCP server — accepts metrics and log data from any configured source
• PagerDuty MCP server — accepts incident data from monitoring integrations
• Jira MCP server — accepts issue data from any user with project access
• GitHub MCP server — accepts issue comments, pull request descriptions, and commit messages from anyone with repo access (Noma Security’s GitLost showed that private repos aren’t safe either)

The pattern is consistent: any MCP server that connects an AI agent to a system with externally-submitted data creates an injection channel. The agent trusts the MCP server. The MCP server trusts the data source. The data source accepts external input. The trust chain breaks at the first link.

Cloud Security Alliance’s research note explicitly connects agentjacking to a broader class of attacks: “the use of legitimate, authorized integration channels to deliver adversarial instructions to AI coding agents.” They reference Elastic Security Labs’ work on self-replicating AI worms that propagate through the same mechanism — trusted channels carrying untrusted payloads.

Why Automated Scanners Can’t Catch This

This is the part that matters for anyone evaluating AI agent security tools.

Automated vulnerability scanners look for known patterns: hardcoded secrets, missing input validation, SQL injection vectors, IDOR endpoints. Agentjacking doesn’t match any existing vulnerability signature because:

1. The Sentry DSN is supposed to be public. It’s not a leaked secret. It’s a public credential by design. No scanner will flag it.

2. The MCP server is operating correctly. It returns the data that exists in Sentry. It’s not executing anything. The execution happens in the agent’s reasoning loop, not in the MCP server’s code.

3. The agent’s behavior looks legitimate. Running diagnostic commands based on error data is exactly what the agent is supposed to do. No anomaly detection will flag it — the agent isn’t behaving anomalously. It’s behaving exactly as designed, on data that arrived through a legitimate channel.

4. The trust boundary is architectural, not technical. The vulnerability isn’t in any single component. It’s in the relationship between components — the assumption that data arriving through a diagnostic tool is safe because the diagnostic tool is trusted. This is a category of vulnerability that automated tools structurally cannot detect because they analyze components in isolation.

This is the same pattern we’ve documented across every major AI agent security incident in July 2026: Friendly Fire exploited the trust between coding agents in auto-review workflows. GhostApproval exploited the trust between the agent’s file system operations and its confirmation dialogs. Pentera’s Claude Desktop C2 exploited the trust between the Personal Preferences sync mechanism and the MCP command execution tool. Agentjacking exploits the trust between the observability platform and the agent’s diagnostic workflow.

In every case, the attack works because the agent trusts something it shouldn’t. And in every case, automated scanners see nothing wrong because each individual component is operating within its specification.

What Organizations Should Do

If you run AI coding agents with MCP integrations, here’s the immediate checklist:

1. Audit your MCP server connections. List every MCP server your agents connect to. For each one, ask: can an external attacker submit data to this system? If the answer is yes — and for Sentry, Datadog, PagerDuty, Jira, GitHub, Slack, and virtually every other developer tool, it is — that channel is a potential injection vector. [CSA]

2. Rotate your Sentry DSN. Tenet Security disclosed to Sentry on June 3, 2026. Sentry has updated their MCP server to add input sanitization. But the fundamental architecture hasn’t changed — the DSN is still public, and error data still flows from external sources to the agent’s context window. Rotating your DSN removes any existing attacker’s access to your project, but it doesn’t prevent new injection.

3. Install agent-jackstop. Tenet released an open-source MCP proxy that sits between your agent and its MCP servers, sanitizing diagnostic data before it reaches the agent’s context window. It strips executable instructions from error payloads while preserving diagnostic information.

4. Minimize your MCP server list. Disconnect any MCP server your agents don’t actively use. Every connected MCP server is a potential injection channel. If your agents don’t need to query Sentry errors, they shouldn’t have the Sentry MCP server installed.

5. Run agents with minimal permissions. The 15% of agentjacking attempts that failed did so because the agent asked for confirmation before running unfamiliar commands. This isn’t a security feature — it’s a side effect of restricted agent permissions. Configure your agents to require explicit confirmation for shell commands, network requests, and file system modifications.

6. Get an architectural audit. The agentjacking attack class — like Friendly Fire, GhostApproval, and Pentera’s C2 — exploits trust boundaries between components, not bugs in individual components. Automated scanners will not catch these vulnerabilities. You need someone who understands the full architecture to identify where your agents trust data they shouldn’t.

The Bigger Picture

Agentjacking is not a Sentry bug. It’s not an MCP protocol flaw. It’s not an AI agent hallucination.

It’s a category error. We connected AI agents — systems designed to act on information they receive as truth — to data sources that accept untrusted external input. We did this without asking whether the agents should trust the data. We did this because MCP servers make it trivially easy to connect agents to any tool, and we connected agents to everything without understanding the trust implications.

The Sentry MCP server is the first to be exploited, but it won’t be the last. The same architectural pattern exists in every developer tool that accepts external data and exposes it to AI agents through MCP. The attack surface is the entire MCP ecosystem.

And the fix isn’t technical — it’s architectural. You can’t patch a trust boundary. You have to redesign the system to not trust data that arrives from untrusted sources. You have to verify before you execute. You have to audit the connections.

That’s what we do at dotfm. We audit the architecture, not just the code. We find the trust boundaries that automated scanners can’t see. We tell you what your agents trust that they shouldn’t, and how to fix it before someone else finds it first.

---

Need an architectural audit of your AI agent infrastructure? Get in touch.