Automation Loop Setup: Let AI Run on Your Real Files — Safely

Guardrail 1 — Least privilege: scope the agent to one sandbox folder

The default instinct is to give the agent access to everything so it can “just work.” Resist that. The more surface area it has, the more places a mistake can land.

Instead, create a single dedicated folder — call it ai-sandbox, agent-work, or whatever you’ll remember — and make that the only directory the agent is allowed to touch. Anything outside it is off limits.

In practice:

• Create the folder and put only the files relevant to this task inside it.
• When you configure the agent (or write its system prompt), explicitly name the folder: “You may only read and write files inside /projects/ai-sandbox/. Do not access any path outside that directory.”
• If the agent uses a connector to Google Drive or a filesystem tool, restrict the connector’s scope to that folder during authorization — don’t grant full Drive access if the connector supports folder-level scoping.

This won’t stop a determined mistake, but it dramatically shrinks the blast radius of an accidental one.

Guardrail 2 — Make every change reversible before the agent starts

Agents move fast. If you don’t have a recovery path, you’re one bad run away from losing work. Set up your undo layer before you start, not after something goes wrong.

Pick one of these depending on what you’re working with:

• Version control (best option): if your sandbox folder is a git repo, every agent run is a distinct set of changes you can inspect and revert with git diff and git checkout. Commit the starting state before each agent session so you always have a clean rollback point.
• Working copy: if git feels like overkill, duplicate the folder before each run — ai-sandbox-backup-2026-06-19 — so you have an untouched snapshot to compare against or restore from.
• Versioned storage: if your files live in Google Drive or Notion, enable version history before the agent session. Both platforms keep previous versions for 30–180 days depending on your plan.

The goal is that no matter what the agent does, you can get back to where you started in under a minute.

Guardrail 3 — Approve on write: the agent proposes, you decide

This is the highest-leverage guardrail because it stops problems before they happen rather than cleaning them up after. The idea: configure the agent so it shows you what it plans to change and waits for your explicit sign-off before writing anything.

How you implement this depends on your setup:

• In the system prompt: tell the agent to describe every write operation before performing it and wait for you to say “go” or “approved.” Simple and works everywhere.
• In agentic frameworks (LangChain, Claude’s computer use, custom loops): most have a “human-in-the-loop” or confirmation step you can insert before any tool call that touches the filesystem. Enable it.
• For batch operations: ask the agent to output its full plan as a numbered list first. Review the list, strike anything you don’t want, then say “proceed with items 1, 3, 5” — it runs only those.

Yes, this adds a confirmation step per write. That’s the point. Once you trust the agent’s behavior on a given task, you can relax this constraint for that specific workflow — but start with it on.

Putting it together: the pre-flight checklist

Before you kick off any agent loop against real files, run through these three checks:

1. Sandbox in place? Agent is scoped to one folder and nothing outside it.
2. Snapshot taken? Git commit, working copy, or version history enabled — clean state is recorded.
3. Approve-on-write active? Agent will describe changes and wait for your go-ahead before touching anything.

All three green? Run the agent. None of this slows the work down in a meaningful way once it’s set up — it just means you’re in control of what actually lands on disk.

Common mistakes

• Skipping the snapshot “just this once” — this is always the run that goes sideways.
• Granting broad connector access “so it has everything it needs” — narrow the scope first, expand only if the task genuinely requires it.
• Approving in bulk without reading — if the agent lists 12 changes and you say “approved” without scanning them, you’ve disabled the guardrail. Read the list.
• Running the full automation before testing it on one file — always do a single-file dry run first to confirm the logic is right before letting the loop loose on a folder of 200 files.