Policy: Allow, Ask, Block
There is no rule language to learn. Every tool of every connection has one of three modes, and you can set a whole connection from one of three presets.
The three modes
| Mode | What it means |
|---|---|
| Allow | Runs without asking. Every call is recorded. |
| Ask | Pauses until a person approves. Approve once, for a while, or always for that person. |
| Block | Refused, and hidden from the agent's tool list. |
Block hides the tool from tools/list as well as refusing it. There is less context for the model to work with and nothing for it to try; a call to a hidden tool still lands in Activity as a refusal.
The three presets
| Preset | What it does |
|---|---|
| Open | Every tool runs without asking. |
| Recommended | Reads run. Writes wait for a person to approve. |
| Locked | Nothing runs until you allow it. |
Recommended is applied when you add a connection. Reads and writes are guessed from each tool’s read-only hint and its name: get_, list_, search_ and friends read; anything that runs raw SQL counts as a write. It is a starting point, not a verdict.
Scoping a tool to a resource
Some tools take a resource argument: a database id, a repository, a project. A tool can be scoped so its mode depends on that argument, and a declared scope that cannot be resolved from the call refuses it rather than guessing. That refusal shows in Activity as couldn’t scope the call.
What is not policy
- There is no allow-list of arguments. If a tool can do something dangerous with the right arguments, its mode should be Ask or Block.
- There is no org-wide “always for everyone”. If everyone should be able to run a tool without asking, set the tool to Allow. One visible decision beats a pile of invisible ones.
- Modes are workspace-wide. Per-person differences come from approvals you remember for that person, not from a second policy layer.