Agentjacking: Poisoned Sentry Error Reports Hijack AI Coding Assistants
Tenet Security researchers describe a prompt-injection class that turns developer error-tracking pipelines into a remote code execution path against AI coding agents.

Key points
- Tenet Security has named a new attack class, Agentjacking, that tricks AI coding agents into running attacker-supplied code on developer machines.
- The trigger is a fake Sentry error report whose free-text fields carry hidden instructions the agent treats as legitimate context.
- No CVE exists because no single product is vulnerable, which makes coordinated patching impossible.
- Blast radius grows with the agent's permissions: shell access, repository write rights, or cached cloud credentials all expand the damage.
- Auto-approve modes remove the human check that would otherwise catch an obviously malicious tool call.
How does the attack actually work?
A threat actor submits a crafted Sentry event whose free-text fields contain hidden instructions. When a developer asks their AI coding agent to triage the issue, the agent ingests the poisoned report as trusted context. Those embedded instructions then redirect it to fetch and execute code, or to exfiltrate secrets from the local environment. No exploit kit required. Just text the agent was told to trust.
Tenet Security frames Agentjacking as a class 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.
Should you worry?
Yes, especially if your team uses auto-approve or so-called YOLO modes that skip human confirmation of tool calls. Those modes remove the one friction point that might catch a malicious shell command before it runs.
This is the part that keeps surfacing across agentic AI research: the security model assumes the agent can distinguish instructions from data. It can't, 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. We've tracked the structural side of this since May, when a paper from Google and two US universities argued that prompt-level defences are inadequate and enterprises should treat the model itself as an untrusted component.
There's no CVE here because there's no single vulnerable product. That's precisely the awkward bit for defenders: nobody owns the fix.
What developers and security teams should do
Treat third-party telemetry as untrusted input when an AI agent will 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 tightly. Don't 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. If an agent reading a bug report suddenly contacts an unfamiliar domain, that should page someone.
Regulators haven't weighed in on agent-level compromises yet. They will. Until then, assume any text your agent reads could be an instruction, and design the blast radius accordingly.



