📰 AI News: Researchers Found a Way to Hijack AI Coding Agents Through a Normal-Looking Error Report 📰

📝 TL;DR 📝

Security firm Tenet has disclosed a new attack method called "Agentjacking" that tricks AI coding agents like Claude Code and Cursor into executing malicious code on a developer's machine, with an 85% success rate across more than 100 organizations tested. The attack requires no direct access to the developer's machine and hides inside a fake Sentry error report. For anyone using agentic coding tools on real projects, the practical defenses are simple and worth knowing now.

🧠 Overview 🧠

As AI coding agents get more capable and more autonomous, they also become a more attractive target. Agentjacking is a new demonstration of that reality: it is not a bug in Claude Code or Cursor specifically, it is an exploit of a structural pattern that applies to any AI agent that reads external data and has permission to run shell commands. The more autonomous access you give an agent, the more important it becomes to understand what it trusts and what it can do with that trust.

This is an awareness and safety story, not a tool to try. The value here is understanding the attack chain so you can check your own setup and apply the practical defenses before you run into this in the wild.

📜 The Announcement 📜

Tenet Security published a report disclosing the attack, which they call Agentjacking, as a variant of a known technique called indirect prompt injection. The core idea is not new: if you can get attacker-controlled text into the context window of an AI agent that has permission to execute commands, you can make the agent execute your commands. What is new is the specific delivery mechanism, and how cleanly it works in practice.

Tenet tested the attack against more than 100 organizations and found an 85% success rate. Scanning public repositories, they also identified 2,388 organizations with Sentry DSNs exposed in ways that make them exploitable using this technique. Sentry has since shipped a content filter as a partial mitigation, and Tenet released a detection tool called Agent-JackStop for security teams.

⚙️ How It Works ⚙️

The attack chain has four steps, each of which relies on normal, trusted behavior:

Step 1 - The attacker finds a public Sentry DSN. This is a credential commonly embedded directly in frontend JavaScript because Sentry treats it as write-only and public by design. It allows applications to submit error events to a project's ingest endpoint.

Step 2 - The attacker uses that DSN to send a fake error event to the Sentry project. They control the message field, stack trace, tags, and context, and they format the fake event to look like a legitimate diagnostic report, complete with headings, code blocks, and a "resolution" section containing a malicious command.

Step 3 - A developer asks their AI coding agent to investigate unresolved Sentry issues. The agent retrieves error reports through Sentry's MCP server as part of a normal debugging workflow.

Step 4 - The agent reads the fake error, treats it as trusted diagnostic guidance because it arrived through a legitimate MCP data source, and executes the attacker's command with the developer's local permissions. In Tenet's proof of concept, the command used a public npm registry package to scan the developer's environment for credentials, cloud configuration files, Git tokens, and information about private repositories.

The key reason this works is that the agent cannot distinguish attacker-controlled content from legitimate content once it arrives through a trusted channel. Sentry's MCP server did nothing wrong. The coding agent did what it was designed to do. The vulnerability is that agents implicitly trust the data they retrieve as if it were safe instructions.

💡 Why This Matters 💡

This generalizes beyond Sentry - The underlying pattern applies to any MCP data source that can be written to or poisoned by an external party. Sentry is a well-known example, but the same logic applies to any tool that feeds external, user-influenced data into an agent's context.

The attack requires no direct access and no social engineering - The attacker never contacts the developer, never touches their machine, and does not need to compromise Sentry. Everything flows through normal tooling behavior.

This is the predictable consequence of increasing agent autonomy - Every additional permission you grant an agent, every MCP server you connect, and every auto-approval you enable expands the attack surface. This is not a reason to stop using agents, but it is a reason to be deliberate about what they can do.

Sentry's content filter is a partial fix, not a full one - The root issue is structural, agents implicitly trusting external data as instructions. A content filter reduces the risk on one specific vector, but the underlying trust problem remains.

🏢 What This Means for Businesses 🏢

Turn off blanket auto-approve for shell commands right now - If your coding agent has permission to run terminal commands without prompting you, change that setting today. In Claude Code and Cursor, requiring explicit human approval for command execution is the single most impactful defense available.

Scope what your agent can touch before pointing it at a real repo - Do not run a coding agent with your full set of cloud credentials, Git tokens, and environment variables in scope unless the task specifically requires it. The more a compromised agent can see, the more damage it can do.

Rotate any Sentry DSNs that may be exposed in public repositories - If you have a Sentry DSN embedded in frontend JavaScript or committed to a public repo, rotate it. While DSNs are designed to be write-only, an exposed DSN is exactly what enables this attack.

Read what your agent is about to do before approving it - Especially when an agent is investigating an external data source like error logs, reading the proposed command before approving it is the practical last line of defense.

This is the "great power, great responsibility" moment for agentic coding - The same autonomy that makes tools like Claude Code useful for large tasks is what makes this attack possible. Treating agent permissions as a security configuration, not just a convenience setting, is the right frame going forward.

🔚 The Bottom Line 🔚

Agentjacking is a good demonstration of a pattern that will keep reappearing as AI agents become more capable and more widely used: the more an agent can do autonomously, the more valuable it becomes as a target for anyone who can influence what it reads. The specific vector here is Sentry, but the structural vulnerability is every MCP server, every external data source, every tool that feeds attacker-influenceable content into an agent's context.

The defenses are not complicated. Require human approval for shell commands, scope your agent's access to only what it needs, and read what it is about to do before approving it. None of those require deep security knowledge, they just require treating your coding agent's permissions with the same care you would apply to any other tool that can touch your credentials and execute code on your machine.

Security researchers covering this story are largely framing it the same way: this was inevitable, and MCP trust boundaries are the new attack surface to watch. Getting ahead of it now, before it becomes a widely exploited technique rather than a disclosed proof of concept, is the right moment to audit your own setup.

💬 Your Take 💬

Have you checked what permissions your coding agent has to run commands on your machine? Is auto-approve currently on or off in your setup? 🤔

2 comments

📰 AI News: Researchers Found a Way to Hijack AI Coding Agents Through a Normal-Looking Error Report 📰