MCP tool allowlisting

An allowlist limits which tools an agent may invoke but does not decide whether one allowed call is authorized.

01 / The operating case

What changes in a real workflow?

A help-desk agent may call update_customer, but only for the account named in its active ticket.

Trace the authority boundary
  1. 01Client / task
  2. 02MCP server
  3. 03Tool call + arguments
  4. 04Downstream effect

02 / Decision contract

What the executor must check

Allowlist the tool as a coarse boundary, then authorize the normalized account, operation and task on every consequential invocation.

InputPrincipal · task · action · target
DecisionGrant ancestry · policy · current state
ResultEnforce · record · verify outcome

03 / Failure and evidence

What goes wrong, and what can be proven?

Failure mode

One allowlisted write tool becomes a path to every customer account.

Evidence to retain

Record catalog version, selected tool, target-specific decision and executor result.

04 / Canonical scope

Why this reference stands alone

Discovery versus authority explains the conceptual difference; this page owns allowlist deployment and its bypass tests.

Protocol or attack trace

Allowlist boundary

Sequence

Tool update_customer is allowed globally; agent task names only account A, but call arguments name account B.

Negative test

Allowlisted tool with B must still be denied by per-target authorization.

Primary references

Read the underlying material

Architecture discussion

Choose one consequential action and make its boundary explicit.

Request a Conversation