Agentjacking: Poisoned Sentry Error Reports Hijack AI Coding Assistants

Researchers describe a prompt-injection class that turns developer error-tracking pipelines into a remote code execution path against AI coding agents.

ThreatVectr Newsdesk· 3 min read
Agentjacking: Poisoned Sentry Error Reports Hijack AI Coding Assistants
Share

A new prompt-injection technique, dubbed Agentjacking, can coax AI coding agents into executing attacker-supplied code on developer workstations. The trigger is mundane: a fabricated error report submitted through Sentry, the widely used open-source error-tracking and performance-monitoring platform.

The attack chain is uncomfortably short.

A threat actor crafts a Sentry event whose stack trace, breadcrumbs, or metadata fields contain hidden instructions. When a developer asks their AI coding agent to triage the issue — increasingly common workflow in shops running Cursor, Claude Code, or similar — the agent ingests the poisoned report as context. The embedded instructions then redirect the agent to fetch and run code, modify files, or exfiltrate secrets from the local environment.

No zero-day. No exploit kit. Just text the agent was told to trust.

The researchers behind the disclosure frame Agentjacking as a class of attack rather than a single bug. Any data source an agent treats as authoritative — issue trackers, log aggregators, CI output, customer support tickets — can become an injection surface. Sentry is the demonstration target because it sits directly between production telemetry and developer attention.

The blast radius depends on the agent's permissions. Agents with shell access, repository write rights, or cloud credentials cached in environment variables expand the impact considerably. Agents running in auto-approve or 'YOLO' modes skip the human-in-the-loop check that would otherwise catch obviously malicious tool calls.

This is the part that keeps coming up across agentic AI research: the security model assumes the model can distinguish instructions from data. It cannot, reliably. NIST's guidance on adversarial machine learning flags indirect prompt injection as an unresolved problem, and the OWASP LLM Top 10 lists it as LLM01.

There is no CVE here, because there is no single vulnerable product. That is precisely the awkward bit for defenders.

What developers and security teams should do

  • Treat third-party telemetry (Sentry events, Jira tickets, log lines, webhook payloads) as untrusted input when an AI agent is going to read it. Strip or sandbox free-text fields before they reach the agent's context window.
  • Disable auto-approval for tool calls that touch the shell, the filesystem outside a scoped working directory, or outbound network destinations.
  • Scope agent credentials. Do not let a coding assistant inherit your full AWS or GitHub token. Use short-lived, narrowly scoped credentials per session.
  • Log every tool invocation the agent makes and review them. If an agent reading a bug report suddenly curls an unfamiliar domain, that should page someone.

Regulators have not weighed in on agent-level compromises yet. They will. Until then, the practical posture is to assume any text your agent reads could be an instruction, and design the blast radius accordingly.

© 2026 Threat Vectr