How do you limit what an AI agent can change?

There are two kinds of restriction and only one of them holds. A stated restriction shapes the plan the agent forms, which is genuinely useful and is why boundaries belong in the brief. An enforced restriction makes the action impossible, and it is the only one that survives a misunderstanding, an unusual situation, or a long run where the original instruction is no longer prominent. Designs that rely on the first alone work until the day they are actually needed.

The strongest enforced control is location. An agent operating on a copy, in its own directory, on a branch, in a container, or against a test account cannot damage anything outside it regardless of what it decides. This is a stronger guarantee than any permission list because it does not depend on enumerating the things you want protected — an exercise that always misses something, since the things you forget are exactly the things you do not think of.

The second is the tool list. An action that has no tool cannot be taken. This is worth stating plainly because it is frequently overlooked in favour of instructions: an agent with no delete tool will not delete, whatever it concludes, and an agent with a delete tool and an instruction not to delete is one confusing situation away from deleting. Keeping the tool list short also improves ordinary performance, since selection accuracy degrades as options multiply.

The third is the account. Running the agent under an identity with narrow permissions moves the limit into the systems themselves, which means it is enforced by things you do not control and cannot accidentally reconfigure in a hurry. It also makes the boundary auditable: what the agent can reach is a question with an answer, which is not true of an agent running as a person.

The fourth is reversibility, which is a different kind of control and is often the most practical. Version control, an append-only log, soft deletion, a snapshot before the run. These do not prevent a change; they make it cheap to undo, which is what actually determines how much autonomy is safe. A great deal of freedom is affordable inside a system where every change can be reverted in one command, and almost none is affordable where it cannot.

Two failure patterns are worth naming. Granting broad access because scoping is fiddly, which is how nearly every over-permissioned system arrives at its state, one reasonable decision at a time. And treating a successful period as grounds for widening the limits, when what the period demonstrated is behaviour on the inputs that happened to occur. Widen when the evidence changes — a check now runs, a rollback now works — rather than when the goodwill accumulates.