What Is Agentjacking?

In June 2026, researchers at Tenet Security disclosed a new attack class they called agentjacking — and it’s the most practical AI agent supply chain attack I’ve seen in production. The premise is deceptively simple: an attacker injects a malicious error event into your Sentry project, and when your AI coding agent (Claude Code, Cursor, or OpenAI Codex CLI) reads that event via the Sentry MCP server, it executes the attacker’s embedded payload with your system privileges.

No phishing. No malware. No prior server access. Just one HTTP POST request and a publicly visible Sentry DSN.

The numbers are sobering: Tenet Security reported an 85% exploitation success rate across all three major coding agents, tested against 100+ consenting organizations. They identified 2,388 organizations with publicly exposed Sentry DSNs — the only prerequisite for the attack. And here’s the part that keeps me up at night: 0% detection by EDR, WAF, firewall, VPN, or IAM in tested environments.

How Agentjacking Works: The 6-Step Attack Chain

Let me walk through the exact mechanics, because understanding the chain is the only way to defend against it.

Step 1: DSN Discovery

Sentry DSNs look like this:

https://abc123def456@o123456.ingest.sentry.io/4507890123

They’re documented as safe to embed in public browser JavaScript — a design decision that predates AI agents by years. Attackers find them through:

  • GitHub code search — DSNs in public repos, often in .env.example files or frontend configs
  • Browser JS source maps — embedded in minified bundles shipped to production
  • Shodan / Censys — scanning for Sentry ingest endpoints with known patterns

Tenet Security found 2,388 organizations with exposed DSNs. Of those, 71 were in the Tranco top-1M — major production sites.

Step 2: Crafting the Fake Error Event

The attacker creates a Sentry error event that looks legitimate but contains a malicious payload in the event description. The key trick: the event uses markdown formatting with a ## Resolution section that includes a shell command disguised as a fix instruction.

Here’s what the injected event body looks like conceptually:

E#Rnr#uprnxoRret@:shaoetUltnufahtocailknolednorlw/eisdnegnRtecrjoyem-cmhtaointodfnitx—o-pTaaypcppkelaEygrertohre:hCoatnfnioxt:readpropertiesofundefined

The npx command fetches and executes an attacker-controlled npm package. That package contains the exfiltration logic.

Step 3: Injection via Single HTTP POST

The attacker sends the crafted event to Sentry’s public ingest endpoint using the exposed DSN. Sentry accepts it — the DSN is write-only by design, and Sentry has no mechanism to verify the authenticity of submitted events. The event appears in the project’s error dashboard alongside legitimate errors.

Step 4: Developer Triggers the Agent

This is the human factor that makes the attack work. A developer opens their Sentry dashboard, sees a new error, and tells their AI coding agent:

“Fix the Sentry errors”

Or they paste the error into Claude Code / Cursor / Codex CLI and ask for a fix. This is normal developer behavior — we do this dozens of times a day.

Step 5: MCP Hands Payload to Agent as Trusted Context

The agent queries the Sentry MCP server for error details. The MCP server returns the attacker’s crafted event — markdown, ## Resolution section, and all. The agent treats this as trusted context because it came from an authorized MCP tool.

This is the critical architectural flaw: MCP servers are trust boundaries, but nobody treats them as such. The MCP protocol provides no mechanism for data provenance, content integrity, or instruction separation. The agent has no way to distinguish “this is error data” from “this is an instruction to execute.”

Step 6: Agent Executes Attacker’s Code

The agent reads the ## Resolution section, interprets it as a fix instruction, and runs the npx command. The attacker’s npm package executes with the agent’s full system privileges.

In 85% of test cases, the agent ran the command without asking for confirmation. The 15% failure rate wasn’t a security control — it was agents asking “are you sure you want to run this?” before the developer said yes and the payload executed anyway.

What Gets Stolen

Once the payload runs, it exfiltrates everything the agent has access to — which is everything the developer has access to:

  • AWS credentials — ~/.aws/config and ~/.aws/credentials
  • GitHub tokens — ~/.config/gh/hosts.yml, environment variables
  • Docker credentials — ~/.docker/config.json
  • SSH keys — ~/.ssh/id_rsa and authorized keys
  • npm tokens — ~/.npmrc
  • Environment variables — database URLs, API keys, secrets
  • Git credentials — stored in the local git config

The exfiltration happens over HTTPS to an attacker-controlled endpoint. No EDR flags it because it’s just curl or wget sending data — the same tools developers use legitimately all day.

Why Traditional Security Fails: The Authorized Intent Chain

This is the most unsettling part. Tenet Security calls it the Authorized Intent Chain:

  1. Developer authorized the agent → authorized
  2. Agent authorized the MCP server → authorized
  3. MCP server returned data from Sentry → authorized
  4. Agent executed a command based on that data → authorized

Every link in the chain is authorized. There’s nothing for EDR, WAF, IAM, or VPN to flag. The attack lives entirely in the logic layer — between what the system is supposed to do and what the attacker can make it do.

System prompt instructions to “distrust external data” don’t help. Researchers tested this explicitly — agents still executed the payload 85% of the time. The agent’s training and design prioritize being helpful over being cautious, and the MCP protocol gives it no tools to distinguish data from instructions.

Sentry’s Response: “Technically Not Defensible”

Sentry acknowledged the disclosure on June 3, 2026. Their response was honest and controversial: they declined root-cause remediation, calling it “technically not defensible” at the Sentry level. They deployed a content filter that blocks only the specific PoC payload string from the disclosure — a narrow band-aid that doesn’t address the class of attack.

I understand their position. Sentry’s ingest endpoint is designed to accept arbitrary data from any client. That’s the whole point of error reporting. Adding content validation would break legitimate use cases where error messages contain code snippets, stack traces, or commands. The vulnerability isn’t in Sentry — it’s in the trust model between MCP servers and AI agents.

But passing responsibility upstream to model vendors without a coordinated fix means thousands of teams remain exposed.

Beyond Sentry: The MCP Trust Problem

Agentjacking isn’t a Sentry bug. It’s an MCP ecosystem vulnerability. The same attack vector applies to any MCP server that surfaces external, attacker-controllable data:

  • Datadog — inject fake monitor alerts with embedded commands
  • PagerDuty — craft incident descriptions with malicious payloads
  • Jira / GitHub Issues / Linear — file a ticket with markdown containing shell commands

Elastic Security Labs found that 43% of MCP implementations in their sample contained command injection flaws. 30% of MCP servers permitted unrestricted URL fetching. The MCP protocol itself lacks:

  • Data provenance — no way to trace where data originated
  • Content integrity — no mechanism to verify data hasn’t been tampered with
  • Instruction separation — no distinction between “data about an error” and “instructions for fixing it”

This is a class of vulnerability, not a single CVE. We’re going to see variants of agentjacking for years.

Defense Guide: Practical Mitigations

Here’s what I’ve found actually works in production, ordered by impact:

1. Audit and Rotate Exposed DSNs

Run a scan across your GitHub orgs for exposed Sentry DSNs. The pattern is straightforward:

# Search for Sentry DSNs in your repos
grep -r "ingest\.sentry\.io" --include="*.{js,ts,jsx,tsx,env,json,yaml,yml}" .

For any exposed DSN, rotate it in the Sentry dashboard immediately. Add DSN patterns to your pre-commit hooks and secret scanning tools.

2. Disable Sentry MCP or Require Human Approval

This is the single most effective mitigation. If you don’t need Sentry MCP, disable it. If you do need it, configure your agent to require human approval before executing any command sourced from MCP data.

In Claude Code, you can set --approval-mode to require confirmation. In Cursor, disable automatic MCP tool execution in settings. For Codex CLI, review the MCP configuration and remove the Sentry server.

3. Apply Least-Privilege to Agent Environments

Run your AI coding agents in sandboxed environments with limited permissions. This is where tools like Cloudflare Temporary Accounts (60-minute sandboxed sessions, announced the same week as the disclosure) and containerized development environments make sense.

The principle: your agent should never have direct access to production AWS keys or SSH credentials. If the agent needs to deploy, it should go through a CI/CD pipeline with its own access controls.

4. Server-Side Sentry Relay

Instead of letting agents connect directly to Sentry’s ingest endpoint, route through a server-side relay that strips markdown and command-like content from error descriptions before passing them to the MCP server. This breaks the injection chain at the network boundary.

5. Pre-Commit Secret Scanning

Add Sentry DSN patterns to your pre-commit hooks and CI pipeline:

# .pre-commit-config.yaml
- repo: https://github.com/your-org/detect-secrets
  rev: v1.5.0
  hooks:
    - id: detect-secrets
      args: ['--pattern', 'ingest\.sentry\.io']

6. Monitor for Agentjacking Indicators

Watch for unexpected npx executions, unusual outbound HTTPS connections from developer machines, and Sentry events with suspicious ## Resolution sections. Agent Beacon (an open-source telemetry tool that emerged alongside the disclosure) can help detect anomalous agent behavior.

The Bigger Picture

Agentjacking is the first major demonstration of a problem I’ve been worried about since MCP was introduced: we’re connecting AI agents to external data sources without any trust boundary between them. The MCP protocol treats all data from a tool as equally trustworthy, and the agent treats all MCP-sourced data as context for action.

This isn’t fixable with a single patch. It requires:

  • Protocol-level changes to MCP for data provenance and instruction separation
  • Agent-level changes to treat MCP-sourced commands as untrusted by default
  • Organizational changes to audit and restrict what agents can access

For related reading on AI agent supply chain risks, check out my Agent Skills Supply Chain Security Guide and the PraisonAI Cross-Origin Agent Execution Vulnerability analysis. For a broader look at agent identity and access control, the AI Agent Identity Framework guide covers production patterns for zero-trust agent environments.

Bottom Line

Agentjacking works because it exploits the gap between what developers think their agents are doing and what agents actually do. Every link in the chain is authorized — that’s the whole point. The fix isn’t a better firewall or a smarter EDR. It’s treating MCP servers as untrusted data sources, sandboxing agent environments, and requiring human approval for any command sourced from external data.

Check your DSNs today. Disable Sentry MCP if you don’t absolutely need it. And start thinking about agent security as a trust boundary problem, not a malware problem — because the next variant of this attack won’t use Sentry at all.