Agentjacking: How a Fake Error Report Can Hijack Your AI Coding Agent

If you let Claude Code, Cursor, or OpenAI Codex read your error logs, you should read this before your next session. A new attack disclosed in June 2026 turns one of the most ordinary things a coding agent does, looking at a bug report, into a way for a stranger to run commands on your machine. The researchers at Tenet Security who found it gave it a name that tells you exactly what it does: Agentjacking.

It is not a clever exploit in the usual sense. There is no zero-day, no buffer overflow, nothing you would call hacking in the movie sense. It works because the agent trusts what it reads, and an attacker gets to choose what it reads. That is the whole trick, and that is what makes it hard to fix.

How the attack works, in plain terms

Modern coding agents are often wired up to your error-tracking tool through MCP, the connector standard that lets an agent pull in outside data. Sentry is the common one. The idea is helpful: the agent sees a real error from your app, understands the context, and suggests or applies a fix. Useful, until you ask where those errors come from.

Here is the gap. Sending an event to Sentry only requires a DSN, which is a public, write-only key. It is meant to be public. It sits in your front-end JavaScript and turns up in GitHub searches without anyone trying very hard. Tenet found exposed DSNs at more than 2,388 organisations.

An attacker takes one of those public keys and sends Sentry a fake error report. Not a real crash, a crafted one, with carefully formatted Markdown buried in the error message and context fields. When your agent later fetches recent errors through MCP, it reads the attacker’s fake report alongside the genuine ones and cannot tell the difference. The Markdown is written to look like legitimate debugging guidance, so the agent follows it, the same way it would follow a real instruction in a real log.

In Tenet’s testing, agents read the injected instructions and executed attacker-controlled commands, running with the developer’s own system privileges. The proof of concept had an agent download and run a malicious npm package. That is remote code execution, delivered through a bug report, with the agent as the unwitting courier.

The reach was not theoretical. AI assistants at more than 100 companies, including a Fortune 100 technology firm, ran Tenet’s test code during the research.

Why this is so hard to stop

The uncomfortable part is the response from Sentry. Their product leadership acknowledged the disclosure on June 3, 2026, and then declined to chase a root-cause fix, describing the problem as “technically not defensible” at the platform level.

They have a point, even if it is a cold comfort. Sentry’s open ingestion is working exactly as designed: anyone with the DSN can submit an event, because that is how error tracking is supposed to work from a thousand different clients. The vulnerability is not really in Sentry. It is in the assumption the agent makes, that data arriving from a trusted tool is itself trustworthy. The pipe is fine. The problem is that the agent drinks whatever comes through it.

This is the recurring flaw in the whole agent moment, dressed up in a new outfit. We keep handing agents the ability to act, then connecting them to data sources that anyone can write to, and acting surprised when someone writes to them. An agent that reads is a feature. An agent that reads and then runs commands based on what it read, with your permissions, is an attack surface with a friendly face.

What to actually do about it

You do not need to rip out your tooling. You do need to close the easy doors.

Rotate and lock down your Sentry DSNs. A DSN sitting in public front-end code is the open window here. Treat exposed DSNs as something to find and fix, not as a harmless public key.

Do not let your coding agent run commands unattended on the back of fetched data. If your setup auto-executes what the agent suggests, that is the specific behaviour Agentjacking relies on. Keep a human approving anything that touches the shell, installs a package, or reaches the network, especially when the suggestion traces back to an external feed.

Be deliberate about which MCP connectors your agent trusts, and treat every one of them as a potential input an attacker can reach. The question to ask of any connector is simple: who else can write to this, and what happens if they write something hostile?

If your team is leaning hard into autonomous coding agents, this is the moment to slow down and read the small print, which is a theme. The same instinct that oversells “agentic” everything, covered in the AI buzzword field guide, is the instinct that wires agents to live data feeds and calls it productivity. Agentjacking is the bill for that arriving early.

The honest verdict

Agentjacking is not a flaw in any one product. It is a flaw in a habit: granting agents the power to act while feeding them data from sources strangers control. The fix is mostly old-fashioned discipline. Keep secrets out of public code, keep a human between the agent and the command line, and assume anything your agent reads could have been written by someone who does not have your interests at heart.

The tools are not going to stop reading your logs. The least you can do is decide what happens when one of those logs is lying.

Frequently asked questions

What is Agentjacking?

Agentjacking is an attack class disclosed by Tenet Security in June 2026. Attackers inject malicious instructions into error-tracking data, such as Sentry events, which AI coding agents then read through MCP connectors and act on, executing attacker-controlled commands with the developer’s own system privileges.

Which AI tools are affected by Agentjacking?

Tenet Security’s testing showed AI coding agents including Claude Code, Cursor, and OpenAI Codex retrieving the injected events and failing to distinguish them from legitimate errors. Any coding agent connected to an error-tracking tool via MCP, with the ability to act on what it reads, is potentially exposed.

How does the Sentry injection work?

Sending an event to Sentry only requires a DSN, a public write-only key often found in front-end JavaScript or GitHub. An attacker uses an exposed DSN to submit a fake error report containing crafted Markdown. When an agent fetches recent errors, it reads the attacker’s instructions as if they were real debugging context and follows them.

Did Sentry fix the Agentjacking vulnerability?

Sentry acknowledged the disclosure on June 3, 2026, but declined to pursue a root-cause fix, describing the problem as “technically not defensible” at the platform level. The mitigation falls largely to the teams using AI agents.

How do I protect against Agentjacking?

Rotate and secure your Sentry DSNs so they are not exposed in public code, keep a human approving any agent action that runs commands or installs packages, and limit and audit which MCP connectors your agent trusts. Treat any data source an attacker can write to as untrusted input.