AI agents touch vast areas of my work now. They write code that touches thousands of users. They analyze revenue data, run experiments, monitor systems and act on them. They have database, file system, deployment access.
Most people hear this and ask: "Aren't you worried?"
No. But not because I trust the agents.
The Conversation is Stuck Between Two Bad Answers
A: Review everything manually. This works until you realize you've replaced one bottleneck with another. At some point you're clicking without reading, and the safety becomes theater.
B: Let the AI operate freely. Skip reviews. Claude Code even has a flag for this: --dangerously-skip-permissions. I use it daily. It removes every safety check, every confirmation and permission prompt. The AI executes anything it decides.
Categorical vs Contextual Risk
The key insight: not all dangerous actions are equally dangerous.
Some AI actions should never happen regardless of context. Dropping a production database, reading SSH private keys. These are categorically dangerous. No scenario justifies them and no context changes the answer.
Other actions are dangerous in most contexts but sometimes necessary. Force pushing to a feature branch, deleting a build directory, writing to environment files. These are contextually dangerous.
How to resolve? Build a system that classifies agent actions into two buckets:
Hard blocks for categorical risks. These can never be overridden. Not by the AI. The override path simply doesn't exist for the AI. We run 43 hard blocks — no override exists, not even for me.
Soft blocks for contextual risks. These require explicit confirmation and are granted through time-expiring permissions. The permission disappears automatically. No forgetting to revoke it. We have 21 soft blocks that require confirmation and auto-expire in one hour.
If everything is blocked, you can't work. If everything is allowed, you can't sleep. The categorical/contextual split forces you to make the classification decision carefully, and the system enforces it permanently.
The Guard Guards Itself
Every security system has one vulnerability: the entity that can turn it off.
When that entity is an AI agent with full access, self-protection is the first thing you build, not the last. The key design: the AI can't modify its own guardrails. Any attempt to edit the safety system is hard blocked.
If the AI tries to edit the safety system — hard blocked. If it tries to change the config that loads it — hard blocked. If it tries to touch the permissions helper — hard blocked.
The Full Stack
The guardrails are one layer. The full stack:
- Branch isolation — AI never touches production directly
- Read-only database — writes need an audit trail
- Credential scanning — catches API keys before they're written, not after
- 78 automated tests validating every pattern
No single layer is enough. Combined, they make catastrophic errors structurally impossible.
This Philosophy Drives How We Build Product
At Frase.io, Content Watchdog monitors your content rankings across Google, ChatGPT, Perplexity, Claude, and Gemini. When rankings drop, it doesn't send you a notification and wait. It diagnoses the cause and applies fixes within the boundaries you've set.
It won't publish without your review. It won't delete content. It won't override editorial decisions.
The Pattern
- Define what "autonomous" actually means in your context
- Classify every risk as categorical or contextual
- Engineer the boundaries precisely
- Let the AI operate at full speed inside them
Most teams debate whether to let AI touch production. That's the wrong question.
The right question: have you done the engineering to define what the AI can and can't do?
Once you have that, the speed follows.
Speed and safety aren't opposites. Speed requires trust, but the trust is now a function of engineering. The question is whether you've done the engineering.