A Simple Checklist Before Letting an AI Agent Touch Real Work

There is a big difference between letting an agent organize your bookmarks and letting it near customers, money, or anything public with your name on it. Real work means real consequences, and agents need a safety setup that matches. This checklist covers the twelve things to verify before an agent touches anything that matters. Run through it once per task setup — it takes fifteen minutes and prevents the failures that take weeks to clean up.

Permissions and access

An agent can only damage what it can reach. The most effective safety measure is also the simplest: give it the smallest access that lets it do the job. An agent that drafts invoices does not need permission to send them. An agent that reads a shared drive does not need write access to it.

• The agent has read-only access wherever reading is all the task needs.
• It cannot send email, publish, pay, or delete anything without your explicit approval per action.
• Its access is scoped to specific folders, accounts, or projects — not your entire system.
• You know exactly which credentials or API keys it uses, and you can revoke them in one place.

Instructions and limits

Vague instructions plus broad access is how agent incidents happen. Before real work, the instructions should be written down, reviewed, and tested — not improvised in a chat box five minutes before the run.

• The goal, constraints, and output format are written explicitly, not implied.
• There is a stuck rule: what the agent does when something is unclear or a step fails.
• Hard limits are set: maximum steps, maximum cost, and a time box for the task.
• The agent has completed at least three trial runs on low-stakes versions of the task without needing correction.

Oversight and rollback

Even good setups fail occasionally. The question is whether you notice quickly and can undo the damage. Oversight means you see what the agent did; rollback means you can reverse it. Both need to exist before the agent touches real work, not after the first incident.

• You receive a completion report for every run: what was done, skipped, and assumed.
• You can review a log of the agent's actions, not just its final output.
• There is a way to undo the agent's changes — version history, backups, or draft states.
• Someone is responsible for checking the agent's work on a schedule, even when it seems to be going well.

After the first real run

The checklist doesn't end at launch. Treat the first few real runs as an extended trial: review everything, keep notes on every surprise, and tighten the setup after each one. Most teams discover that their instructions need two or three rounds of fixes before the agent is genuinely reliable — usually around edge cases nobody thought to specify. That is normal. What matters is that the surprises happen while you are watching closely, with rollback ready, rather than months later when nobody is checking.

• Review the first five real runs completely, not just the summaries.
• After each surprise, add one instruction or limit that would have prevented it.
• Widen the agent's scope gradually — one new responsibility at a time.
• Re-run this checklist whenever the task, tools, or permissions change.