Give your agents a sandbox before you give them the keys.
Most organizations that try an AI agent start the same way. Someone connects it to the shared inbox, the calendar and the customer records, gives it a broad instruction, and watches what it does. That works fine right up until the agent does something nobody expected, at which point the only real protection is whatever the agent was technically able to reach.
What a sandbox is.
A sandbox is a closed space where software can run without touching anything outside it. For an AI agent, that means a defined set of systems it can see, a defined set of actions it can take in them, and a hard wall around everything else. The agent can still do useful work inside the box. It just can't wander out of it, however its instructions get interpreted.
The idea is old in computing. Browsers have long run web pages this way, so that a bad page can't read the files on your laptop. What's newer is applying it to software that makes its own decisions. An agent picks its next step based on what it just saw, which is the reason it's useful and also the reason its limits need to be enforced by something other than its own judgment.
Why a written rule isn't enough.
Many teams set limits for agents the way they set limits for people: they write them down. The instruction says "only reply to scheduling questions" or "never change an invoice amount," and the hope is that the agent follows it. Usually it will. But an instruction is something the agent reads and weighs, and agents misread things, get confused by an odd email, or follow text planted in a document by someone who wanted them to.
A sandbox works at a different level. If the agent has no permission to edit invoices, it can't edit one, whatever the email in front of it says. We see the same pattern in most teams we work with: the written rules are sensible, and the permissions underneath them are far wider than the rules imply, because the agent was connected with the admin account somebody already had open.
An instruction is a request the agent weighs, and a permission is a wall it can't climb.
Both have a place. The instruction shapes how the agent behaves on a normal day. The permission decides how bad an abnormal day can get.
Start the agent in a copy of the world.
The simplest sandbox is a copy. Before an agent touches the real inbox or the real records, let it run against a test mailbox, a duplicate spreadsheet or a demo account that most software already provides. Feed it last month's real requests (with anything sensitive removed) and read what it does with them.
Say a school district office wants an agent to sort parent emails and draft replies. For the first two weeks, it works on a forwarded copy of the mailbox, and its drafts go to a folder that only the office manager reads. Nothing goes out. At the end, the team knows how often it guessed wrong, which kinds of message confused it, and whether it ever tried to do something outside its job. That last point is easy to miss, and a copy is the only safe place to find it.
When the agent moves to the real systems, widen its reach one step at a time. Let it read before it writes. Let it draft before it sends. Each widening should follow a stretch of evidence that the previous level was handled well, and somebody should decide it on purpose rather than by default.
What belongs inside the box.
A good sandbox for an agent has a few walls, and each one answers a plain question. Which systems can it see at all? Within those, which actions can it take: read, create, edit, delete, send, pay? Which actions need a person to approve them first? And where does it run: on a service your team controls, or somewhere you can't inspect?
Two more pieces turn the box from a fence into something you can manage. The first is a log, a record of every action the agent took and why, kept somewhere the agent itself can't edit. The second is a stop button that a non-technical person can find and press in under a minute. A clinic administrator who notices an agent sending odd appointment reminders on a Saturday morning shouldn't have to call a developer to make it stop.
Five questions to ask a vendor.
More software now arrives with agents built in, and the containment is often decided by the vendor, not by you. Before you switch one on, ask these. A vendor who can answer them clearly has thought about the problem. One who can't is asking you to trust the instructions.
- Can we limit the agent to specific systems, folders and actions, and is that limit enforced by permissions rather than by its prompt?
- Can we run it against test data or a copy of our accounts before it touches anything live?
- Which actions can it take without a person approving them, and can we change that list ourselves?
- Where is the record of what it did, how long is it kept, and can the agent alter it?
- How does someone on our team stop it immediately, and what happens to work it had half finished?
Write the answers down next to the name of the person who asked. When the tool changes its features next year, which it probably will, you will want to ask the same five questions again and compare.
