01 / The operating case
What changes in a real workflow?
A server exposes read_invoice and release_payment. A child agent may read invoice I-42 but lacks authority to release its payment.
- 01Client / task
- 02MCP server
- 03Tool call + arguments
- 04Downstream effect
02 / Decision contract
What the executor must check
Inspect the call at the server or executor PEP, validate the delegated grant and reject release_payment before downstream dispatch.
Architecture review / negative test
Make the boundary testable.
Specify which component sees the real caller, task, tool name and normalized argument values. A server-side PEP can decide before tools/call dispatch, but an executor check may be needed if a gateway cannot see hidden business context or direct routes exist. Keep transport scopes distinct from per-action permission.
03 / Failure and evidence
What goes wrong, and what can be proven?
A client sees a tool in a catalog and treats its visibility as permission to execute it.
Connect tool call ID, policy decision and downstream result; retain denied attempts.
04 / Canonical scope
Why this reference stands alone
The existing pillar guide remains broad canonical MCP security; this page owns the call-level authorization contract.
Technical deep dive
Transport access ends before business permission begins.
The MCP authorization specification governs access to an HTTP protected resource; the tools specification describes listing and invoking server tools. Neither defines a finance policy for a release_payment call. Translate a concrete invocation into trusted principal, task, tool, target and normalized arguments, then have an enforcement point that can stop the downstream effect apply the decision. Test catalog visibility, direct calls and alternate execution routes separately.
Token audience: finance MCP server → valid Task: validate invoice I-42 read_invoice(I-42) → ALLOW release_payment(I-42, USD 8,400) → DENY Direct payment API call → same DENY at executor
Run the negative test
Use one valid transport token to list and call both tools. The forbidden call must fail at tools/call or execution despite successful authentication. Change the payee after a permitted decision and confirm the executor rejects the mismatch. A hidden tool invoked directly must fail as well.
Continue to MCP threat model for the adjacent boundary.
Architecture field test
Transport access and action authority are separate
Does this tools/call fit the task and protected effect?
- 01Validate MCP resource token
- 02Resolve tool and normalized arguments
- 03Authorize exact task-bound effect
- 04Use separate downstream credential
Work the boundary
An agent can list a payment MCP server’s tools with a token issued for that server. Calling release_payment for invoice I-42 still needs the invoice, payee, amount and originating grant checked before the downstream payment API commits.
| Required facts | Token issuer and audience, authenticated principal, task grant, tool name, target, normalized arguments and downstream policy. |
|---|---|
| Allow only when | The server accepts the token for itself and a separate decision allows this precise tool effect. |
| Deny when | A valid MCP token permits discovery but the agent calls a payment tool outside its task grant. |
Break the assumption
Try a token for another MCP resource, then a valid token with an out-of-scope payee. Finally call the downstream API directly. These are different failures and need different controls.
Design tradeoff
The July 2026 MCP authorization specification governs HTTP transport authorization and token handling. It does not by itself define the business authorization semantics for every tool effect; those belong to the protected operation.
For transport access and action authority are separate, consult MCP authorization specification, July 2026. This worked decision and negative test are ProofGrid analysis.
Continue with MCP authentication and transport.
Primary references