The least-privilege MCP series ends on a gap: token-side and resource-side authorization both work per call, and neither names the task the user approved. This essay applies Mission-Bound Authorization at the MCP boundary. The Mission is the durable approved task, tokens and PDP decisions are projections of it, tool discovery and invocation and approval line up against it, expansion routes through a fresh approval, and audit joins on one identifier. A denial is traced end to end to show the whole spine working.
Part one laid out two ways to lock down a single tool call an agent makes through the Model Context Protocol: carry a narrow token, or let the resource decide each call. This part walks the standards that close the gaps. AuthZEN gives a standard way to ask the policy question, the Access Request and Approval Profile turns a denial into a governed request for approval, and a set of proposals carries that approval over the wire. Each makes one call’s authorization more interoperable, and none gives a multi-step task a shared identity. So a string of individually correct calls can still drift from what the user approved. The missing piece is a durable, governed record of the approved task, the object I call a Mission.
There are two natural ways to lock an agent’s Model Context Protocol (MCP) tool calls down to least privilege. The agent can carry a narrow token scoped to the action, or the server can decide each call as it happens. Carrying a token gives portable proof of what the agent may do, but pushes domain knowledge onto the authorization server and token management onto the client. Deciding at the resource keeps the meaning where it lives, but the decision is not portable. MCP makes the tool boundary first-class for both. This part compares the two models and how to choose. Part two covers the standards that close the per-call gaps and the task object neither names.