Scoping, approval and isolation

The moment you give a model tools, you have given it a hand on your machine. The difference between a useful agent and a disaster is not the model's intelligence, it is how carefully you scoped that hand.

The three rules

Scope what it may touch. The agent should see one project, one directory, one account, not your whole disk and every credential. The narrowest scope that does the job is the right scope.
Require approval for anything irreversible. Writes, deletions, network calls, payments: pause and ask. Read-only actions can be automatic; anything with consequences should wait for you.
Isolate it. Run the agent in a container or a VM, or at least a dedicated account with limited rights. Assume it will eventually do something wrong, and make "wrong" cheap to recover from.

The mindset

Treat an agent the way you would treat a very fast, very confident junior colleague you just gave a keyboard: you would not hand them root and walk away. You would scope their access, review their work, and keep a backup.

The concrete safeguards

One-way mirrors and backups. Several setups in the catalog keep the agent's files on a separate volume with a backup, so "it deleted my work" is a non-event.
Environment variables, not secrets in files. Give the agent what it needs per task, never your global credentials.
Log everything. A log of what the agent called and changed is how you debug "why is my repo different."

Why this is a method, not a setting

Security here is a habit, not a checkbox. The method track returns to this: before you build, you decide what the agent may touch; while you test, you watch what it actually did; after, you keep the trace. That is the same discipline as designing an app, applied to an agent.

The catalog has a recurring pattern: the setups that let an agent touch their machine all describe their guardrails. Copy those, not just the hardware.