Match autonomy to blast radius

Start from a finished task. In this course’s illustrative scenario, the change to shared-lib, the course’s illustrative internal library, imported by about a dozen services, is shipped: a configurable approval-threshold check and a new approval-requested audit-event type. You ran it in the Agent role (Copilot’s role that edits files and runs commands) on Manual permissions, read every consequential action at each approval (the run the checkpoint lesson walks through), and the change went out without breaking a single one of the dozen consumers. That is the riskiest change in the course, made under the tightest control the tool offers. Now step back and name what you actually did, because the next repo asks the opposite of you.

The same dial, turned two ways

What decided your permission level was not how hard the library change was. The code was modest - the same audit-event type and threshold rule. What made it demand Manual permissions was blast radius plus a mistake that would take real work to walk back: twelve services downstream, and the hard-to-undo part is not the git edit (that is one checkout) but the published release those services pick up. The dial below - two questions, one recommended rung - has a cell for git-tracked shared-library edits, and it says let the edits flow and gate the publish; choosing Manual for the whole session is the one-lever version of that same answer - both the edits and the publish stay behind review. High stakes, short leash.

Now picture the work waiting in orders-service, the order service your squad owns: building the approval workflow on top of those new helpers. It is a bigger job - more files, more moving parts. But for this task both questions land easy - a change you can fix forward, with nobody downstream. Low stakes here means easy answers for this task, not a property of the repo: flip either axis (a costly-to-undo mistake, a shared surface) and the rung moves even inside your own app. With both answers easy, there you loosen the dial - Allow all, let the Agent role run without stopping at each action, review the whole change at the end - inside a fence you choose: a branch you own (when the worst action is a tracked-file edit), a throwaway worktree, a sandboxed run. Allow all removes the prompts; the boundary has to come from somewhere else. The no-prompts-no-fence rung is the one the dial never recommends on a real machine - it belongs to disposable environments. The interruptions that protected you on the library would be friction here.

Same engineer. Same week. Same feature, even. Opposite permission settings - and the thing that flipped them was never difficulty. It was what a wrong answer would cost.

	shared-lib	orders-service
Consequences of a wrong action	High - 12 consumers, hard to undo	Low - your app, fix forward
Permission level	Manual permissions - review every consequential action	Allow all - let it run, inside a fence (branch, worktree, sandbox)
Your posture	Tight: short leash, close watch	Loose: long leash, review at the end

That table generalizes past these two repos. The same two questions size up any task you will ever hand an agent - set them for the library (real work to walk back, twelve consumers downstream), then flip both for your own service, and watch the recommended rung swing from near one end of the ladder to near the other without difficulty ever entering into it. The dial’s strict end - read and propose only - is the Ask role (a role choice, not a permission level); the edits-flow, commands-gated middle is the manual default with edits added to your tool-approval auto-approve rules - Copilot names levels at the ends and realizes the middle through per-tool approval settings, per the approvals documentation as of September 2026:

Two questions decide how much leash a task earns - neither of them is “how hard is it.” Set both for the work in front of you and read the rung it lands on.

If the agent’s worst single action went wrong, undoing it would take…

a git checkoutthe change lives in tracked files; the floor holdsreal worka migrated database, regenerated files, a rebased brancha miraclea send, a deploy, a delete with no backup

…and its consequences would reach

your working copyone repo, one machine, nobody downstreamwhat the team sharesa library others consume, common infra, shared databeyond the machineproduction, customers, money, the public

1. Run free, no fencedisposable environments onlyNothing pauses it and nothing contains it. No combination on this dial lands here - it belongs only where the whole environment is disposable: a throwaway container, an already-isolated CI runner.
2. Run free inside a fencethis taskNo prompts; the boundary does the protecting. The agent grinds end to end inside a sandbox, container, or scratch worktree, and you review the whole batch once at the end.
3. Auto-apply edits, gate the rest
4. Ask before acting
5. Read & propose only

A mechanical rename across your own repo is the canonical case: the worst outcome is a git diff you throw away. Prompting on every one of twenty-four identical edits doesn’t add safety - it teaches you to stop reading prompts, which is where real risk starts. Let it run inside the fence and review the batch once.

The rung names are generic on purpose - every tool spells its own versions of them, and most let you set different rungs for different categories of action. The judgment underneath is the same two questions, asked per task, never answered once for all time.

This is the whole discipline

You met this idea in the modes chapter as a posture - which role you reach for. Now you have made it a setting - chat.permissions.default, a value you choose deliberately before consequential work and check before trusting the one you left on yesterday. Roles are the judgment in your head; permissions are the same judgment written into the tool.

And it is not a Copilot trick. Match-autonomy-to-stakes is the core discipline of working with any capable agent - you will see it under different names across every other course on this site. Get it right and the agent is fast where speed is safe and careful where care is owed, without you re-deciding from scratch each time.

The careful library work is done. But permissions are only one of the two dials you control. The other is not about how much the agent is allowed to run - it is about how much thinking it spends on the problem in front of it, and what that thinking costs. Next chapter: Models & credits.