Stop your AI agent from going rogue: 7 guardrails that actually work

The core problem

"Going rogue" is rarely dramatic. It is a series of small, plausible-looking decisions that add up to a disaster. Guardrails work because they interrupt that chain early.

1. Scope pinning

Before an agent edits anything, it must restate the task in its own words and list the files it plans to touch. Reject the plan if the list is empty or wildly larger than the task.

2. Read-only zones

Mark files that are dangerous to modify — auth logic, billing, migrations, secrets. The harness refuses writes, not the model. Trust the enforcement, not the intention.

3. Command allow-lists

Do not give a shell. Give a curated set of commands. bun test yes; rm -rf no. Every new command is a conscious decision.

4. Diff budgets

Cap the size of any single change. A "small fix" that touches 40 files is not a small fix. Force the agent to explain or split.

5. Structured memory, not chat history

Chat scrollback is not memory — it is noise. Persist decisions and constraints in structured, queryable memory that survives session resets.

6. Explicit failure modes

Tell the agent what to do when it does not know. "Stop and ask" is a valid answer. Silent guessing is the enemy.

7. Human checkpoints

Some actions — pushing to main, running a migration, calling a paid API — require a human tap. This is not micromanagement, it is operational sanity.

Putting it together

Each guardrail on its own helps a little. Layered, they produce agents you can leave running overnight without dread. That layering is exactly what Loop-OS ships as a default.