If you build or run coding agents, the most important security event may happen before your UI has anything to ask you.
Manifold Security's GitSpawn disclosure found eight findings across seven AI coding agents. In four paths, a repository's own Git configuration could execute code on the host before the agent displayed an approval prompt. This is not primarily a prompt-injection failure. It is a harness-ordering failure.
The background command that crossed the boundary
Git repositories can carry configuration in .git/config. One setting, core.fsmonitor, can point Git at a file-system monitor hook. The feature is documented and useful for speeding up operations such as git status on large repositories.
The risk appears when an agent runs that ordinary command automatically while gathering context. The repository author controls the configuration. The agent controls the timing. If the hook path executes before the approval flow, attacker-supplied code reaches the host without a model decision or user approval.
The first diagnostic I now run in an unfamiliar repository is read-only:
git config --show-origin --get-regexp '^core.fsmonitor$'
An unexpected value is a stop signal. Do not open the repository in an automated agent until the configuration and hook path have been reviewed. For tools you build yourself, background Git operations need the same sanitization policy as user-triggered commands.
The runtime contract should be explicit about what first action means. Record the repository identity, the configuration source, the exact background command, whether a permission state existed, the start and finish events, and the resulting process or tool output. A record that begins with the first model prompt cannot answer whether git status ran earlier.
This is why the fix has two parts. Prevent repository-supplied executables from running during context gathering, and preserve enough evidence to reconstruct the path if prevention fails. One is a Tools-layer control. The other crosses Tools, Memory, and Human review. Neither replaces the other.
Why the prompt is in the wrong place
The Agent Stack gives this failure a useful map: Human → Behavior → Tools → Memory → Agents → Models.
The Models layer was not involved. The Agents layer made a normal context-gathering decision. The Tools layer ran git status, and Git followed the repository's configuration. Behavior rules and the Human approval checkpoint were downstream.
The prompt may still render correctly. It is guarding a later action while the earlier tool call has already completed.
What the retest showed
The disclosure covered seven agents but eight findings because Claude Code had two separate exposed paths. By the September 1 retest, four paths were fixed and four remained open: Hermes Agent, Qwen Code, Grok Build, and Claude Code's second path. Qwen could execute before authentication completed. Grok could execute on the first keystroke. Claude Code and Hermes could execute before workspace trust was accepted.
This is why closing a ticket is not the same as fixing a layer. A vendor can patch the exact route a researcher reported while leaving another route with the same trust assumption.
A practical preflight
Before opening an unfamiliar repository inside an agent:
- Inspect .git/config and check core.fsmonitor or similar hook settings.
- Treat every repository you did not write as untrusted input.
- Sanitize repository-supplied executables on background context-gathering calls.
- Log the first background tool action, not just the first visible prompt.
The full article, including the layer mapping and retest details, is here: https://echonerve.com/gitspawn-through-the-agent-stack-lens-where-your-agents-trust-boundary-actually-sits/
Top comments (0)