Agentjacking: A Fake Bug Report Can Now Hijack Your AI Coding Agent

This is the AI security story of the week, and it’s one every team running coding agents needs to understand. In mid-June, researchers at Tenet Security disclosed a new class of attack they’re calling "agentjacking" — and it turns your AI coding assistant against you using nothing more than a fake bug report (The Hacker News).

Let me explain it in plain English, because the mechanics matter.

How the attack works

Most engineering teams use an error-tracking tool like Sentry. When something breaks, the error lands there, and increasingly a developer just asks an AI agent to go investigate it. The agent pulls the error details — often through a Model Context Protocol (MCP) connection — reads them, and suggests or runs a fix.

Here’s the trap. An attacker sends a crafted error event into Sentry using a publicly accessible Data Source Name, and buries malicious commands inside that error (Tenet Security). When the agent reads the error, it can’t tell the difference between the real diagnostic data and the attacker’s planted instructions. It treats the payload as its own remediation guidance and executes it — as if the idea came from the agent itself (The Hacker News).

No breach. No stolen credentials. The attacker just speaks the agent’s language and the agent obeys.

The numbers are not reassuring

In Tenet’s controlled testing, the technique worked roughly 85% of the time across the major coding agents (Infosecurity Magazine). That’s not a fragile proof-of-concept. That’s a near-reliable exploit.

And the exposure is wide. Using only public Sentry APIs — breaching nothing — Tenet found 2,388 organizations exposed, with confirmed agent execution at companies ranging from Fortune 100 giants down to independent solo developers (The Hacker News). One writeup framed it bluntly: a single fake bug report hijacked a $250-billion company’s AI agent (Tenet Security).

This is the same root problem the security world has been circling all year. The agent can’t separate trusted instructions from untrusted data when both arrive as text (The Next Web). Give an agent the power to run commands, then feed it attacker-controlled input, and you’ve handed over the keys.

What this means for you — independent operators and SMBs

I know the temptation. You’re a one-person shop or a small team, you’ve wired up an AI agent to investigate your errors, and it feels like magic. It is. But this is a real reminder that an agent with the ability to execute code on your machine is a loaded tool.

You don’t need a security team to lower your risk today. Three things. First, don’t let your coding agent auto-run commands without a human approving the action — that confirmation step is the whole ballgame. Second, treat any tool that pulls in outside data, error trackers included, as a potential injection path. Third, lock down your Sentry DSNs and don’t leave them publicly exposed.

The visible-friction approach is the safe one. I’ve said before that I actually prefer agents that ask before doing something sensitive, even when it slows me down. This is exactly why.

What this means for you — enterprise IT

If your developers are running coding agents with MCP connections — and many are, whether you’ve blessed it or not — this belongs in your threat model now, not next quarter.

Practical steps. Inventory which agents your teams use and what tools those agents can reach. Assume any agent that ingests third-party data can be fed a malicious payload, and put a human approval gate in front of command execution. Rotate and scope your Sentry DSNs, and review who can write events into your projects. And get ahead of the shadow-AI problem: developers adopt these tools faster than policy can keep up, so the answer is safe defaults, not a memo telling people to stop.

The CISO community already logged this in its mid-June breach reporting, so it’s on the radar at the right level (Infosecurity Magazine). Your job is to make sure it’s on yours.

My take

This doesn’t make me want to abandon agents. It makes me want to use them the way I’ve argued for all along — with the guardrails turned on and the human in the loop for anything that touches a command line.

The pattern here is the defining security challenge of the agent era. We keep giving these systems more autonomy and more connections, and every new connection is a new way for untrusted text to become trusted action. The labs and the security vendors will patch specific holes like this one. But the underlying lesson doesn’t expire: an agent is only as safe as the boundary between what it reads and what it’s allowed to do.

Use the tools. Keep the gate. Don’t let convenience talk you into auto-executing whatever shows up in your error log.

News commentary by Brad Rowland — IT Infrastructure and Operations leader, automation builder, and AI implementer. Sources are linked inline.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top