# Your AI Coding Agent Just Became a Delivery Mechanism
When developers invite AI agents into their terminals, they're handing over something they've never handed to a tool before: the ability to read, reason about, and *act* on their entire local environment. Manifold Security just showed what happens when an attacker puts a poisoned repository in that agent's path.
The research, published this week, documents eight security flaws across seven command-line AI coding agents — including tools built on Claude, OpenAI's Codex, and Cursor. The core issue is deceptively simple: a repository's .git/config file can specify a command, and several of these agents will execute it on the developer's machine without an approval prompt, outside whatever sandboxing the agent otherwise enforces, running as the user.
Four of the eight vulnerabilities remain unpatched.
## How Git Becomes a Trap
Git's configuration system was designed for flexibility — power users can define custom merge drivers, filter programs, credential helpers, and filesystem monitors. The core.fsmonitor key, for example, accepts an executable path that Git calls to check for modified files. So does core.hookspath, which redirects Git hook execution to an arbitrary directory. These are legitimate features. They're also, in the context of AI agents that autonomously run git operations against untrusted repos, a loaded gun pointed at the developer.
Here's the sequence that turns a clone into a compromise:
A developer asks their AI coding agent to review, analyze, or run a repository. The agent — acting autonomously, as designed — performs git operations against the repo. The repo's .git/config contains a crafted entry pointing to an attacker-controlled command. Git invokes that command. The command executes as the developer, with their credentials, their SSH keys, their cloud provider tokens, their access to production.
No prompt. No warning. No sandbox. Just execution.
The agents tested by Manifold weren't cutting corners on security out of negligence — most have sandboxing and permission models that their developers have spoken publicly about. The problem is that these protections assume the threat model is an AI making bad decisions. They were never designed to handle the case where a *configuration file* in the repository itself instructs git — which the agent calls as a subprocess — to run something.
## The Supply Chain Angle Nobody's Talking About
Most coverage of this class of vulnerability focuses on the immediate scenario: a developer clones a malicious repo and gets compromised. That's real and serious. But the more concerning attack path runs through legitimate repositories that have been quietly poisoned.
Consider the actual development workflow these agents are designed to support. You open an issue in a GitHub repo. Your AI agent fetches the repository, analyzes the code, proposes a fix. If that repository — even a well-known open source project — has had a malicious commit land in its git history that tampers with .git/config, every developer whose agent touches that repo is exposed.
The same dynamic applies to private repositories where an insider threat or compromised contributor introduces a single config change. .git/config isn't a file that shows up prominently in code review. Pull requests typically display diffs of source files. Config manipulation is quiet.
This is also worth reading in the context of typosquatting attacks on package registries, where attackers create slightly misspelled versions of popular packages. Typosquatted repositories with weaponized git configs are a natural evolution of that playbook — and they'd be considerably harder to detect, because the payload lives outside the source tree that security scanners typically inspect.
## Four Unpatched Is Not a Rounding Error
Manifold disclosed these flaws through coordinated disclosure. Three vendors patched before publication. Four did not.
The disparity matters. When half the affected vendors patch and the rest don't, it creates a false sense of safety — developers see their preferred tool listed alongside patched vendors and assume the problem is solved. Meanwhile, agents in active use at companies processing sensitive code remain vulnerable to a published, documented exploitation technique.
It also reveals something about the security posture of teams building these agents. The vendors who patched quickly likely already had internal threat models that included malicious repository content. The ones who haven't patched yet apparently did not, or didn't treat it as urgent once they did.
That gap is the actual news here.
## What Defenders Can Do Right Now
For teams already deploying AI coding agents:
Enforce repository isolation. Agents should operate against repositories in ephemeral, network-isolated environments when possible. If the agent can't reach your AWS metadata endpoint or SSH to your production server, the blast radius of exploitation shrinks dramatically.
Audit your agent's subprocess model. Does your agent invoke git directly? Does it sanitize or inspect .git/config before running git operations? Read the source if it's available. File a support request if it isn't.
Treat .git/config like executable code in review. Any change to that file in a pull request should get the same scrutiny as a script change. Add it to your code review checklist. Some CI pipelines can flag this automatically.
Check your vendor's patch status. Manifold's disclosure names the affected tools. If your agent is among the four unpatched, your options are to restrict its use on untrusted repositories, wait for a patch with awareness of the risk, or replace it with a patched alternative.
## HackWire Analysis
This disclosure lands at a specific moment: enterprise adoption of AI coding agents is accelerating faster than the security industry's ability to threat-model them. Security teams are still figuring out how to govern what these tools can *read*. The question of what they can *execute* has barely entered the conversation.
What Manifold has documented is a class of vulnerability — call it configuration-driven code execution via trusted tooling — that will recur. Git is not the only attack surface. Package managers, build systems, and editor configurations all follow similar patterns: they read local configuration files and execute code based on what they find. An AI agent that autonomously interacts with these systems inherits all of those attack surfaces simultaneously.
There's also a vendor accountability problem emerging in real time. When four out of seven affected vendors haven't patched a published vulnerability that executes arbitrary code on developer machines, the question isn't whether the vulnerability is serious — it clearly is — the question is whether the AI coding tool market has the security maturity to handle responsible disclosure at scale. Based on this evidence, it doesn't yet.
The developers most at risk are the ones using these agents most aggressively: the early adopters who've fully integrated autonomous agents into their workflow, who let agents run git operations without supervision, who clone unfamiliar repositories precisely because the agent makes analysis cheap. The people getting the most value from these tools are also the most exposed.
Defenders should treat this as a category of risk, not a single CVE to patch and forget. Every time you hand an AI agent the ability to run tools autonomously, you're expanding the attack surface. That's not an argument against using these tools — it's an argument for understanding the new threat model they introduce.
— HackWire Editorial
---
## Related Coverage