Guarding coding agents before they touch your shell, git and files

A coding agent has the same tools a developer has: a shell, git and the file system. Most of what it does is harmless (reading files, running tests, editing source). The problem is the small share of calls with a large blast radius:

• rm -rf on the wrong directory, or a cleanup step that deletes untracked work.
• git push --force to a shared branch, or git reset --hard that discards uncommitted changes.
• Reading ~/.ssh/id_ed25519, .env or a cloud credentials file, then a curl to an external host a few steps later: a classic data exfiltration pattern.
• Following instructions found in a README, an issue comment or a dependency’s output rather than the developer’s request (indirect prompt injection).

None of these need a malicious model. A misread instruction or an over-eager cleanup is enough.

Call the guard from the agent’s pre-tool-call hook (for example a PreToolUse hook in Claude Code, or the equivalent in your framework). For each call, send:

• action: the tool and its arguments, e.g. { tool: "bash", args: { command: "git push --force origin main" } }.
• intent: what the developer asked for in their own words.
• trigger: user_request when the action follows directly from the developer, tool_result when the agent proposed it after reading file contents, command output or web pages.
• constraints: the rules of the session, such as "never push to main" or "only modify files under src/".
• context: the repository, branch and whether this is a local checkout or a shared machine.

The trigger field matters most for injection: a destructive command proposed right after the agent read an untrusted file deserves more suspicion than the same command typed by the developer.

By default the server returns block when P(unsafe) is at least 0.8 or the approval_policy head says reject, ask when P(unsafe) is at least 0.3, the policy head says require_human, or args_grounded is below 0.5, and allow otherwise. You can ignore the default verdict and apply your own thresholds to the scores.

For coding agents a practical policy is: run allow silently, show ask as a confirmation prompt with the reasons, and refuse block while telling the agent why so it can choose another approach. The scores that matter most here are destructive (file deletion, history rewrites), exfiltration (secrets leaving the machine), injected (instructions from repository content) and blast_radius (local and reversible versus shared or remote). Read-only calls such as ls, cat on source files or git status should come back as allow, which keeps prompts rare.

A check takes about 15 ms on our GPU (RTX 4090, batch 1, p95 about 23 ms) plus the network round trip, so it fits in the hook without slowing the session noticeably.

The guard is one layer and it can be wrong. Keep deterministic controls that do not depend on a model:

• Run the agent in a container or VM with only the repository mounted.
• Give it credentials that cannot push to protected branches; use branch protection on the server side.
• Keep a short denylist for commands you never want run (for example rm -rf / or git push --force to main) and enforce it before the guard is called. See guards vs allowlists and denylists.
• Commit or stash often, so a bad edit is recoverable.

The guard covers what the rules cannot anticipate: the unusual command, the right command in the wrong context, or the command the agent was talked into by a file it read.