What the Agent Must Never Do
Explore how to define and enforce authority policies that specify permitted and forbidden actions for AI coding agents. Understand the importance of separating read, write, and command permissions, managing secrets securely, and requiring approvals for irreversible operations. This lesson helps you build safeguards that keep AI agents reliable and prevent unintended destructive actions within software sessions.
We'll cover the following...
- Why did a correct repair need a destructive command?
- Isn’t this what a sandbox solves?
- What must an Authority Policy decide?
- Which actions are irreversible?
- How should a secret reach the agent without entering the repository?
- Why must a denial produce a receipt?
- Who can widen authority, and for how long?
- Can you hold the boundary under pressure?
- What can you add to your own harness today?
- How do you test the policy?
- What’s next?
Wrenfold’s agent picked up CLIN-530, the ticket that makes appointments respect provider time off. Its ledger row was active, its Scope Contract was current, and its first repair was correct.
The end-to-end command then failed for an unrelated reason: the local database had no time_off table. The agent read package.json, found a db:reset script, and ran it. The script reads DATABASE_URL from .env. Someone had pasted the clinic’s live connection string there four months earlier.
The command dropped and recreated the appointments table. It removed 1,412 real bookings.
The agent then left a helpful note in its checkpoint so the next session would not hit the same wall. The note contained the full connection string, user, and password included, committed to the repository.
Both steps were reasonable moves toward the ticket. Neither was an action anyone had decided the agent could take.
Why did a correct repair need a destructive command?
Because the blocker was real. The schema was genuinely stale, and resetting a development database is genuinely how engineers fix that.
The agent had no way to tell the two databases apart. db:reset is one script name. DATABASE_URL is one variable. Which rows that variable points to is a fact about deployment, and no part of the repository told the agent which fact was true today.
The model reasoned correctly from what it could see. What it could see included a live credential and a command that consumes ...