Guardrails: permissions and what not to automate

Across the whole curriculum you'll see this pattern repeat (it's the same logic behind human-in-the-loop design for AI systems generally): the right amount of human review scales with blast radius (how much can go wrong, and how visibly) and reversibility (how easily you can undo it if it does). A typo fix has tiny blast radius and is trivially reversible with version control — low review need. A schema migration that drops a column has large blast radius and may not be reversible at all once it runs — high review need, always.

• Version-controlled code changes — generally safe to let an agent iterate on with a final diff review, since git gives you an undo button
• Destructive filesystem or database operations — deletions, drops, truncations — should always pause for explicit confirmation, regardless of how routine the agent's plan claims it is
• Anything touching secrets, credentials, or auth logic — deserves a human look even when the diff is small, because the cost of a subtle mistake here is disproportionate to its size
• Commands that reach outside your machine — deploying, pushing to a shared branch, calling a paid external API, sending real emails — should require a conscious "yes," not happen as a side effect of a broader task
• Anything in production — a categorically higher bar than local or staging work; most teams should never let an agent apply changes directly to production without a human-approved step in between

Many agentic tools run commands in a constrained environment — restricted filesystem access, limited or no network access, no ability to touch certain system calls — precisely so that a mistaken or even malicious command does less damage than it would unrestricted. Understanding that your tool has a sandbox (and what it does and doesn't cover) is worth five minutes of reading its documentation once, rather than discovering the boundary the hard way.

If an agent runs a destructive command because you (or a task description) told it to, the fact that it was "just doing what it was told" doesn't undo the damage. The responsibility for scoping a task safely sits with the person writing the task, the same way it would if you delegated the same instruction to a new hire without checking their judgment first. This isn't a reason to avoid autonomy — it's a reason to be deliberate about where you grant it.

When you're unsure whether a task needs a checkpoint, default to reviewing the diff before it takes effect. The cost of an unnecessary review is a few extra seconds. The cost of an unreviewed mistake — especially anything destructive or hard to reverse — is usually much larger than the time saved by skipping the review. Loosen the default only for task categories where you've deliberately decided the tradeoff favors speed.