A Fake Error Message Hijacked AI Coding Assistants — and Security Tools Saw Nothing

Key points

• Researchers at Tenet Security tricked AI coding assistants — including Claude Code, Cursor, and OpenAI's Codex — into running attacker-controlled code by planting one fake error report in a public bug-tracking service.
• Tenet found 2,388 organisations with a misconfigured setting that could have made them vulnerable to the same trick.
• The attack, which Tenet calls "agentjacking," bypassed standard identity controls, endpoint security tools, and network monitoring because every action the AI took looked authorised.
• Real-world consequences could have included theft of AWS keys, GitHub tokens, and SSH keys — credentials that open the door to source-code repositories and cloud infrastructure.
• Tenet's CEO says the fix is not a software patch; it requires organisations to monitor what their AI agents are actually doing against what they were asked to do.

Sentry is the name most developers know when something breaks in their software. More than 200,000 organisations — including GitHub, Disney, and Anthropic — use it to collect error reports, crash logs, and performance warnings from their applications. That familiarity is exactly what made it useful bait.

Researchers at Tenet Security crafted a fake error report and slipped it into a Sentry project through a publicly exposed DSN — a Data Source Name, which is a kind of address code that applications use to send diagnostic information to Sentry without needing a password. Many organisations leave these codes openly accessible so that apps running on customers' devices can report problems automatically. Tenet says it found 2,388 organisations that had done exactly that.

How did a fake error report take over an AI agent?

The planted report looked like a normal debugging message. Hidden inside it were instructions written for an AI, not a human. When a developer asked their AI coding assistant to investigate unresolved Sentry issues — a routine task — the assistant fetched the poisoned report via MCP (Model Context Protocol, a standard way for AI tools to pull in data from outside services). The assistant then treated the hidden instructions as legitimate guidance and executed them, running attacker-controlled code directly on the developer's machine.

The core problem is simple and old. AI coding agents cannot reliably tell the difference between data they are reading and commands they are supposed to obey. It is the same class of bug that has plagued web applications for decades — SQL injection, where malicious instructions are smuggled inside what looks like ordinary data — except here the victim is an AI assistant, not a database.

"The agent read it, trusted it, and ran our code with the developer's own access," said Barak Sternberg, CEO of Tenet Security. "Every step was authorised, so identity controls, endpoint detection, and network tools had nothing to flag."

One case in the research involved a company with a market value of $250 billion.

Tenet's research was first reported by Dark Reading.

What should developers and their employers actually do?

Sternberg's near-term advice: disable automatic package-installation scripts, require a human to approve any shell command the AI wants to run, and give AI agents the minimum access they need — nothing more. Over time, organisations need tools that watch an agent's actions in real time and flag when what the agent is doing no longer matches what the user originally asked it to do.

Gene Moody, field CTO at Action1, puts it plainly: treat AI models as untrusted until they have been fully security-tested, not just tested for whether they do their job. Then keep restricting what data they can receive and what actions they can take.

If you use AI-assisted development tools at work, ask your IT team whether those tools can reach external data sources like error-tracking services. If they can, someone should be watching what they fetch.