There’s a particular kind of pull-request mess that only happens when an AI coding agent commits unsupervised: a sprawling diff that touches files unrelated to the task, contains a half-finished refactor, and leaves the repo in a state that’s hard to bisect. Once you’ve cleaned up one of those by hand, you start asking better pre-flight questions.
Here’s the checklist I run through before letting any AI agent — Claude Code, Codex, Gemini, Copilot CLI, all of them — commit autonomously. Five questions. If you can’t answer all five with a confident yes, the agent isn’t ready for that workflow yet.
1. Is the agent on its own branch?
Default-branch protection should be the first wall. If your agent ever has the option to commit to main, you have one accident away from a bad day. The pattern that works:
- Branch protection rules on
main— require PR, require review, require CI green - The agent’s shell starts in a feature branch by default (a wrapper or alias does
git checkout -b ai/<task>) - An auto-deny rule on
git push origin main,git push -f, andgit push --forcefor the agent
The branch is the seatbelt. Everything downstream of it is recoverable; without it, things aren’t.
2. Is the diff bounded by scope?
The classic AI-agent failure mode is “helpfulness drift” — the model fixes the bug you asked about, then notices three other things that look fixable, then tries to refactor the directory layout. Two ways to constrain this:
- Pre-commit diff size guard. A simple hook that fails the commit if the diff exceeds N lines or touches more than M files. Forces the agent to break work into smaller pieces.
- Path allow-list per task. If the task is “fix the bug in
auth.ts,” only files undersrc/auth/**andtests/auth/**should be in the diff. Anything else, prompt.
The point isn’t to make the agent dumber — it’s to make sure the boundary of what changed matches the boundary of what you asked for.
3. Are there secrets in the diff?
This one is non-negotiable. If your agent commits a file containing an API key, even on a branch, even before push, you assume the key is leaked. Three layers:
- A pre-commit secret scanner.
gitleaks,trufflehog, or equivalent. Auto-fail the commit if it finds anything. - An auto-deny rule on writing files matching
**/.env*,**/secrets/**,**/*.pem. The agent can read them when needed; it should never write them. - An auto-deny rule on echoing environment variables to anywhere a log might catch them.
echo $SECRET_KEY,printenv,env | grepshould all prompt.
4. Is what’s about to happen reversible?
Before approving any agent action, ask: “If this turns out to be wrong, can I get back to where I was?” Three categories worth distinguishing:
- Trivially reversible. Local file changes you haven’t committed.
git checkoutfixes it. - Reversible with effort. Local commits that haven’t been pushed.
git resetorgit revertfixes it. - Effectively irreversible. Pushed force-pushes, deleted branches, dropped tables, package publishes, emails sent, payments processed.
Auto-approval is fine for the first category, careful for the second, and never for the third. git push --force-with-lease on a feature branch is in category 2; npm publish is in category 3.
5. Is there an audit trail?
The last check is the one that helps you when something does go wrong. You need a record of:
- Which prompts triggered which tool calls (chat session ID + permission requests)
- Which tool calls were approved, denied, or auto-resolved — and by what rule
- What the resulting commits / files / network requests were
If you can answer the question “what did the agent do last Tuesday?” in less than five minutes, you’re fine. If you can’t, you don’t actually know what it did, you just hope it was the right thing. That’s not a defensible position when the audit eventually matters.
None of this is to say AI agents shouldn’t commit autonomously. They should — that’s most of the value. But autonomous needs a different posture than human-in-the-loop. The five checks are how you build the posture without giving up the speed.