How to stop an AI coding agent from doing something you can't undo (approval gates, explained)

Draft only. Publishing = CEO approval (public content). Second SEO asset, targeting a **different, more transactional

long-tail cluster** than SSK-SEO-001 (which targets "CLAUDE.md template / multi-agent workflow"). This one targets the

pain-search — someone who just got scared by an agent and is Googling how to constrain it. Value-first; the product is

the last line, in context. Builds a second compounding organic entry point.

How to stop an AI coding agent from doing something you can't undo

If you've handed real autonomy to a coding agent — background runs, its own task list, work across sessions — you've probably had the moment this post is about: it got one command away from something irreversible (a force-push, a prod deploy, an email to a real user) and the only thing that stopped it was you happening to be looking.

That's not an agent-quality problem. It's a missing control. Here's the control, in the order I'd add it.

1. The mental model: separate judgment from authority

Let the agent have full judgment — how to write the code, how to structure the work, what to research. Take away its authority over a short, fixed list of actions that are irreversible or externally visible. The agent doesn't get to decide whether those are "safe this time." They always stop.

My list — the whole thing:

• Spending money or changing a subscription
• Deploying to production
• Emailing or messaging any external party (customer, vendor, user)
• Deleting data or changing a production schema
• Committing to a price, deadline, or scope with a customer
• Publishing public content

Six items. Everything else runs autonomously.

2. Make "merge to main" physically impossible, not merely discouraged

The most important gate isn't a prompt — it's branch protection. Turn it on for every main and require a PR review you (a human) click. Now "the agent must not merge to main" isn't a rule the model can rationalize its way around under a confident-sounding plan; it's a wall. The agent opens a PR, and production waits for a human click. This one setting removes the entire category of "it deployed something I hadn't seen."

3. Route irreversible actions to an approval file instead of executing them

For the actions in §1 that aren't a git merge, the pattern is: the agent writes the request to a pending-approval file — what it wants to do, why, the cost/risk, and a default if you don't respond — and stops. You review a queue instead of catching things mid-flight. The agent's reasoning is preserved, so approving is a 10-second read, not an interrogation.

Example entry:

## APR-014 | Send 20%-off email to trial users who stalled at onboarding
why:   12 users stalled at step 3 in the last 14 days; recovery attempt
risk:  external message to real users; reputational if mistargeted
default (no reply in 48h): do NOT send
status: waiting on founder

4. Give money a boundary, not a blank check

If an agent can spend (ads, APIs, infra), it gets a budget envelope: a pre-approved amount, a ledger it must write to before spending, and a hard "never past the balance." Every spend gets a one-line hypothesis, reviewed later against what actually came back. This turns "the agent ran up a bill" into a bounded, auditable experiment.

5. Decide when to stop before you start

For each project, write a one-line kill/scale criterion at the outset — "kill if 0 paying users by week 4; scale if 1+ sale → set an MRR target." When the date arrives, shutting it down is a criterion check, not an emotional call. Agents (and founders) both need this, because both are bad at killing things they've invested in.

6. See it at a glance

Once you have more than a couple of agents, you need one place that answers "what's blocked on me right now." A tiny dashboard over the approval queue does it — review and approve from your phone, skip digging through git log.

---

The point

None of these are model features you wait for. They're controls you add, the same way you'd add permissions and audit logs before giving a new human employee production access. Add branch protection first (five minutes, biggest risk removed), then the approval file, then budgets and kill-criteria as you scale past one project.

I packaged this exact system — the constitution, the approval-gate protocol, budget envelopes, kill/scale templates, the memory protocol, and the dashboard — as the [Founder OS Kit], so you don't have to derive it after getting burned. But the six controls above stand on their own; steal them.

asset ideas

• Diagram: the six-item authority list as a "stop sign" gate between agent and production.
• Screenshot: a real (sanitized) pending-approval entry.
• Internal-link to SSK-SEO-001 (the constitution post) for topical clustering.