What is MCP authorization?

The Model Context Protocol standardises how an agent discovers and calls tools on a server. Its authorization specification is built on OAuth 2.1 and addresses identity at the connection boundary: the client obtains a token, the server validates it, and the connection is established with a scope attached. That is a real and necessary piece of infrastructure, and it is genuinely better than the credential-sharing it replaced.

What it does not do — and does not attempt to do — is rule on individual calls against enterprise policy. Once a connection is established, the operations that server exposes are reachable. The protocol has no concept of Segregation of Duties, no notion of which human the agent is acting for, and no view of what this agent has already done in the workflow, because none of those are properties of a protocol connection.

The gap has a concrete shape. An accounts payable agent is properly authenticated to your ERP's MCP server, holding a valid token with a legitimate scope. Everything about the connection is correct. It then calls the operation that approves an invoice — one it raised itself forty minutes earlier.

Nothing in the authentication layer objects, because nothing in the authentication layer is wrong. The agent is who it claims to be, connected to a server it is entitled to reach, calling an operation that server exposes. The violation is a Segregation of Duties breach, and SoD is a statement about the relationship between two actions and one actor, which no connection-scoped token can express.

The same shape recurs across every category of enterprise risk: value thresholds, blast radius, regulated data classes, and whether a named human authorised this particular thing. All of them are properties of the call, not the connection.

There is a second problem with treating the connection as the security boundary, and it is one of granularity.

An enterprise MCP server commonly exposes dozens of operations, and connecting an agent grants reach to all of them. The grant intended to let an agent read invoices also gives it vendor edits, payment releases, and whatever else lives behind the same server. Nobody decided that; it fell out of the unit at which access is expressed.

Closing it means enumerating operations and deciding per operation, which is only practical if the enumeration is automatic. LangGuard's SCOPE-MCP classifies the operations a server exposes before an agent is permitted to reach it, labelling each against Segregation of Duties rules and regulatory regimes, so the resulting scope is a specific list of permitted operations rather than a list of permitted servers.

Every tool call is treated as an authorization decision, evaluated after the agent reasons and before the call reaches the server.

Arbiter evaluates the specific call — this tool, this operation, these parameters, this agent, acting for this person — against the scope established at design time, and returns ALLOW, BLOCK, or ESCALATE. Calls inside scope with no threshold applying clear without perceptible latency. Calls outside scope do not execute. Calls inside scope but above a threshold are held and routed to the named approver for that scope. The decision, its policy, and its approver are recorded as evidence at the moment it is made.

Because enforcement attaches at the points where agents reach tools — the MCP catalogue, the gateway, and the agent harness — it applies to agents you did not build, including packaged and vendor-supplied ones, without requiring changes to them.

Governing the movement of enterprise context through MCP, rather than the tool calls themselves, is a related but separate problem: which data may travel down which path, and for what purpose. That is covered by MCP Context Authorization.