Skip to content
Training
🔥0
Sign in
9 min readmedium+45 XP

Configure Tool Permissions and Allow Lists

Tool permissions are the contract between trust and capability. Learn to pair each autonomy level with the right consent gate, allow list and audit trail so an agent can act with the least power that still gets the job done.

After this topic, you'll be confident about Allow list, Read-only mode, Consent gate and 1 more concept.

Configure Tool Permissions and Allow Lists

Every agent decision has two halves: what should it be able to do? and who confirms each action? Tool permissions answer the first; consent gates answer the second. Get either wrong and you have either a useless assistant or a confidently wrong one with admin privileges.

The three layers of a real allow list

  1. Server selection — which MCP servers does the host load at all?
  2. Toolset and tool filtering — within each server, which named tools are exposed? The GitHub MCP server, for example, supports a --read-only flag and --toolsets flags to enable only repos,issues.
  3. Argument constraints — for high-risk tools, can you constrain arguments (e.g. only pr_number=42, only branches matching agents/*)?

Tools live on a sliding scale of blast radius. The job of permissions is to match each tool's blast radius to a proportionally strong gate.

Autonomy and guardrails

The same tool can be safe at one autonomy level and dangerous at another. A merge_pull_request tool is fine in Suggest mode (the agent recommends it; a human clicks) and terrifying in Auto-apply mode without checks. Walk each level and ask: what guardrail makes this level safe?

Autonomy dial

+45 XP

For each autonomy level, toggle the guardrails the agent must have before tool calls of this class are permitted.

L1L2L3
L1 · Suggest
Agent proposes the tool call; a human must click to invoke it.
Toggle the guardrails this level needs.

Quick check

The dial above is the assessment for this topic; treat each level as an exam-style scenario and explain why each guardrail is required at that step.

Where this shows up on the exam

Expect a question that hands you a scope (e.g. repo PAT, full filesystem) and asks which is appropriate for a stated task. The right answer is always the narrowest scope that still completes the task — and the wrong answers always rationalise away a missing consent gate.

Anchor concepts

Key terms

Allow list
The explicit, named set of tools (and often arguments) an agent is permitted to call. Anything not on the list is implicitly denied.
Read-only mode
A configuration that disables every write/mutating tool on a server while leaving discovery and reads available — the safest default.
Consent gate
A user-facing prompt that must be approved before a sensitive tool is invoked. Required by the MCP spec for tool calls.
Scope (token)
The set of operations a credential allows on a remote system (e.g. GitHub PAT scopes like `repo`, `read:org`). Always grant the minimum.
Watch out

Common pitfalls

  • Granting an agent a token with `repo` scope when `public_repo` or read-only is enough — the blast radius now includes every private repo you can access.
  • Putting tools on the allow list but skipping the consent gate; the user has no chance to see or stop a risky action.
  • Treating 'auto-approve' as a permission level instead of what it is: an explicit decision to remove a safety control for one named tool.
Configure Tool Permissions and Allow Lists · Training