Skip to content
AI Security Wire

Published

- 6 min read

By

Agentjacking: How Poisoned Sentry Events Hijack AI Coding Agents

img of Agentjacking: How Poisoned Sentry Events Hijack AI Coding Agents

A single POST request to a public API endpoint. No credentials stolen, no servers breached, no phishing email. That’s the setup for Agentjacking, a class of attack demonstrated by Tenet Security’s Threat Labs on June 17, 2026. In controlled testing against more than 100 organisations, the attack achieved an 85% exploitation success rate, turning AI coding agents into unwitting executors of arbitrary attacker code.

The underlying flaw is something the security community has discussed in theory for a while: AI agents connected to external services via the Model Context Protocol have no mechanism to distinguish legitimate data from attacker-injected data. Tenet’s research demonstrates what that looks like at operational scale against real production environments.

The Architecture of the Attack

Sentry is an error-tracking and performance-monitoring platform used across tens of thousands of organisations. Its Data Source Name (DSN) is a connection string embedded in application JavaScript, by design. Sentry documents it as safe to expose publicly because it is write-only: any endpoint can send error events to your Sentry account using your DSN, but the DSN cannot be used to read data back.

That write-only access is sufficient for this attack.

When an AI coding agent like Claude Code or Cursor is connected to Sentry via the Sentry MCP server, it can query Sentry for unresolved error events. This is a legitimate and useful workflow: a developer asks their agent to review and triage outstanding Sentry issues, and the agent reads the events, reasons about root causes, and proposes or executes fixes.

The attack injects a crafted event into that read path. An attacker who finds a target’s DSN (from JavaScript source, Censys, or GitHub code search) sends a POST request to Sentry’s ingest endpoint with a malicious payload in the event fields. The event body contains carefully formatted markdown in message fields and context key names. When the Sentry MCP server returns this event to the AI agent, it renders as structured content that is visually indistinguishable from a legitimate Sentry resolution template.

The agent reads the injected content as authoritative system guidance and executes whatever commands it contains.

What Gets Executed and What Gets Stolen

The injected command runs with the developer’s full local privileges. Tenet’s demonstrations show extraction of:

  • Environment variables, including AWS access keys, GitHub tokens, and Sentry authentication tokens sitting in the developer’s shell environment
  • Git credentials and private repository URLs from ~/.gitconfig and the local repository’s remote configuration
  • Developer identity information

The exfiltration happens silently. The agent completes what it believes is a legitimate error remediation task. No alert fires because the agent is an authorised user, the Sentry query is a legitimate MCP call, and the commands executed are issued by the developer’s own process with the developer’s own credentials.

Tenet’s phrasing is precise: “The attacker never touches the victim’s infrastructure. The malicious instruction arrives disguised as a legitimate ‘Resolution’ inside an ordinary error.”

Scale and Affected Platforms

Tenet found at least 2,388 organisations with valid, injectable Sentry DSNs accessible through standard discovery methods. Their controlled testing covered more than 100 organisations. The 85% success rate applies to injected errors actually being acted upon by AI agents when developers prompted them to resolve Sentry issues.

Affected AI coding tools confirmed in the research include Claude Code, Cursor, and OpenAI’s Codex. Tenet notes that sandboxed agents, internal-network agents, and agents with live AWS keys in scope all fell for the attack across macOS, Windows, and cloud environments. The attack bypasses EDR, WAF, IAM policies, VPNs, Cloudflare, and standard firewalls because every action in the chain is authenticated and authorised by design. There is no anomalous binary, no malformed network packet, no suspicious process launch to detect.

Sentry’s Position

Sentry has acknowledged the research and described the issue as “technically not defensible” at the platform level. Their reasoning: the DSN is intended to be public and writable; restricting that would break Sentry’s core frontend error-reporting architecture. As a partial mitigation, Sentry activated a global content filter that blocks a specific payload string from the Tenet proof-of-concept. That filter addresses the exact payload demonstrated publicly but does not prevent payload variation.

The practical implication for defenders: platform-level remediation is unlikely. Sentry’s current posture is that the responsibility for safe AI agent behaviour rests with the agent’s configuration and the developer’s operational practices, not Sentry’s event ingestion model.

Why This Matters Beyond Sentry

Agentjacking is not a Sentry-specific vulnerability. The root cause is the absence of a trust boundary between data plane and instruction plane in MCP-connected agents. The Sentry DSN is just an accessible entry point to demonstrate the class.

Any external service that an AI agent queries via MCP, and that accepts writes from partially-trusted or public sources, is a potential injection vector: issue trackers, log aggregation platforms, customer support systems, internal wikis accessible to broad audiences, public GitHub repositories. If an AI agent reads that data and can execute code or file operations, the data source is now part of the agent’s attack surface.

The NSA’s guidance on MCP security, published in May 2026, highlighted tool output poisoning as a priority risk category. Agentjacking is that category in production.

Defensive Guidance

Restrict what your AI agent can do after reading external telemetry. Claude Code and Cursor support configuration files that constrain tool use. Tenet released an open-source tool, agent-jackstop, that provides hardened drop-in configuration files for both agents, limiting automatic execution of commands sourced from MCP tool responses without explicit developer confirmation.

Treat MCP-connected external services as untrusted input. The mental model that should govern AI agent configuration: any data that arrives via an MCP tool response may be attacker-controlled. This is the same model that governs input validation in web applications. Agent workflows that execute code based on tool response content without a human confirmation step are equivalent to a web application that passes user input directly to eval().

Audit your Sentry DSN exposure. If your DSN is in frontend JavaScript, it is discoverable. Check whether your Sentry integration is configured to allow MCP access from your AI coding agents. If it is, consider whether that integration provides enough value to justify the attack surface, or whether a human-in-the-loop review of Sentry issues before agent action is warranted.

Monitor agent execution logs for unexpected behaviour. When a developer asks an AI agent to fix Sentry errors, review what commands the agent actually proposed or ran. Legitimate Sentry error resolution does not typically require POSTing to external endpoints, reading credential files, or making outbound connections to non-application servers.

The Tenet research and agent-jackstop configuration files are available at their published blog post. The research represents the most concrete public demonstration to date of indirect prompt injection converting to code execution in a real, production-scale attack scenario.

References

Frequently Asked Questions

What is Agentjacking?
Agentjacking is an attack class identified by Tenet Security's Threat Labs in June 2026. It exploits the implicit trust AI coding agents place in MCP tool responses. By injecting a crafted error event into a target organisation's Sentry error-tracking account — using the account's public Data Source Name (DSN) — attackers can cause an AI agent to execute arbitrary code on a developer's machine when the developer asks the agent to fix unresolved Sentry issues.
Does this attack require the attacker to compromise Sentry or the target's servers?
No. The Sentry DSN is a write-only credential that Sentry intentionally documents as safe to embed in frontend JavaScript source code. Any attacker who finds the DSN — by inspecting page source, running a Censys search, or querying GitHub — can inject events into the target's Sentry account without any authentication beyond that single public credential. The attacker never touches the victim's infrastructure.
What does Sentry's response to the vulnerability mean for security teams?
Sentry has acknowledged the issue but described it as 'technically not defensible' at the platform level, since the DSN is by design a public, writable credential. Sentry added a global content filter that blocks a specific known payload string. That filter is bypassable with payload variation. The defensive burden falls on agent runtime configuration and developer workflow practices rather than platform-side remediation.