SSO is not an MCP privilege boundary. Authorise every tool call again.

AWS published an MCP authorization pattern on 17 September that puts four checks between a signed-in user and a tool invocation: MFA, geography, group-to-role mapping and tool-level permission checks. Microsoft Entra ID supplies the identity claims; an Amazon Bedrock AgentCore Gateway interceptor evaluates them before business logic runs.

The useful part is not the AWS wiring. It is the separation of authentication from execution authority. A valid SSO token proves who arrived. It does not prove that the caller should invoke this tool, with these parameters, from this context.

The privilege boundary belongs outside the model

Natural-language routing makes this distinction operationally important. An agent can choose a tool because a prompt, retrieved document or intermediate plan steered it there. If the same agent also decides whether that choice is authorised, policy and execution collapse into one control plane.

AWS's walkthrough instead evaluates deterministic claims before invocation. Its sequence checks MFA, location, group membership and tool permissions. AWS's Agentic AI guidance makes the same architectural point: tool authorization should be an external check before execution, with identity and user context propagated through the chain.

An authenticated agent is still an untrusted requester at the tool boundary.

That changes the threat model for MCP deployments. Prompt injection is no longer expected to be defeated solely by better instructions. A manipulated agent may request an operation, but the gateway still has an independent opportunity to deny it.

Tool names are only the first policy dimension

A binary allow-list is not enough for consequential tools. The same operation can be acceptable for one resource and dangerous for another. AWS explicitly extends the pattern toward attribute and parameter-level checks, which is where least privilege becomes useful for agents.

A production policy should therefore bind authority to the caller, tool, resource, action and relevant request attributes. High-risk mutations can add a separate approval checkpoint. The audit record should preserve the identity and policy decision, not merely the agent's generated rationale.

Test denied paths as release evidence

Teams integrating MCP should add authorization tests to the production gate. For each exposed tool, exercise an allowed persona and at least one denied persona or parameter set. Confirm that denial happens before the target executes and that the decision is logged with enough context to reconstruct it.

Then review the architecture whenever a new tool, identity claim or target is introduced. SSO remains necessary, but it is only the entrance control. The durable security boundary is the deterministic authorization decision immediately before execution.

Written by the Devence Lab research team.