Public Sentry key enables hijacking of AI coding agents through fake error reports

A single, publicly exposed Sentry key can turn trusted AI coding agents into unwitting conduits for attacker code execution on developer machines. No malware, no credential theft — just a forged error report and a protocol blind spot. The attack, dubbed "agentjacking" in The New Stack's coverage of the disclosure, targets agents like Claude Code, Cursor, and Codex through the error feeds they are wired to trust. For developers and security teams running AI-assisted coding tools, this is 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, and how to lock down your workflow.

What is the "agentjacking" attack using a public Sentry key?

Agentjacking uses a single fake Sentry error report to hijack AI coding agent workflows. The mechanism: a routine "unresolved error" remediation request is slipped into Sentry — using only a public DSN (Data Source Name) — and an AI agent treats this poisoned data as authoritative guidance. The agent reads the error report not as passive telemetry, but as new instructions for what to do next. The attacker simply submits a well-formed, malicious error event; from there, the error-monitoring system becomes a command-and-control interface.

This is not malware, and it does not rely on traditional social engineering or password theft. The attack operates in the open through standard telemetry channels. The analogy: imagine a contractor who trusts any note in the work-order system — 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 a candidate target. The underlying vector is the Sentry DSN: Sentry's own docs note that DSNs only allow submission of new events, which is why they are routinely embedded in public frontend code — but that same write access lets anyone submit arbitrary errors, which the agent then treats as high-trust input. Sentry acknowledges the abuse risk and offers IP blocking plus DSN rotation as controls.

Takeaway: Agentjacking does not break in through a backdoor. It piggybacks on trusted error feeds, exploiting the 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 is inert telemetry or payload. This is an effect of the Model Context Protocol (MCP) and how it connects agents to external services for guidance.

MCP is the protocol standard bridging AI agents and services like Sentry. When a developer asks an 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 agents do not distinguish — the structure of the record offers 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 documented as safe to embed in public JavaScript since they are write-only. That assumption held when humans read Sentry feeds. It fails when agents automate away the human check — a hardening gap that belongs on every AI app security checklist.

In code:

// pseudo-example of the vulnerable pattern
const unresolved = await querySentryUnresolved(DSN)
for (const issue of unresolved) {
  agent.act(issue) // the original sin — no input validation
}

No verification, no input filtering, no provenance audit.

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 defines how coding agents ingest and act on context from tools and error-monitoring feeds. In the modern pipeline, MCP channels error histories and project metrics directly into the agent's working memory and action loop.

The attacker's path: harvest a public Sentry DSN — visible in frontend JavaScript, scrapeable from public source, or found via code search — and inject a malicious error payload. MCP then surfaces all unresolved Sentry errors, genuine and forged alike, as tasks to the AI agent. By design, agents treat these items as instructions for next-step fixes. The attacker needs nothing more: just the DSN and the knowledge that MCP acts as an ingest conveyor belt into the agent's engine.

Attack flow (summarized):

1. Public Sentry DSN is harvested from app JavaScript or codebase.
2. Attacker submits a crafted error event to Sentry.
3. MCP fetches unresolved events from Sentry.
4. The AI agent ingests the payload as "context."
5. Attack payload is executed as a real code-change command on the developer's 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. An attacker can run code on a developer's machine by injecting a single error report via a public Sentry DSN. It is not a denial-of-service or nuisance bug — it is silent, first-party code execution, with no malware dropped and no stolen credentials.

What is at risk:

• Developer machines become remote-controlled via trusted error reports.
• No alerts fire if no traditional malware or credential exfiltration occurs.
• Productivity halts as agents act on weaponized bugs.
• Proprietary code and intellectual property can be subverted without notice.

For enterprises, the threat is not contained to a single dev box — it is a toolchain-level risk spreading through every agent-assisted workflow connected to the poisoned Sentry instance. If your team runs Claude Code against production telemetry, read the Claude Code security primer alongside this post.

Takeaway: The security boundary is now at the error-monitoring feed. Agentjacking is a new class of supply chain compromise — one that bypasses signature-based defenses.

How can developers detect and mitigate Sentry key hijacking today?

1. Audit all public Sentry DSNs:

• Search public JavaScript, open GitHub code, and app templates for hardcoded DSNs.
• Prefer environment-variable injection during build or deploy steps.
• Rotate DSNs when exposure is found — Sentry supports rotation and revocation.

2. Monitor Sentry for anomalous error submissions:

• Alert on large spikes in error events, unusual time-of-day activity, or unfamiliar user agents posting telemetry.
• Flag any error records referencing suspicious commands or patterns.
• Quarantine error events that appear to instruct direct code or action steps.

3. Harden agent input validation:

• Sanitize and validate Sentry (and other MCP-fed) issue content before treating it as executable instructions.
• Implement allow-lists or basic taint tracking to block suspicious data from reaching the action loop.
• Run agent-initiated tasks in sandboxes or with reduced privileges where possible.

In code — block action when you cannot validate an 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
  }
}

4. Watch for vendor patches:

• Monitor agent tool release notes for security advisories or new MCP validation features.
• Pair this with a production-grade Sentry error-tracking setup so your telemetry pipeline itself follows hardened conventions.

Takeaway: The days of "public DSN is safe by design" are over — error data must be regarded as a potential attack surface.

Closing: vigilance at the data edge

A single exposed Sentry key, used as prescribed, enables a new class of attacks against AI coding agents. The central lesson: error telemetry is no longer "just data" once machines act directly on its contents. 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. Do not wait for the first forged error to hit your queue.

Ship on telemetry you can trust: OTF kits come with production-hardened observability conventions your agent can follow from day one. Browse the kits →

Sources

• The New Stack: "A public Sentry key is all it takes to hijack Claude Code, Cursor, and Codex" — verified live coverage of the agentjacking disclosure; the mechanism and affected-agent claims above rest on this report.
• Sentry docs: Data Source Name (DSN) — DSNs are public-embeddable and write-only; abuse risk acknowledged; rotation and IP-blocking controls.
• OTF kit templates — production kits referenced in the CTA.