Governing the Agent Workforce: Repo Trust, Inventory and Audit

Most teams govern AI coding agents with one control: the permission prompt. The agent asks, a developer clicks allow, work continues. It feels like a human in the loop.

On September 1, researchers showed how thin that layer can be. A repository can make several popular coding agents run attacker code on a developer's machine before the agent ever asks for permission.

This year we have written about least privilege for agents, shadow agents installed outside IT's view and intrusions moving at machine speed. The credential advice from those pieces still stands: separate identities, narrow and short-lived access, approval gates the agent cannot grant itself, backups out of reach. This piece is about the four things they left open: what the agent trusts, what you know about your agents, what you can prove afterwards, and who is in charge.

GitSpawn: when the repo runs before the prompt

Manifold Security published GitSpawn on September 1: eight findings across seven command-line AI coding agents, with four still unpatched at publication. The Hacker News reported it the next day. The core trick uses core.fsmonitor, a Git performance setting whose value is a command Git runs to detect changed files. A malicious .git/config points it at an attacker's command.

Agents run commands like git status in the background at startup to understand the workspace. That triggers the setting, and the command runs as the user, outside the agent's sandbox, with no approval prompt. Manifold reported that in at least one agent the payload ran before the workspace-trust prompt was even accepted.

There are limits worth stating. Exploitation needs the repository to arrive with its .git directory intact, such as a shared archive, shared drive, sync folder or USB stick; an ordinary clone does not carry the config. The Hacker News found no reports of exploitation, and several vendors had shipped fixes while others were still pending.

The bigger point is architectural. The agent's permission system governed the agent's own tool calls. It did not govern everything that happened in the developer's environment because the agent was there. A permission prompt depends on a human paying attention, on the agent describing what it is about to do, and on every side effect going through the prompt. GitSpawn broke the third assumption. Prompt fatigue breaks the first one every day.

Treat the workspace as untrusted input

We already treat web pages and emails as untrusted input for agents. Repositories and their configuration belong in the same category. A workspace is not just source code: it carries Git config, hooks, editor task files, dependency manifests and, increasingly, agent instruction and tool configuration files. Any of them can change what runs when an agent opens the folder.

• Open received code in a throwaway environment. Anything that arrives as files rather than a clone from a known remote gets opened first in a disposable container or VM with no credentials.
• Check config before the agent does. Look for core.fsmonitor, core.hooksPath and filter settings in .git/config, and for unexpected hooks or task files.
• Review agent config like CI config. Changes to agent instruction files, tool settings and server lists should need a code owner's approval, the same as a pipeline definition.

Keep an agent registry

GitSpawn affected seven agents. The first question every security team had was which of them their developers run, and which versions. Most could not answer quickly. A registry turns that into a lookup. For each agent, record:

• The tool and version, and where it runs: laptops, CI, cloud workspaces.
• The identity it acts as and the systems that identity can reach.
• Which workspaces and config sources it reads at startup.
• A named human owner and the business purpose it serves.

Feed vendor advisories against that list, pin versions, and treat an unregistered agent as a finding rather than a curiosity.

Design the audit trail before you need it

Logging tool calls is not enough. In GitSpawn the harmful command was not a tool call at all; it was a process Git started because the agent asked for status. An audit trail for agents should capture who or what made the request, which workspace and config were loaded, which tools were called, which credentials were used, and the process tree underneath, linked by one session ID. Endpoint tooling that records process lineage gives you the last part. Ship it all somewhere the agent cannot write, and test that you can answer "what did it do?" in minutes.

Decide who owns agent governance

Agents fall between teams. IT manages the laptops and licences, security writes policy and handles advisories, and the business or engineering lead decides what the agent is for. When nobody is named, every team assumes another one has it. A workable split: IT owns the registry and the managed runtime, security owns policy, detection and response, and each agent's business owner approves its scope and answers for its actions. Write that down in one page.

Vendors are moving the same way. On October 6, ServiceNow announced AI Workflow Factory, with its AI Control Tower governing "the workflows, decisions, and agent actions" and a single governance model and audit log for apps and agents on its platform. You do not need that product to apply the idea. You do need the idea.

What we recommend

• Patch and pin agent CLIs. Track vendor advisories for GitSpawn-class issues and keep agents on fixed versions.
• Stand up the registry this quarter, with an owner for every entry.
• Make untrusted-workspace handling the default for anything received as files.
• Put agent config files under code owners.
• Define the audit record, including process lineage, and run one drill that reconstructs a session from logs.
• Publish the ownership split between IT, security and the business.

None of this is new security thinking. It is the same input validation, asset inventory and audit discipline we apply elsewhere, extended to a new kind of worker that happens to be very fast and very literal.

If your teams are adopting coding agents faster than your governance can keep up, the HAZL Solutions team can help you design the registry, workspaces and audit trail to match.