/AI-SECURITY · 2026-09-10
Git status is a tool call
Seven coding agents ran git in the background to “understand the repo.” A config key became argv because git was never an allowlisted tool.
Manifold’s GitSpawn class is simple: the agent shells out to git for status, diff, and log. A cloned repo can ship a .git/config that points those commands at attacker-controlled programs. Claude Code, Codex, Cursor, Goose, Qwen Code, Grok Build, Hermes. Four were still open on a 1 Sep retest. We are not publishing the keys.
The harness runs git with the repo’s config. If the broker does not name git as a tool, does not pin the binary, and does not refuse repo-local hooks, you have a chat box with side effects. See four gates.
What failed
- Allowlist: git was not a named tool. It was ambient context collection.
- Schema: config values became execution. Extra keys were not dropped.
- Sandbox: the process could run whatever the repo named, as the user.
- Confirm: background git has no human in the loop. That is the point of background.
Vendor patches that “ignore unknown config” are a local fix. The harness still has to decide whether git runs at all, with which binary, from which working tree.
What we look for on an agent desk
Does the agent clone untrusted remotes? Does it run git before a scope file says the tree is in-bounds? Can a retrieved README or a submodule change the tool list? If yes, stop. The finding is that context collection was execution.
Same thesis as prompts → loops: the attack surface moved when the model got a shell. GitSpawn is just the loop touching a config file you did not inventory.