Git Operator
A mediation point that decides before a git/gh mutation from a coding agent reaches GitHub, and records every decision in a hash-chained ledger.
- Model
- Commercial B2B product, sales-led pilots
- For
- GitHub-hosted engineering orgs of ~20–120 developers already running coding agents
- Deployment
- Local-only: npm CLI + gitoperatord daemon. Nothing leaves the client's machine or CI runner.
- V1 verbs
- begin-work · commit.create · finish
The moment a coding agent has a shell, it inherits the ambient git/gh credentials of the machine it runs on.
Branch protection, PR review and secret scanning all fire after the mutation has already reached the forge. Agent-assisted commits already leak secrets above baseline: 3.2% against 1.5% (GitGuardian, 2025).
“Detect and block after the fact” is not the same product as “decide before it happens.”
The bet is falsifiable: if target buyers cite GitHub's native push protection or Agent HQ AI Controls as already sufficient and decline to evaluate further, the bet is wrong.
The one call that must be perfect
The agent never calls git or gh directly. Everything else in the product is downstream of this promise holding under real agent traffic.
Judges the impact of the mutation.
Judges whether it is in scope.
Judges who is accountable and under what authority: a registered operator session, a traceable work_item_id, and no unverifiable extended-authority claim.
Every decision, accepted or rejected, is appended as an entry referencing the previous entry's hash.
If chain verification fails at any point, all further mutations are frozen until the chain is restored or manually cleared. Recovery target: RTO ≤ 5 minutes.
V1 has no real issuer for capability_id or remote_claim, so every such request is rejected.
Faking acceptance would misrepresent a verification the product cannot perform. This is a shipped product trait, not a gap hidden behind a v2 promise.
Who it is for
Prevent an agent-caused incident before it happens: a leaked secret, an out-of-scope diff, a protected-branch push.
Today: branch-protection rulesets, human PR review and secret scanning, all after the fact.
Keep agent velocity while every git/gh mutation is checked and recorded, without reviewing every diff by hand.
Onboarding a new identity takes one CLI command. A rejected legitimate request offers a self-service exception path.
What I refuse to build
- A hosted, multi-tenant control planeA cross-client ledger would be a labelled breach target, not leverage. V1 stays local-only.
- A two-tier pricing gridTwo grids invite self-selection discounting. One grid, priced per repo, banded by contributing-developer count.
- A faked capability_id or remote_claimEvery unverifiable request is rejected, not silently accepted.
- A two-way issue-tracker connector in V1It does not move useful-rejection rate, time-to-PR or doctor-green. work_item_id stays compatible with Linear, Jira and GitHub Issues keys.
- A production-ready queue.admitIt depends on a real org merge queue that has never been live-verified end to end. It stays beta.
Commercial model
A sales-led pilot motion. The prospect installs the CLI into their own repositories; doctor-green is the proof point that closes a pilot.
Open assumptions
- Buyers will pay for a pre-mutation gate distinct from GitHub's bundled controls. Pending
- Neither GitHub nor Entire ships a native pre-mutation gate within the V1 window (~2 quarters). Pending
Git Operator is a commercial product in development. Latency and pilot figures are design targets, not measurements. Zero paid pilots within 6 months is a project-ending condition.
Running coding agents against your repos?
Pilots are open to GitHub-hosted engineering teams already using coding agents in local dev or CI.