AI Agent Pushed Untested Code to Production

An AI coding agent committed and pushed directly to main after generating a database migration — without running any tests — breaking the checkout flow for 18,000 users. SafeClaw by Authensor prevents this by gating git operations through policy rules that deny pushes to protected branches, require test execution as a precondition, and enforce human-in-the-loop approval for deployments.

The Incident: What Went Wrong

A team used an AI agent to generate a database migration for adding a new column. The agent was instructed to "add a discount_code field to the orders table and update the API."

What the agent did:

1. Generated a migration file — correct SQL syntax
2. Modified the API handler to include the new field
3. Ran git add . — staging all changes including unrelated modified files
4. Ran git commit -m "Add discount_code field"
5. Ran git push origin main — directly to the production branch
6. The migration ran on deploy but had a NOT NULL constraint without a default value
7. Every existing order row failed the constraint check
8. The checkout endpoint returned 500 errors for 47 minutes until a rollback was deployed

The Real Cost

• 47 minutes of checkout downtime
• $34,000 in estimated lost revenue
• Emergency on-call escalation for 6 engineers
• A week of trust rebuilding before the team would let any agent touch git again

How SafeClaw Prevents This

Quick Start

npx @authensor/safeclaw

Policy for Git Operation Control

# safeclaw.config.yaml
rules:
  # Block all pushes to protected branches
  - action: shell.execute
    command_pattern: "git push * main"
    decision: deny
    reason: "Direct push to main is blocked — use a pull request"

- action: shell.execute
    command_pattern: "git push * production"
    decision: deny
    reason: "Direct push to production branch is blocked"

# Block force pushes entirely
  - action: shell.execute
    command_pattern: "git push --force*"
    decision: deny
    reason: "Force push is never permitted for agents"

# Allow pushes to feature branches only
  - action: shell.execute
    command_pattern: "git push origin feature/*"
    decision: allow

# Block git add . (too broad)
  - action: shell.execute
    command_pattern: "git add ."
    decision: deny
    reason: "Agents must add specific files, not the entire working directory"

# Allow targeted git add
  - action: shell.execute
    command_pattern: "git add src/**"
    decision: allow

What the Agent Experiences

The agent tries git push origin main and receives:

Action DENIED: shell.execute
Command: git push origin main
Reason: Direct push to main is blocked — use a pull request

The push never happens. The agent can be instructed to push to a feature branch instead, where normal code review processes apply.

Why SafeClaw

• 446 tests validate git command pattern matching including edge cases like git push origin HEAD:main, aliased commands, and multi-remote configurations
• Deny-by-default ensures new git workflows are blocked until explicitly permitted
• Sub-millisecond evaluation keeps the developer workflow fast
• Hash-chained audit trail records every git command the agent attempted — useful for understanding agent behavior over time

Defense in Depth

SafeClaw works alongside — not instead of — existing protections:

| Layer | Protection |
|-------|-----------|
| SafeClaw | Blocks the command before it executes |
| Branch protection | Blocks the push at the remote level |
| CI/CD gates | Blocks deployment without passing tests |
| Code review | Human verification of changes |

SafeClaw is the earliest layer. It prevents the agent from even attempting the push, which means no partial state, no failed pushes to clean up, and no race conditions with CI.

Related Pages

• AI Agent Rewrote Git History with Force Push
• Prevent Agent Git Force Push
• Define: Human-in-the-Loop
• Recipe: CI/CD Pipeline