How a Public Sentry Key Can Hijack AI Coding Agents Like Claude Code and Cursor
A single, publicly exposed Sentry key can turn trusted AI coding agents—such as Claude Code, Cursor, and Codex—into unwitting conduits for attacker code execution on developer machines. On June 17, 2024, Tenet Security Threat Labs published details of the “agentjacking” attack: no malware, no credential theft, just a forged error report and a protocol blind spot. For developers and security teams running AI-assisted coding tools, this isn’t just an edge-case bug. It’s a new kind of supply chain risk at the exact layer where code hits the editor. This post breaks down the attack, why it works, its impact, and how to lock down your workflow.
What is the "agentjacking" attack using a public Sentry key?
Agentjacking is an attack, disclosed by Tenet Security Threat Labs on June 17, 2024, that uses a single fake Sentry error report to hijack AI coding agent workflows. Here’s the mechanism: a routine “unresolved error” remediation request is slipped into Sentry—using only a public DSN (Data Source Name)—and an AI agent, such as Claude Code or Cursor, treats this poisonous data as authoritative guidance. The agent reads details of the error report not as passive telemetry, but as new instructions of what to do next. The attacker simply has to submit a well-formed, malicious error event; from there, the error-monitoring system becomes a command and control interface.
This is not malware, and it doesn’t rely on traditional social engineering or password theft. The attack is subtle, operating in the open through standard telemetry channels. The analogy: imagine a contractor who trusts any note in the work-order system is valid—a forged ticket triggers action every bit as readily as a genuine one. In practice, any AI coding agent wired to fetch unresolved Sentry issues is vulnerable. As documented by Tenet, this includes Claude Code, Cursor, and Codex (as of the disclosure date). The underlying vector is the Sentry DSN, a credential meant to be embedded in frontend JS, which is inherently discoverable and grants write access to error feeds. Anyone in possession of this key can submit arbitrary errors, and the agent will treat them as high-trust input.
Takeaway: Agentjacking doesn’t break in through a backdoor. It piggybacks on trusted error feeds, using a design assumption that agents will not treat error data as executable intent.
Why can AI coding agents not distinguish data from instructions?
The root problem: AI coding agents are wired to act on anything authenticated and well-formed, regardless of whether it’s inert telemetry or payload. This vulnerability isn’t about an obscure serialization quirk or exotic prompt injection—it’s an effect of the Model Context Protocol (MCP) and how it connects agents to external services for guidance.
MCP is the protocol standard that bridges AI agents and services like Sentry. When a developer asks an AI agent to “fix unresolved errors,” the agent queries external tools, and processes whatever data returns, assuming it holds actionable context for the next code-change step. Under conventional (human) review, a bug report is only ever advice, requiring interpretation. But AI agents don’t distinguish—the structure or semantics of the record offer no safety guarantee. The agent cannot differentiate between harmless stack traces and attacker-planted instructions because, to the protocol, both look like “context.”
Compounding this: Sentry DSNs are explicitly documented as safe to embed in public JS, since they’re write-only and designed to enable error reporting from any client device. While that assumption held when humans read Sentry feeds, it fails when agents blindly automate away the human check.
In code:
// pseudo-example
const unresolved = await querySentryUnresolved(DSN)
for (const issue of unresolved) {
agent.act(issue) // the original sin—no input validation
}
No verification, no input filtering, and no audit as to provenance.
Takeaway: The separation between “data” and “instruction” is a human distinction—MCP removes it. Agentjacking exploits this ambiguity at the AI interface.
How does agentjacking exploit the Model Context Protocol (MCP)?
The Model Context Protocol (MCP) is the engine room behind the scenes: it defines how coding agents ingest and act on context from a constellation of tools and error-monitoring feeds. In the modern pipeline, MCP channels data like error histories or project metrics directly into the agent’s working memory and action loop.
For agentjacking, the attacker’s path is clear. They discover a public Sentry DSN—visible in frontend JavaScript, scrapeable from public source, or found via code search tools like GitHub or Censys—and inject a malicious error payload. MCP then ensures all unresolved Sentry errors (genuine and forged) are surfaced as tasks to the AI agent. By design, agents treat these items as instructions for next-step fixes. The attacker doesn’t need additional access: just the DSN and the knowledge that MCP acts as an ingest conveyor-belt into the agent’s engine.
Attack flow (summarized):
- Public Sentry DSN is harvested from app JS or codebase.
- Attacker submits a crafted error event to Sentry.
- MCP fetches unresolved events from Sentry.
- AI agent (Claude Code, Cursor, Codex) ingests the payload as “context.”
- Attack payload is executed as a real code-change command on the developer’s machine.
The risk isn’t theoretical—the Tenet Security Threat Labs report demonstrates real attacks across multiple agent products, all connected by the same MCP flow.
[[DIAGRAM: Sentry DSN exposed via frontend JS → attacker submits malicious error report → MCP fetches issues → agent receives poisoned context → agent executes attacker code on developer machine]]
Takeaway: MCP, when fed context from external tools without validation, becomes a high-bandwidth channel for attackers—turning by-the-book monitoring into an unintentional code execution pipeline.
What are the real-world implications for developers and enterprises?
For any team running AI coding agents, the attack surface is wider than it looks. Through agentjacking, an attacker can run their code directly on a developer’s machine by injecting a single error report via a public Sentry DSN. It’s not just a denial-of-service or nuisance bug—this is silent, first-party code execution, with no malware dropped and no stolen credentials.
Given Sentry’s adoption—“thousands of teams” integrate it, per The New Stack’s coverage—the scale potential is disturbing. If Sentry DSNs are left exposed, any motivated attacker with basic knowledge of the flow can turn error monitoring into a supply chain risk. The avenue is cheap, silent, and well within reach: find a DSN, submit a payload, and let the agent do the rest.
What’s at risk:
- Developer machines become remote-controlled via trusted error reports
- No alerts if no traditional malware or credential exfiltration occurs
- Productivity grinds to a halt as agents act on weaponized bugs
- Proprietary code and intellectual property can be subverted without notice
For enterprises, the threat isn’t contained to a single dev box—it’s a toolchain-level risk spreading through every agent-assisted workflow and developer who connects to the poisoned Sentry instance.
Takeaway: The security boundary is now at the error-monitoring feed. Agentjacking is a new class of supply chain compromise—one that bypasses all the signature-based defenses.
How can developers detect and mitigate Sentry key hijacking attacks today?
Mitigation starts where the design assumption failed. Sentry DSNs must be treated as semi-sensitive, not casually exposed, and should never be assumed safe simply because “they’re write-only.” Here are actionable steps for teams:
1. Audit all public Sentry DSNs:
- Search your public JavaScript, open GitHub code, and app templates for hardcoded DSNs.
- Move from public exposure where possible—prefer environment-variable injection during build or deploy steps.
- Rotate DSNs when exposure is found.
2. Monitor Sentry for anomalous error submissions:
- Set up alerts: large spikes in error events, unusual time-of-day activity, or unfamiliar user agents posting error telemetry.
- Flag and review any error records that reference suspicious commands or patterns.
- Block or quarantine error events that appear to instruct direct code/action steps.
3. Harden agent input validation:
- Instrument AI coding agents (or proxies) to sanitize and validate Sentry (and other MCP-fed) issue content before treating as executable instructions.
- Implement allow-lists or basic taint tracking to block syntactically suspicious data from ever reaching the action loop.
- Where possible, run agent-initiated tasks in sandboxes or with reduced privileges, so accidental execution does not cover the full attack surface.
4. Watch for vendor patches:
- Monitor agent tool release notes for security advisories or new MCP validation features. The affected vendors (Claude Code, Cursor, Codex) are likely to release explicit hardening soon following the Tenet disclosure.
In code:
Block action when you cannot validate a Sentry event’s provenance:
const ALLOWLISTED_ORIGINS = ["myteam.sentry.io"]
function validate(event) {
return ALLOWLISTED_ORIGINS.includes(event.origin)
}
for (const issue of unresolved) {
if (validate(issue)) {
agent.act(issue)
} else {
// log for manual review
}
}
5. Reference Tenet Security Threat Labs for detailed technical guidance:
Review the official Tenet Security Threat Labs publication for ongoing updates and sample mitigation code.
Takeaway: The days of “public DSN is safe by design” are over—security review needs to move up the stack, and error data must be regarded as a potential attack surface.
Closing: the agentjacking era demands vigilance at the data edge
A single exposed Sentry key, used as prescribed, now enables a new class of attacks against AI coding agents via agentjacking. The central lesson: error telemetry is no longer “just data” once machines act directly on its contents. Developers and security teams must reclassify the trust boundaries around error feeds, question the safety of “write-only” credentials, and deploy real validation and monitoring at every AI-agent interface. As AI development accelerates, so do the attack vectors—understanding, detecting, and defending against agentjacking is table stakes for securing the modern coding pipeline. Don’t wait for the first forged error to hit your queue.
Top comments (0)