Running agents safely

AI agents are fast, which means a bad instruction turns into a lot of edits quickly. Operon gives you several layers of control so a run stays inside the lines — and so that when something does go wrong, it is caught, paused, and recoverable rather than discovered later in the diff. This page is the short version of how to use them together.

Set a scope boundary for the session

The single highest-value habit is telling Operon which files the agent is allowed to touch. You set a scope as glob patterns when you create the session. If the agent writes outside that boundary, Operon pauses the terminal and reverts the out-of-scope change — but non-destructively: the pre-revert content is snapshotted to a quarantine area first, so you can review it and restore it if the change was actually wanted.

• Enforce mode pauses the agent and reverts out-of-scope writes, keeping the original in quarantine so nothing is lost.
• Warn mode surfaces the violation without reverting — good when you want a heads-up but not a hard stop.
• Off means no boundary — use it only when you genuinely want the agent to roam the whole repo.
• A revert is never final: approve a flagged change to restore it from quarantine if the agent was right to make it.

Gate risky steps with the Harness

For work that moves in stages, use checkpoint gates. Between plan steps the Harness snapshots the repo, pauses the agent, and shows you a review panel with the diff and a confidence score before the next step runs. You approve, reject, or roll back to an earlier checkpoint. This turns a long autonomous run into a series of small, reviewable increments instead of one big leap you only see at the end.

• Confidence scoring weighs factors like file count, scope boundary, and token utilization so you know how risky a step is before approving it.
• Rejecting a checkpoint rolls the step back — the agent does not get to keep changes you did not accept.
• Roll back to any earlier checkpoint if a later step went in the wrong direction.

Apply a governance policy

When you want rules that hold across every session — yours or a teammate’s — use a policy. A policy is one declarative document that can protect paths, forbid specific commands, cap spend with budgets, and require a test gate. Operon enforces it hard: an edit to a protected path is reverted and logged, a forbidden command pauses the session, and a session that hits its budget ceiling is stopped. Every enforcement is written to an audit trail so you can see what was blocked and why.

Write a clear, specific goal

A lot of unsafe behavior starts with a vague instruction. When you type a goal for a new session, Prompt Copilot scores it and suggests improvements — it rewards concrete file references, action verbs, a stated outcome, and a defined scope, and flags ambiguous pronouns or missing testing intent. A goal that scores well gives the agent a narrow target, which is itself a safety measure: the more precise the ask, the less room there is to wander.

• Name the files or area you want changed instead of saying "the code".
• State the outcome you expect and how you will know it worked.
• Say what is out of bounds, then back it up with a scope boundary.

Isolate experiments with a worktree

For anything speculative — a risky refactor, a new agent you have not used, or a change you are not sure about — run the session in an isolated git worktree instead of your main working tree. The agent gets its own checkout to edit, so a bad run cannot touch the branch you are actually working on. If the experiment pans out you fold it in through the Changes workbench; if it does not, ending the session preserves any uncommitted work rather than destroying it.

• In-repo runs directly in your working tree — simplest, least isolated.
• New worktree gives the session its own checkout so nothing touches your main tree.
• Pooled reuses a warmed worktree for faster startup.
• Ending a worktree session with uncommitted changes preserves the worktree — your work is never silently deleted.

Before you launch

A quick checklist that fits most sessions — the more of it you do up front, the less you have to intervene mid-run.

1. 1

   Write a specific goal

   Name the files or area, state the outcome, and let Prompt Copilot nudge the score up before you launch.

2. 2

   Set a scope boundary

   Add glob patterns for exactly where the agent may write, and use enforce mode so out-of-scope edits are paused and reverted (safely, into quarantine).

3. 3

   Isolate if it is risky

   Choose a worktree for anything speculative so a bad run cannot touch your main working tree.

4. 4

   Turn on checkpoints for staged work

   Use the Harness so each plan step is reviewed with a diff and a confidence score before the next one runs.

5. 5

   Lean on policy for the rules that always apply

   Let a governance policy enforce protected paths, forbidden commands, budgets, and the test gate across every session automatically.

Related pages