Your AI Coding Agent Reads Untrusted Input All Day. In 2026, Attackers Started Writing To It.

An Attack That Needs Nothing But a URL

Most security findings in the agentic AI space describe misconfiguration — an agent granted too much access, a credential left in a prompt, an unsandboxed tool. Agentjacking is more interesting than that, because there is nothing misconfigured about the systems it exploits.

Researchers at Tenet Security disclosed it on June 3, 2026, with the Cloud Security Alliance publishing a research note on June 15. The mechanism is almost trivially simple. Sentry's error ingestion is designed to be open — that's the point, since client applications need to report errors without holding privileged credentials. An attacker finds a publicly discoverable Sentry Data Source Name, crafts an error event whose contents are injected instructions, and POSTs it to the ingest endpoint. Nothing is compromised. An error report was submitted, which is what the endpoint exists for.

The payload activates later, and it activates because a developer does something entirely reasonable: they ask their AI coding agent to look into recent Sentry issues. The agent retrieves the poisoned event through MCP, reads the injected instructions inside what it understands to be diagnostic data, and carries them out as though they were legitimate remediation steps. According to the disclosure, an attacker needs 'only a publicly discoverable Sentry DSN and an HTTP client' — no credential theft, no phishing, no server compromise.

The numbers are what elevate this from clever to alarming. An 85% code-execution success rate across Claude Code, Cursor, and Codex. 2,388 organizations identified with exposed, injectable DSNs. Controlled testing confirming that agents at more than 100 organizations executed attacker payloads. Exfiltrated material including environment variables, AWS credentials, GitHub tokens, Kubernetes secrets, CI/CD tokens, and registry credentials. No CVE was assigned, deliberately — the researchers framed it as a systemic architectural vulnerability class rather than a discrete bug anyone could patch.

This Is Not the Over-Privileged Agent Problem

It's worth being precise about why this differs from the agent identity and permissions issues that have dominated agentic security discussion, because the mitigations are almost entirely different.

The over-privilege problem is a provisioning failure. An agent holds broader access than its task requires, so when something goes wrong the blast radius is larger than it needed to be. The fix is familiar IAM discipline: scope credentials tightly, issue them short-lived, audit what non-human principals can reach, apply least privilege to machine identities the way you already do to human ones.

Agentjacking is not that. The agent has exactly the access a developer investigating a production error would need. It performs exactly the actions it was designed to perform. The failure is that it cannot distinguish between data it was asked to analyse and instructions it was asked to follow, because both arrive as text in the same context window. Least privilege reduces the damage but does not prevent the attack — an agent scoped perfectly to 'investigate Sentry issues and propose fixes' is still fully exploitable, because reading the hostile input is the legitimate task.

This is the confused deputy problem, arriving in a form the software industry has not built defences for. Every hardening measure that assumes a boundary between code and data is weakened when the executing component treats all input as potentially instructional. Reducing agent permissions is necessary and insufficient — and organizations that have done that work and consider agent security addressed are the ones most likely to be surprised.

SANDWORM_MODE and the Dependency Vector

Agentjacking poisons what an agent reads at runtime. Four months earlier, a campaign demonstrated the complementary approach: poison the agent's own tooling at install time.

The Socket Research Team disclosed SANDWORM_MODE on February 20, 2026 — a self-propagating npm worm distributed through at least 19 malicious packages under two publisher aliases, official334 and javaorg. The packages typosquatted widely used developer utilities, crypto libraries, and AI coding tools, including look-alikes of supports-color, Claude Code, and OpenClaw. The distribution channel was ordinary npm typosquatting; the payload was not.

On installation, the malware registered a rogue Model Context Protocol server targeting Claude Code, Cursor, Continue, and Windsurf, then relied on prompt injection through that server to exfiltrate SSH keys, AWS credentials, npm tokens, and environment secrets across both developer machines and CI environments. Reporting on the campaign described a multi-stage design: a second stage decrypting an AES-256-GCM-protected module bundle exporting five components — Propagate, Exfil, DeadSwitch, McpInject, and GitHooks — performing deep harvesting that reached into password managers and local SQLite databases.

The architectural lesson is that an AI coding agent's dependency tree is now security-critical infrastructure in a way a linter's dependency tree never was. A malicious package that can write to your agent's MCP configuration gains an instruction channel into a process that holds repository access, cloud credentials, and the developer's trust. The packages have been removed from npm following coordinated disclosure, but the pattern is established and the incentive is obvious: the agent is a higher-value target than the developer.

Tool Poisoning Is Not a Fringe Weakness

A reasonable objection to both findings is that they are proof-of-concept research against unusually careless setups. Benchmark data argues otherwise.

The MCPTox benchmark evaluated 45 live MCP servers and 353 authentic tools against poisoned tool descriptions across a range of contemporary language models. Many popular agents showed attack success rates above 60%, with the highest reaching 72%. These are not results against toy configurations — they are against real servers and genuine tools, with the attack carried in the tool description metadata that agents necessarily read in order to know what a tool does.

Discrete vulnerabilities are appearing in the surrounding tooling too. CVE-2026-23744 gave attackers remote code execution on MCPJam Inspector at CVSS 9.8. Palo Alto's Unit 42 has separately documented attack vectors through MCP sampling, where the protocol's own capability for a server to request model completions becomes an injection channel.

Taken together, these describe an ecosystem in a familiar phase: rapid capability growth, broad adoption driven by genuine usefulness, and a security model still being retrofitted. That is not an argument against using MCP or coding agents — the productivity gains are real and the direction of travel is set. It is an argument for treating the current generation of agent tooling with the operational caution you would apply to any young, fast-moving, highly privileged component.

Configuration Files as a Beachhead

One detail from the 2026 attack chains deserves separate attention, because it changes the incident response calculus. Documented attacks quietly edited agent configuration — writing to files like the user's Claude settings to register a malicious MCP server and to loosen permission rules — so that the compromise persisted across every subsequent session.

This is a well-chosen target. Agent configuration files are rarely under version control, rarely monitored for integrity, and rarely reviewed after initial setup. They are, functionally, startup scripts for a highly privileged process, and they enjoy none of the scrutiny a CI pipeline definition or a production deployment manifest would receive. A single write grants durable, silent influence over every future agent session on that machine.

The response implication is uncomfortable: if you suspect a developer workstation has been touched by one of these campaigns, rotating credentials is not sufficient. Agent configuration must be treated as a persistence location and audited explicitly, the way you would examine shell profiles, cron entries, or git hooks after an intrusion. Most organizations' incident response playbooks do not yet have a line item for it, which is precisely what makes it effective.

What Actually Reduces the Blast Radius

There is no single control that resolves prompt injection, and vendors claiming otherwise should be treated sceptically. What exists is a set of measures that meaningfully reduce exposure, most of them unglamorous.

Treat MCP servers as an allowlist, not an ecosystem to explore. Every server an agent can reach is an instruction channel; the set should be small, deliberately chosen, pinned to specific versions, and reviewed when it changes. Put agent configuration files under version control or integrity monitoring so that unauthorised registration of a new server is a detectable event rather than an invisible one.

Remove ambient credentials from the environments agents run in. A great deal of the harm in both campaigns came from harvesting environment variables and credential files that happened to be present — cloud keys, GitHub tokens, registry credentials, Kubernetes secrets. Agents that operate with short-lived, narrowly scoped credentials obtained on demand lose most of their value as an exfiltration target. Control egress from developer and CI environments, since exfiltration requires a network path and arbitrary outbound access is rarely a genuine requirement.

Keep a human reviewing agent-proposed changes with actual attention, particularly changes to dependency manifests, CI configuration, and anything that touches credentials or network configuration. And name the assumption explicitly in your threat model: any data an agent ingests — error reports, issue trackers, logs, pull request comments, web pages, tool descriptions — is attacker-controllable, and should be treated with the same suspicion as user input in a web application.

The Governance Gap in Outsourced Development

These findings land awkwardly on any organization whose code is written on machines it does not manage. The relevant questions are suddenly quite specific, and most outsourcing arrangements have no answers to them.

Whose laptop is your repository cloned onto? Which AI coding agents are running against it, and who chose them? Which MCP servers are registered in those agents' configurations, and who reviewed that list? Which npm registry do those machines install from, and is there any dependency scanning in that path? If a contractor's workstation were compromised by a campaign like SANDWORM_MODE, would anyone know, and would you be told? When a subcontractor's engineer rotates off the project, what credentials did their agent hold, and were those rotated?

For project-based outsourcing and large body-shop arrangements, these questions frequently cannot be answered at all. Work is distributed across engineers the client never meets, on machines the client cannot inspect, with tooling chosen individually, sometimes through layers of subcontracting. The agentic supply chain risk in that model is genuinely unbounded — not because the engineers are careless, but because no one holds a complete picture of the tooling surface touching the client's code.

This is where the delivery model becomes a security control rather than a commercial preference. Stepto's engagements are built on direct-hire senior engineers working as a persistent extension of the client's team, with a known and managed tooling surface — identified people, managed workstations, an agreed set of AI tools and MCP servers, and no subcontracting layers obscuring who is touching the codebase. That doesn't make prompt injection impossible; nothing does. It makes the questions above answerable, which is the actual prerequisite for managing the risk at all.

Using Agents Anyway, Deliberately

None of this argues for abandoning AI coding agents. The productivity case is real, the tooling is improving quickly, and organizations that step back from it will be at a genuine disadvantage. The argument is for adopting them with the operational seriousness their privilege level warrants, which is not how most teams adopted them.

The characteristic mistake was treating a coding agent as an editor plugin — an individual developer's productivity choice, installed at will, configured personally, unreviewed. The 2026 incidents make clear it is closer to a privileged automation service: it holds repository write access and cloud credentials, ingests untrusted external data, executes commands, and modifies dependencies. Software with that profile in any other context would arrive with a threat model, an approved configuration, integrity monitoring, and a defined incident response path.

Retrofitting that discipline is straightforward and mostly organizational: decide which agents are approved, pin and review their MCP surface, monitor their configuration, strip ambient credentials from their environments, keep meaningful human review on the changes they propose, and add agent configuration to your compromise-assessment checklist. Teams that do this keep the productivity gains while removing themselves from the population that the next agentjacking-class disclosure will describe.