Lesson 22.822.8 Permission policies: allow, ask, decide

In everyday life. A hospital pharmacy sorts its medicines into three cabinets. Some are on an open shelf: any nurse may take them. Some need a pharmacist's signature each time. And some sit behind a machine that checks the prescription against the patient's chart and dispenses or refuses. The machine is useful, but no hospital calls it a pharmacist. In this concept, the open shelf is "allow", the signature is "ask", and the machine is "decide".

What you will learn. The three rules a tool can have on a hosted worker, what each one does on every call, and which defaults protect you and which do not.

Why it matters. A tool added to a server next month should not run in your product until someone reviews it. And a platform's own judgment cannot stand in for the person who must answer for an action.

One request, start to finish. Next month, Brightline's connector gains a fifth tool, export_vendor_list, added for another team. Ana asks the worker a question the new tool could help with.

1. The four reviewed tools run without asking. Their policy is "allow".
2. The new tool is not on the list of tools turned on (22.6), so the model never sees it. Ana gets her answer from the four.

What if someone had turned the whole connector on instead?

1. The new tool's policy is "ask", the default for every connector tool. The session stops with "needs action" and names the call.
2. The portal shows Ana the tool's name and its inputs, with Allow and Deny buttons.
3. Ana denies it. The session continues without it, and tells her it could not export the list.

What is a permission policy?

A permission policy is the rule for one tool, set in the agent definition. There are three:

The defaults are where most mistakes hide. On the lab's main platform, connector tools default to ask, so a tool someone adds to a server later does not run in your product without approval. That default protects you. The worker's own built-in tools, such as running commands or reading files, default to allow. That default does not. A command tool left on, with "allow", runs any command a fooled model asks for, inside the sandbox, without asking. So the lab turns off every built-in tool it does not need, and keeps only the file tools the skill reads with.

Have you seen these shapes before (21.5)?

In Chapter 21, the first SDK asked your callback, which answered at once, and the second SDK paused the run and handed the call back for approval.¹ A hosted platform runs no code of yours inside its loop, so "ask" works like the second SDK's approval: the session stops, your product sees the call as an event, and answers it. "Decide" is like the setting Chapter 21 warned an SDK may choose for you if you leave it out, where a second model judges each call. It can be useful, but it is never your rule and never a person.

How does the confirmation round trip work?

With "ask", the session emits the tool call, then goes idle with the stop reason "needs action", naming the call (22.3). It waits with no time limit. Your product shows the person the call, then sends back a confirmation: allow or deny, for that one call, with an optional message saying why. A deny reaches the model as a refused tool result, and it carries on without it.

Is a platform's judgment a human checkpoint?

"Decide" can be useful for low-risk tools in a worker no one watches. But understand what it judges. It reads the question your product sends as what the person wants, even if an untrusted user typed it. It treats what tools return, pages it fetched and connector results as data, never as intent. So it can refuse an instruction hidden in a vendor note. It cannot know that the person asking has no right to the answer, and it cannot be the person who is accountable for an action. When an action needs someone accountable, use "ask", and put a person behind it (Chapter 24).

How do you see what was decided?

Each tool call in the log carries the policy's result for that call: allowed, asked or refused. Under "decide", a call it refused or paused also carries the platform's reason, as a code. That makes the log the record of who allowed what.

At work. In Lab 22, Task 6, Claude Code sets the connector's default policy to "ask", turns on the four read-only connector tools by name with "allow", and keeps the command tool and both web tools off. Three built-in file tools stay on: read (open a file in the sandbox), glob (list files whose names match a pattern) and grep (search inside files). The builder asks: "Show me, for each tool the model can see, its policy and why." Claude Code prints seven rows. Four are connector tools on "allow", reviewed in Chapter 17. Three are file tools (read, glob and grep) on "allow", which the skill needs and which reach only the sandbox's own files. The lab never uses "decide", because no person checks it.

The operating rule: ask by default, and allow only the tools you reviewed. Never let the platform's judgment stand in for a person who must own the action.

Figure 22.12. Allow, ask, decide. Only "ask" puts a person behind the call.

Part B in one minute

Your skills and connector travel unchanged, but commands, hooks and settings files do not, so their checks move into a policy or the connector (22.6). The sandbox gets one open door, the connector's address (22.7). And every tool gets a policy: allow, ask a person, or let the platform decide, which is never a human checkpoint (22.8).

Now do Lab 22, Sitting 2 on the lab page: Tasks 5 to 8 (about 1 hour 15 minutes). Then come back for Part C.