Your Yes Is the Weakest Gate

The first time an AI coding agent asks to run a command, you read it carefully.

The tenth time, you skim it. By the fiftieth, you're hitting yes before the prompt finishes drawing.

That's not a character flaw. That's training. And the agent trained you.

Ask a team what stops their AI agent from doing damage, and the answer is usually a person clicking yes. Komodor's 2026 Agentic Operations Survey (vendor survey, 1,000 engineering leaders) found 75.7% of organizations maintain restrictions on autonomous operations, and human approval for changes is one of the named ones. Guardrails were the top challenge, at 53.6%. I think that click is the weakest gate we have.

The approval becomes the hole

Asking permission feels safe. A human is in the loop, so nothing bad can happen.

But a human in the loop is only as good as their attention. If the agent asks before every file read, every test run, and every tiny edit, you learn one lesson: the prompt is noise. Click through it.

Then one day the prompt that matters shows up. Maybe it's an install from a package you've never heard of. Maybe it's a write to a folder outside the project, or a command that touches credentials. It looks just like the last forty-nine. You say yes.

A tired yes beats a strong deny list every time, because you hand the tired yes out for free.

The fix isn't more prompts. It's fewer prompts that mean more, plus hard walls where no prompt should ever appear.

Three lanes, not one

I sort every action an agent might take into three lanes.

Always allow. Safe, boring, and constant. Let them through without asking, so your attention is still there when it's needed.

Always ask. Actions that reach outside the sandbox or change what's installed. These should be rare enough that each one makes you stop and read.

Never. Actions that should not happen even if you say yes. No prompt, no override in the moment, just a block.

Where these rules live matters as much as what they say.

Put the never lane and the ask lane in the permission layer: the tool's settings and hooks that check every action before it runs. Don't put them in the prompt, and don't rely on a line in CLAUDE.md that says "please don't touch secrets."

Here's why. Instructions in the agent's context can fade. Long sessions get compacted, earlier text gets summarized, and a rule you wrote at the start may not carry the same weight hours later. A hook doesn't fade. It runs the same check every single time.

Keep CLAUDE.md short and use it for guidance on style, conventions, and how the project works. Use deterministic gates for the rules that keep you safe.

Your fence has silent defaults

The guardrail you think you have is not the one you have. A practitioner tested this in r/ClaudeCode and found two quiet gaps. There is no .claudeignore file; Claude Code does not read one, so that file protects nothing. And a PreToolUse hook that exits 1 does not block the tool call. Only exit 2 blocks. A hook that crashes fails open too.

Two more catch people who think they are covered. A deny rule on the Read tool for a secrets file does not stop the agent running cat on it in Bash. And a rule in CLAUDE.md is a request the model can drift from. A hook is the guarantee, and only if it fails closed. Before you trust any of it, test every gate once with the thing it is meant to stop.

The three-lane checklist

Always allow

Reading files inside the repo
Running the test suite
Running linters and formatters
Searching and listing inside the project

Always ask (set in the permission layer)

Installing or upgrading packages
Any network call to an outside service
Writing files outside the repo
Pushing to a remote branch

Never (blocked by a hook or deny rule)

Reading secrets files, keys, or tokens
Using production credentials
Destructive deletes, like recursive removes or dropping tables
Force-pushing over shared history

Your lists will differ. The shape is what matters. Let most actions through without a prompt, ask about only a few, and block a small, firm set outright.

When the agent works the 3AM shift, you won't be awake to approve anything. The gates you set up in daylight are the only ones that count.

Look at your last ten approvals. How many of them did you actually read?

Disclaimer

This post describes my personal experience with my own systems and accounts, in my own words. It is a first-person account of what I observed and what I do in my own work — not a statement of any company’s intentions, policies, or internal decisions. Where I do not know something, the post says so.
I am not affiliated with, endorsed by, or speaking for any company, product, or vendor named in this post. All product and company names are trademarks of their respective owners and are mentioned only to describe the experience accurately.
Any error messages, documentation excerpts, or figures quoted here are reproduced from my own records or from the public sources linked in the post, believed accurate at the time of writing. Product behavior changes over time; verify against current official documentation before relying on any detail.
Nothing in this post is professional, financial, legal, or security advice for your specific situation. Examples are illustrative — validate in your own environment before running anything in production.
Corrections are welcome. If any company named here publishes an official statement, or if any detail is wrong, I will update this post and note the correction. The goal is an accurate public record, not a verdict.