Every engineer has a production horror story. The interesting question isn't why it happened. It's why we keep building systems that let it happen.

There's an old saying about Unix: it was designed to deliver Mr. Bullet to Mr. Foot as efficiently as possible. You ask it to do something, it does it. No questions asked. That's power. That's also how you accidentally drop a production database on a Tuesday afternoon.

RBAC and just-in-time permissions are not just security features. Yes, they protect against outside intruders. But another part of their job, the one that saves you on a regular Tuesday, is protecting competent people from their own inevitable mistakes.

What engineer has worked for any length of time and not accidentally pointed at production when they meant dev? A typo in an environment variable. A tab with the wrong cluster selected. A script that defaulted to the wrong context. These aren't signs of incompetence. They're signs of being human and doing complex work under time pressure.

This maps directly to AI agents. The same logic that protects engineers from their own typos protects agents from theirs: a capable actor doing complex work fast still mistypes a path, picks the wrong context, runs the right command in the wrong place. Permissions give them a survivable margin for error. A well-designed system slows things down just enough to prevent catastrophes, making "are you sure?" cheap and "oops" recoverable.

The question isn't "do I trust this agent?" It's "have I built the system so that a mistake doesn't take down the building?"

Guardrails, permissions, and deterministic checkpoints aren't the brakes that slow you down. They're the brakes that let you go faster with more confidence. A car without brakes isn't fast. It's a projectile.

Related reading: