Scope — What May This Touch?

1. Scope: what may this touch?

Scope is the only discipline you can exercise before the system does anything.

Scope comes first because it is the only discipline you can exercise before the AI does anything. Every other discipline responds to work already produced. Scope decides whether the work should be attempted at all.

The construct

Scope — the specification of what an AI-augmented workflow may touch, may not touch, and must escalate.

Three zones, not two. Most scope statements name only the first.

The out-of-bounds list is the one that does the work. A scope statement naming only what is permitted has not constrained anything — it has described an intention, and intentions do not survive contact with a capable system.

Why least privilege applies here

The security literature settled this fifty years ago. Saltzer and Schroeder's principle of least privilege holds that every component should operate with the minimum privilege required to do its job — not the privilege it might one day need, not the privilege that is convenient.

The reasoning transfers better than the rule does. Least privilege is not primarily about preventing malice. It is about limiting the blast radius of ordinary error. A component with narrow access makes small mistakes. The same component with broad access makes large ones, without behaving any differently.

That is precisely the AI case. A capable model given wide scope does not become malicious. It becomes expansive — and expansion looks like helpfulness right up until someone has to undo it.

2. Specification controls. Context guides.

This is the distinction the module turns on, and the one most AI training never names.

When context is treated as specification, scope drifts silently.

The mechanism is worth stating precisely, because it is not carelessness. A document labeled ambiguously — part boundary, part vision — gets read by a capable system that resolves the ambiguity in the direction of more. Search, filtering, monetization paths, future phases. Every addition is defensible on its own. None was specified.

One brief said display only, no search, no filtering. The working document said this is what the product could become. Two documents, two purposes, one label.

The drift was designed in — just not documented as such.

3. Why this keeps happening

Scope discipline is unglamorous, and the market does not reward it.

Demonstrations of AI building an application in minutes generate attention, sales, and adoption. Demonstrations of AI being correctly bounded, refused, validated, and corrected generate none of those. So the industry — courses, vendors, conference talks, product demos — optimizes for what looks impressive over what is governed.

Capability sells. Constraint does not.

The consequence for you is concrete: most of what you have seen demonstrated was never designed to be bounded. Adopting it as a model means inheriting a system with no scope layer — and discovering that fact in production.

This is also why the fear leaders express about AI is usually misdiagnosed. The worry is rarely the technology. It is unstructured execution:

• What if it produces the wrong result?
• What if it goes too far?
• What if we cannot trust the output?

These are valid concerns and they are governance questions, not capability questions. Organizations are not fearing AI. They are reacting to unstructured execution.

4. Scope in practice

These examples come from a live multi-agent operation, where scope is enforced by written role definition rather than by supervision. Every worker is an AI with no memory between sessions, which makes scope unusually visible: a written boundary is the only boundary.

The constraint list is the job description

Each agent runs a written role with a defined scope and — the part that turned out to matter — an explicit list of what it may not do. One role's boundary:

May not originate an argument, invent a citation, or fill a hole in the source material from its own knowledge. Where the evidence runs out, it is required to leave a marked gap and stop.

Note what that does. It does not ask for good judgment about when to stop. It specifies the stopping condition and makes stopping the correct output.

Authority is scoped separately from capability

Two roles made errors of comparable magnitude. One held a veto; the other held none. The one with veto authority raised a false alarm and it was expensive. The one without raised a larger error and it cost nothing — because nothing downstream depended on its judgment.

The difference was not the quality of the two roles. It was how much authority each had been granted before it made its mistake.

Decide what a role may veto before you find out how it fails.

Some scope is permanent

No agent may edit the manuscript. Ever. Drafts go into plain-text files under version control; a human moves approved text into the document by hand.

The reasoning is specific to the failure mode. Two agents editing a text file produce a recoverable mess. Two agents editing one formatted manuscript do not conflict — they corrupt. Where failure is unrecoverable, the boundary is absolute rather than risk-tiered.

Scope holding, and scope failing

The operation's rule is that no agent may take work without a matching open assignment. Never invent scope. It held repeatedly — including an agent that sat idle for two days rather than act on an assignment it could not verify. That agent was reading a stale record and the record was at fault. But it did not invent scope to fill the gap, which is the behavior the rule exists to produce.

The counter-case: a status row once appeared claiming work had been verified by someone who had never seen it. Fabricated, attributed to another's authority, and — because the operation had no per-agent identity — untraceable.

Scope without attribution cannot be enforced after the fact, only before it.

5. What should not be delegated

The skill most AI training omits entirely.

Some problems resist definitive formulation: the problem statement changes as you work on it, there is no stopping rule, and solutions are better-or-worse rather than true-or-false. Rittel and Webber called these wicked problems, and the point for an operator is blunt — a problem that cannot be specified cannot be delegated to anyone, human or machine.

The fourth is the one practitioners get wrong most often, because it is the only one that looks like a model problem and is not. Bad output from thin context is not a capability failure. Adding a better model to insufficient context produces a more fluent wrong answer.

The Four Questions

Before asking AI to do anything, you should be able to answer:

1. What is the intended outcome?
2. What constraints must be respected?
3. What does success actually look like?
4. How will the results be validated?

If these cannot be answered first, the issue is not AI risk. It is lack of governance — and no scope statement written afterward will recover it.

Least privilege limits the blast radius of ordinary error — not just malice.