Today we're releasing gitfence as an open-source project under the MIT license. It's a drop-in git wrapper that stops AI agents from executing destructive git commands — install it once, and every git call in that environment is filtered. Read-only commands pass through instantly; mutating commands are blocked before they touch your repository.
The problem: agents have git, and git has no brakes
AI agents are writing code now. They commit, push, rebase, and reset — the same operations any developer uses. The difference is that an agent doesn't understand consequences. It can hallucinate a reason to force-push to main, delete a branch it decides is "stale," or run git reset --hard because it thinks that's the fastest path to a clean state. It doesn't realize it just broke a CI pipeline, wiped uncommitted work, or overwrote a teammate's branch.
The deeper issue is that git was never designed for autonomous agents. Read and write operations live in the same binary, one flag apart. git log is safe. git push --force rewrites history. There's no separation between "inspect the repo" and "mutate the repo." The moment you give an agent access to git for something as innocent as a status check, you've implicitly handed it every destructive operation git offers.
We heard this pain directly from engineers building with agents. The single most common frustration wasn't hallucinated code — it was agents pushing to main. When an agent has commit and push rights, one bad decision reaches the remote before a human ever sees it.
Why the existing workarounds fall short
Teams have tried to contain this, but every approach trades away too much:
- Remove git entirely. The agent can't push — but it also can't
git difforgit log. You lose the read-only operations that make an agent useful in the first place. - Read-only VMs. Every write syscall is blocked at the OS level. The agent can't even write a file, let alone push. Far too blunt for real work.
- Prompt instructions. "Don't push to main" works right up until the model hallucinates a reason to ignore it. Prompt-based guardrails are probabilistic, not deterministic — and probabilistic isn't good enough when the downside is rewritten history.
How gitfence works
gitfence is the deterministic alternative. It parses every git command before execution and applies a strict allowlist. Read-only commands (status, diff, log, show, blame, and more) pass straight through to native git with effectively zero overhead. Mutating commands (push, commit, reset, rebase, checkout, clean, ...) are stopped with a clear, structured error that tells the agent exactly what happened and what to do instead.
It runs in one of two modes.
Standalone mode — zero config
Block all mutating commands. No network calls, no external dependencies. Run gitfence init and it works.
Agent runs `git push origin main`
|
v
[gitfence parser]
|
|-- Read-only command? --> Pass through to native git
|
|-- Mutating command? --> Block + return structured error
Governed mode — with a policy gateway
Connect gitfence to a policy gateway for granular control: allow pushes to feature branches, block pushes to main, and route force-pushes to human approval. The gateway evaluates policy; gitfence executes the decision — ALLOW, BLOCK, or PENDING_APPROVAL.
Agent runs `git push origin main`
|
v
[gitfence parser]
|
|-- Read-only? --> Pass through locally (no gateway call)
|
|-- Mutating? --> POST /git/evaluate to gateway
|
|-- ALLOW --> Execute via native git
|-- BLOCK --> Return error to agent
|-- PENDING_APPROVAL --> Wait for human approval, then execute
When a command routes to human approval, gitfence stays alive and polls until the request resolves. And before it executes an approved command, it verifies the repository's HEAD hasn't changed since the approval was requested — closing a real vulnerability class where an approval granted for one set of changes gets used to push a different one.
No lock-in: gitfence is gateway-agnostic
gitfence talks to any HTTP service that implements two endpoints — POST /git/evaluate and GET /git/approval/{id}. There's no vendor requirement. You can build your own gateway (a policy that allows feature-branch pushes and blocks main is about 50 lines of code), use an existing one, or run standalone with no gateway at all.
If you want a gateway that handles this alongside full AI governance — a policy engine, an audit ledger, a human-in-the-loop approval queue, and cost controls — that's exactly what Froda AI provides. But gitfence never requires it. That's the point.
Why we're open-sourcing it
We built gitfence because our own platform needed deterministic git guardrails, and we quickly realized the problem is bigger than any single vendor. Every team putting an AI agent near a repository faces the same gap, and a guardrail you can't inspect is a guardrail you can't fully trust.
Open source is the right answer for a tool like this:
- Trust through transparency. A security guardrail should be auditable. You can read exactly which commands pass and which are blocked — no black box deciding what your agents can do to your code.
- A shared, defensible default. The classification of read-only vs. mutating git commands is something the whole ecosystem benefits from getting right, together. A community-maintained allowlist is stronger than one any single company ships in isolation.
- Adoptable anywhere. MIT-licensed, gateway-agnostic, zero-dependency in standalone mode. Drop it into a container, a CI runner, or a local agent sandbox without adopting a platform.
Guardrails only matter if people can actually use them, everywhere their agents run. Locking this behind a product would defeat the purpose.
Get started
Install from source with Go 1.22+:
go install github.com/shahriarhossain/gitfence@latest
Then initialize it in standalone mode to block all mutations:
gitfence init
That's it — git now resolves to gitfence, read-only commands work normally, and destructive commands are stopped before they run. Homebrew, manual downloads, and Docker setup instructions are all in the repo.
The code, the full gateway contract, and the complete list of allowed and blocked commands live on GitHub:
📦 github.com/shahriarhossain/gitfence
Try it, open an issue, send a pull request. If it stops even one agent from force-pushing to main, it's done its job.
Froda AI provides runtime governance infrastructure for autonomous AI systems — helping teams discover, govern, enforce, and audit AI activity in real time. gitfence is one deterministic layer of that story, and it's yours to use. Learn more.
