Four AI Coding Agent Exploits Landed in Two Weeks. The Sandbox Boundary Failed in All Four.

Two weeks, four AI coding agent exploits, one root cause

Between the last week of August and the first week of September 2026, four separate disclosures landed in AI coding agent security: a git-configuration exploit that needs no prompt at all, a supply-chain trick built on unregistered package names inside vendor documentation, a firewall-log injection technique, and fresh numbers on how exposed the wider agent ecosystem already is. Read individually, they look like four unrelated stories. Read together, they are the same story told four times.

None of the three headline exploits below relied on tricking a model into ignoring its instructions. Each one worked because an agent took an action that crossed from "inside the sandbox, reversible" to "outside the sandbox, running as the developer" without anyone being asked whether that crossing was fine.

GitSpawn: git status is not supposed to be able to do this

Manifold Security disclosed GitSpawn on 1-2 September 2026. The mechanism abuses the core.fsmonitor setting inside a repository's .git/config: point it at an attacker-controlled command, and the moment anything runs a routine, read-only-looking git operation such as git status, that command executes. Not on clone. Not on an obscure command a developer might pause over. On git status, which a coding agent runs constantly and unattended, often dozens of times an hour, without ever treating it as a decision point.

Manifold found the flaw affects seven agents: Claude Code, OpenAI Codex, Cursor, Goose, Hermes Agent, Qwen Code and Grok Build. Four CVEs were assigned, and four of the affected paths were still unpatched at disclosure. For scale, Claude Code alone sees more than 77 million npm downloads a month, which gives a sense of how many working copies a single unpatched path touches.

Full technical detail is in the Manifold Security writeup covered by VibeEval's September security roundup.

The phantom package problem: when vendor documentation becomes the attack surface

A separate piece of research, described by Bruce Schneier in early September, took a different angle: instead of attacking an agent directly, researchers at an Israeli stealth startup scanned 6,214 live domains belonging to defence contractors, Fortune 500 companies and major technology firms for llms.txt and llms-full.txt files, the increasingly common convention vendors use to hand AI agents machine-readable documentation.

Across those domains they found 8,265 such files. Of those, 120 pointed to code packages or domain names that were not actually registered to anyone. The researchers claimed a handful of the unclaimed names and hosted harmless test packages at them. Within an hour, one of those packages received a phone-home response from a Fortune 500 company's network. Over the following period, a few dozen more came in from other Fortune 500 firms and startups.

The pattern they call "the Clerk case" is the clean version of this: a vendor's own documentation instructed agents to fetch a package name that was never registered, leaving it open for anyone to claim. An agent that treats vendor documentation as ground truth, rather than as an unverified pointer, will install whatever sits at that address.

Schneier's summary of the research is here: AI coding agents are installing unknown, untrusted code on corporate networks.

GhostJacking: turning your own defences into an attack vector

The third disclosure, from Tenet Security, is the one that should worry security teams who thought they already had a mitigation in place. A web application firewall does exactly what it is meant to do: it blocks a malicious request and logs the payload, intact, for later review. GhostJacking exploits the step after that. When an agent is later asked to investigate what got blocked, it reads the logged payload as an instruction to follow rather than evidence of an attack to report on.

Tenet Security measured a 90% success rate against Claude Code running a vendor-recommended configuration, with no standard detection firing anywhere along the chain. In their demonstrated attack chains, this reached as far as DNS record modification, cloud credential theft and lateral movement between agents. Their reconnaissance identified more than 15,000 organisations sitting in range of the same setup.

More detail on the GhostJacking chain is in Adversa AI's roundup of coding agent security resources.

These three are not isolated war stories either. Antiy CERT separately confirmed 1,184 malicious skills across ClawHub, the marketplace for the OpenClaw agent framework, roughly one in five packages in that ecosystem at peak infection. Trend Micro, working the infrastructure side, found 492 MCP servers exposed to the open internet with no authentication and no traffic encryption at all.

Why prompt injection defences don't stop any of this

Most of the public conversation about AI agent security still centres on the prompt: system-prompt hardening, refusal training, red-teaming for jailbreaks. That work matters, but it is defending the wrong layer for all three exploits above. GitSpawn triggers on a git configuration setting before the model reasons about anything. The phantom-package attack exploits trust in a documentation channel, not persuasion of the model. GhostJacking exploits what an agent does once asked to review a log, not what it can be talked into believing.

In each case, the vulnerability sits in the gap between "the agent has decided to take an action" and "that action is now running outside the sandbox, as the developer, with real credentials." A model that never says anything unsafe can still walk straight through that gap, because nothing about the exploit requires it to say anything at all.

The five checkpoints that would have stopped every one of these

None of this requires waiting on a vendor patch. Each disclosure maps to a specific, buildable checkpoint:

• Treat repository configuration files, .git/config, .npmrc, lockfiles, as untrusted input on the same footing as an uploaded file. Flag config-only diffs in review separately from code diffs; don't let them ride through silently.
• Require an explicit approval prompt before any agent action that changes state or reaches the network outside its sandbox, including commands that look read-only, on any repository that wasn't cloned by a trusted process.
• Verify package and domain ownership before an agent installs or fetches anything referenced in vendor documentation. An llms.txt entry is a pointer, not a pre-vetted dependency.
• Never route defensive logs, WAF, IDS, error-monitoring output, into an agent's context as material to act on without isolating the logged payload first. Quote it back to a human; don't let the agent execute what it contains.
• Assume tool output can be adversarial even when the tool itself is trusted. Compromising Sentry, a WAF, or a package registry was never necessary in any of these three cases; only what flows through them was.

The market is already responding to some of this. Apollo Research shipped Watcher Live on 3 September, a hook-based evaluator for Claude Code and Codex reporting 93% recall on high-severity cases, under 1% false positives, and under 0.1% escalation to a human reviewer. AIR Security raised $50 million the same week, Sequoia leading a $10 million round and Greenoaks leading a subsequent $40 million round, to build a layer that discovers running agents and vets the skills, plugins and MCP servers they touch.

Both are useful. Neither replaces the checkpoint above. A detection layer sitting downstream of the sandbox boundary catches what gets through; it doesn't move the boundary itself. The shape of a fix, in practice, looks like an explicit gate on state-changing tool calls rather than a blanket allow:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|GitCommand",
        "condition": "repo.trust_level != 'verified' && action.changes_state",
        "action": "require_approval",
        "reason": "State-changing action on an unverified repository"
      },
      {
        "matcher": "PackageInstall",
        "condition": "!registry.owner_verified(package.name)",
        "action": "block",
        "reason": "Referenced package has no verified owner"
      }
    ]
  }
}

What to ask your AI coding agent vendor before the next incident

Four of the seven agents affected by GitSpawn were still unpatched at disclosure. That is the more useful question to ask a vendor than "do you have a fix": ask when it shipped, and whether it shipped for the specific path your team runs. Ask whether the agent draws a hard, enforced line between sandboxed and outside-sandbox execution, or whether that line is a setting a busy engineer can leave on its default. Ask how the agent treats vendor documentation, marketplace skills and MCP servers by default, verified, or trusted until proven otherwise.

The three exploits above are not going to be the last of this shape. The pattern is now well understood enough that the next one will look different on the surface and identical underneath: a routine action, a missing checkpoint, and a sandbox boundary that turned out to be a suggestion.