How should scope be written?

As an explicit list of permitted actions, with everything not on it excluded by default. That fails safely when something unanticipated comes up, whereas a list of prohibitions leaves the unimagined cases available and those are the ones that matter.

How does scope widen without anybody noticing?

Through ordinary helpfulness. A new integration is enabled, an existing credential is reused because it was to hand, a permission is granted on a Friday to unblock somebody, and none of those is recorded anywhere as a change to what the agent may do.

What should we review, and how often?

What the agent could do, not what it has done. Past actions describe the conditions that happened to arise; the possible set is what determines the worst case, and reviewing it takes minutes if somebody keeps the permitted list current.

Glossary

Scope of action

The set of things an automated system is permitted to do, decided by the access it holds rather than by the instructions it was given.

In plain terms

What the system is actually able to do, as opposed to what you asked it to do. Those are different lists, and only the first one constrains anything, because instructions describe an intention and access describes a capability.

Why it matters

Because most thinking about agent safety happens in the prompt, and the prompt is the part that does not bind. An agent asked politely to be careful with a system it has full access to is a hope; an agent without the access is a constraint.

How it works

Scope is what the credentials permit, not what the instructions request. A carefully worded prompt narrows behaviour on a good day and does nothing on a bad one, so the useful question is always what would happen if the instruction were ignored.

It has to be a list of what is allowed rather than a list of what is forbidden. Prohibitions require you to have imagined every bad action in advance, and the actions that cause trouble are reliably the ones nobody thought to name.

Read and write deserve separate treatment. An agent that can read widely and write in one place is a very different proposition from one that can write wherever it can read, and the second is what happens by default when access is granted as a single thing.

Reversibility is the useful axis for deciding what needs more control. Sending a message, deleting a record and moving money are not the same kind of act as drafting a document, and grouping actions by how hard they are to undo produces a shorter and more defensible list.

Scope widens without anybody deciding to widen it. A tool gains an integration, a credential is reused because it was already there, a permission is granted to unblock somebody on a Friday, and none of those is recorded as a change to what the agent may do.

The check worth running periodically is what the agent could do rather than what it has done. A log of past actions describes behaviour under the conditions that happened to arise, and the question that matters is what remains possible.

Two things people call scope

The reason the left-hand column absorbs the attention is that it is where the interesting work is. Writing careful instructions is a craft, it produces visible improvements, and it feels like the thing you are supposed to be doing. Adjusting permissions is administrative, it involves somebody else's system, and it produces no observable improvement on any ordinary day. So the instructions get better and better while the access stays as broad as it was on the afternoon somebody set it up in a hurry. The correction is a single question asked at design time and repeated whenever anything changes: if this system ignored every word of its instructions, what could it still do. If the answer is uncomfortable, no amount of further work on the prompt addresses it, and the work that does address it can usually be finished in an afternoon by whoever administers the systems involved.

Seen in the wild

An agent given a broad credential because narrowing it would have taken an afternoon.
Lindy
An automation that can read from everywhere and write to one reviewed place.
Make
A coding agent allowed to propose changes but not to apply them anywhere shared.
Claude Code

Common misconceptions

People assume

The instructions define what it will do.

In fact

They describe what you would like. Access defines what is possible, and the difference only becomes visible on the day the instructions are misread, contradicted or successfully argued around by something the agent read.

People assume

A list of forbidden actions is enough.

In fact

It requires having imagined every harmful action in advance, and the ones that cause real trouble are the ones nobody thought of. A list of permitted actions fails safely; a list of prohibitions fails in whatever direction was not anticipated.

Questions

How should scope be written?: As an explicit list of permitted actions, with everything not on it excluded by default. That fails safely when something unanticipated comes up, whereas a list of prohibitions leaves the unimagined cases available and those are the ones that matter.
How does scope widen without anybody noticing?: Through ordinary helpfulness. A new integration is enabled, an existing credential is reused because it was to hand, a permission is granted on a Friday to unblock somebody, and none of those is recorded anywhere as a change to what the agent may do.
What should we review, and how often?: What the agent could do, not what it has done. Past actions describe the conditions that happened to arise; the possible set is what determines the worst case, and reviewing it takes minutes if somebody keeps the permitted list current.