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.
Modern agent harnesses make work durable across restarts, devices, background jobs, and sub-agents. That durability is a runtime property, not a governance property. A session answers where the agent can continue working. A mission answers why the agent is allowed to keep working. Conflating them is a central failure mode of long-running autonomous agent systems.
Open-world OAuth can improve discovery, resource binding, and first-contact trust. That still leaves the harder agent problem: how approved intent becomes bounded authority that stays governed across delegation chains, unfamiliar tools, consent expansion, revocation, and task termination.
OAuth was built for closed worlds, and that constraint is why it became mature. Agents expose the limits of that deployment model. This post traces what the newer OAuth standards get right and which substrate gaps still need to close.