PTN—35
Scoped autonomy
Give the AI explicit, adjustable boundaries — what it may do alone versus what requires a person.
Autonomy is not a slider from “chatbot” to “agent”; it is a permission map. Scoped autonomy makes the map explicit: this agent may read anything in the repo, edit files in this directory, run these commands, and must ask before everything else. The scope is visible to the person, enforced by the system, and adjustable as trust grows. Without it, every agent ships with an implicit scope of “whatever it decides to do,” and the first surprise defines the relationship.
Good scopes are set per capability and per context, not globally. Auto-approve file reads but gate writes. Allow edits in the working directory but not the home directory. Let the marketing agent draft posts but never publish. The unit of trust is the specific action in the specific territory, and the interface should let people grant it at exactly that grain — a blanket “autonomous mode” toggle forces an all-or-nothing bet nobody should have to make.
Scope must be legible before, during, and after. Before: show what the agent is allowed to do when the person delegates. During: when the agent hits a boundary, say so plainly and ask, which is where scoped autonomy hands off to approval gates. After: log what was done under standing permissions, because autonomy granted must remain auditable. A scope people cannot inspect is not a scope; it is a hope.
When to use
- Any agent that takes real actions — files, APIs, purchases — rather than just generating text.
- When users differ: novices want tight gates, experts want standing permissions for known-safe operations.
- When the same agent operates across territories with different stakes — scratch space versus production.
- When you want autonomy to grow with demonstrated reliability instead of shipping maximal by default.
Design considerations
- 01Default to the narrowest useful scope; let people widen it deliberately, never the reverse.
- 02Grant permissions at the grain of action-plus-territory (“run tests in this repo”), not global modes.
- 03Show the active scope before delegation starts, in the same place the person hands off the task.
- 04Enforce boundaries in the harness, not the prompt — a scope the model can talk itself out of is decoration.
- 05Announce boundary hits plainly and convert them into approval requests, not silent failures.
- 06Log every action taken under standing permissions so granted autonomy stays auditable.
- 07Make scope revocation instant and obvious — one control that returns the agent to ask-first.
Pitfalls
- ✕Prompt-enforced boundaries: telling the model “never touch production” in the system prompt and calling it a scope — injection or drift walks right through it.
- ✕The all-or-nothing toggle: one “autonomous mode” switch forces people to choose between constant nagging and unbounded risk.
- ✕Scope creep by accumulation: dozens of one-click “always allow” grants pile up with no page that shows what has been granted, so nobody can audit the blast radius.
- ✕Invisible scopes: the agent has real boundaries, but the person cannot see them, so they either over-trust it or refuse to delegate at all.
In the wild
- Claude Code
- Permission rules allow or deny specific tools and command patterns per project; people can grant standing permission for exact commands while everything else still asks.
- Cursor
- Agent settings include command allowlists and auto-run controls, so routine operations execute freely while unlisted commands wait for approval.
- GitHub Copilot
- The coding agent works inside a scoped sandbox: it can push to its own branch and open a PR, but cannot merge or touch the default branch without human review.
- ChatGPT
- Agent mode operates in an isolated browser environment and asks before consequential actions like purchases — capability boundaries plus in-flight gates.