A workspace where an agent may be wrong

Agents will get things wrong. Not maybe, but certainly, sooner or later: they misread the goal, read the wrong file, or run the right command in the wrong place. So the first preparation before an agent touches anything is a sandbox: a separate workspace where a mistake only breaks things you can throw away.

Its form depends on the work:

• For documents: a test folder holding copies of files, not the real team folder.
• For code: a separate checkout of the code per task, for example its own branch and working directory, so two agents never overwrite each other and changes can be discarded with one command.
• For databases: a throwaway database in a container, on its own port that nothing else uses, filled with sample data or a disguised copy.
• For outside services: a test account or the provider's test mode, not the account customers use.

A good sandbox has two properties. First, it can be rebuilt in minutes, so you do not hesitate to throw it away when it breaks. Second, it has no path to real data, except what you deliberately give. The second property is the one that leaks most often, usually not through a permission you granted, but through a default you did not notice.

Many programs have a default that is used when a setting is empty. The most common example: the database address. If the environment variable for the database address is not set, the program uses a default address, and that default is often the development database on your own machine, holding weeks of work data.

Now imagine an agent running tests that, as setup, empty the database. If the address is set explicitly to a throwaway database, there is no problem. If it is forgotten, the tests fall back to the default address and empty the wrong database. The agent did nothing malicious; it ran the right command with an empty setting. That is what happened in this lesson's case.

The rule: every environment variable that decides where the agent writes is set explicitly, in the same command as its task, not relied on from a local settings file or an earlier session. Better still, change the program so it refuses to run when the address is empty, instead of falling back to a default. This is part of the principle of least privilege: the agent can only reach what was given for this task.

One more small habit: write in the agent's instructions the places it must never touch, for example "never use the database on the default port, never write to the team folder". Instructions like this are not a reliable fence, because a model can misread or be misled by other text, but they help the agent refuse before trying. The real fence stays in the environment itself: narrow permissions and addresses set explicitly. The two together are much stronger than either one.

Finally, note the test environments you create: their name, which task they serve and how to throw them away. A forgotten environment slowly gets used for other things and stops being a safe place to be wrong.