MCP Authorization
Authentication proves who is calling. Authorization decides what they are allowed to do — and MCP defines none of it. The Model Context Protocol authenticates a caller at the transport, then hands over the server's full toolset with no scoping. An authenticated agent can call any tool the server exposes, including the destructive ones, because nothing has said it should not.
This page covers how authorization works in MCP (it largely does not), why the decision belongs at the gateway, and how per-tool, per-argument policy scopes an agent down to what it should actually be permitted. It pairs with MCP authentication (the "who"), sits inside the MCP gateway that enforces it, and rolls up to the broader MCP security and AI agent security references.
How authorization works in MCP
It mostly does not. The MCP specification defines transport, message format, and an OAuth flow for authentication. It does not define authorization — which caller may invoke which tool, with which arguments, under which conditions. That decision is left to implementers, and most implementers leave it unmade. The common outcome is all-or-nothing: authenticate, and you receive the server's entire toolset. There is no native way to expose get_issue while withholding delete_repository, and no way to say that one person may refund up to a limit while another may not refund at all.
Authentication is not authorization
Authenticating a caller proves identity. It does not bound what that identity can do once it is through the door. An authenticated agent holding a valid token can still issue a refund, drop a table, or send a message as the user, because authentication answers who, not what. The two are distinct controls and a production deployment needs both: identity from your enterprise identity provider, and authorization as a separate policy decision on every call. Strong authentication with no authorization is an open door with a guest list.
Why authorization belongs at the gateway
You cannot add authorization inside servers you do not control, and most MCP servers in a real stack are third-party. The place to put the decision is the boundary every call has to cross: an MCP gateway that intercepts each tools/call, evaluates it against policy, and only then forwards it upstream. Because evaluation happens before execution and outside the model, the verdict is deterministic — an identical call yields an identical decision, and a prompt injection cannot argue its way past a rule it never reaches.
Tool-level and argument-level authorization
Real authorization operates at two levels. The first is the tool: expose a subset of a server's tools to a given identity and withhold the rest, blocking individual destructive actions while leaving the rest of the server usable. The second is the argument, and it is where most of the risk lives. The same tool is safe with one argument and dangerous with another — a refund of five dollars versus fifty thousand, a query against a sandbox versus production, a deploy to staging versus main. Argument-level authorization reads the actual parameters of the call and decides on them: allow, deny, rate-limit, or require human approval.
RBAC and ABAC for MCP
Two models, used together. Role-based access control (RBAC) grants tools by role: a support agent gets read tools, an engineer gets more, an admin gets the rest. Attribute-based access control (ABAC) decides on attributes of the specific call — argument values, environment, data classification, the requesting identity — and is what enforces the conditions RBAC cannot express. A production gateway should treat identity-provider group membership as a first-class attribute, so a role in Okta or Entra maps directly to what an agent acting for that person may do.
How to authorize MCP access safely
- Default to deny. A new tool is unavailable until a policy grants it, not the other way round.
- Authorize per tool, not per server. Block one destructive action while leaving the rest of the server usable.
- Read the arguments. Decide on the values of the call, not just its name — amount, environment, recipient, query text.
- Enforce before execution. The decision must happen on the path, before the call reaches the server, not in a log afterwards.
- Drive it from your IdP. Map roles and groups to grants so access tracks joiners, movers, and leavers automatically.
- Keep it deterministic. Identical request, identical verdict — no model in the decision path. Pair authorization with authentication: who, then what.
Frequently asked questions
What is MCP authorization?
MCP authorization is deciding what an authenticated caller is allowed to do once it can reach an MCP server: which tools it may call, with which arguments, under which conditions. The Model Context Protocol handles authentication at the transport layer but defines no authorization model, so by default any caller that can connect to a server can invoke every tool that server exposes. Authorization is the layer that scopes that down to what a given person or agent should actually be permitted.
What is the difference between authentication and authorization in MCP?
Authentication proves who is calling; authorization decides what that caller may do. An agent can hold a perfectly valid token (authentication) and still call delete_repository, issue a refund, or run a destructive query, because nothing has scoped what the token is allowed to invoke (authorization). The two are different controls and you need both: authentication via your identity provider, authorization via per-call policy at the gateway.
Does MCP have an authorization model?
No. The MCP specification covers transport, message format, and an OAuth flow for authentication, but it does not define authorization — which caller may invoke which tool under which conditions. That decision is deferred to implementers, and in practice most servers make no decision at all: an authenticated caller gets the full toolset. Authorization has to be added at a control point outside the server, which is what an MCP gateway provides.
How do you authorize MCP tool calls?
Route the agent through a gateway that evaluates every tools/call against policy before it reaches the server. The policy decides per tool and per argument — not just "can this agent reach Stripe" but "can this call refund this amount" — and supports role-based (RBAC) and attribute-based (ABAC) rules driven by your identity provider. Because the decision happens before execution and outside the model, it is deterministic and cannot be talked out of by prompt injection.
RBAC or ABAC for MCP authorization?
Both, and they compose. Role-based access control (RBAC) grants tools by role — a support agent gets read tools, an admin gets more. Attribute-based access control (ABAC) decides on attributes of the call: the argument values, the environment, the data classification, the time, the requesting identity. RBAC sets the broad grant; ABAC enforces the conditions on individual calls, such as capping a refund amount or restricting a query to one schema. A production gateway should support IdP group membership as a first-class attribute.
Can you authorize at the argument level?
Yes, and you should. Tool-level allow or deny is not enough when the same tool is safe with one argument and dangerous with another. Argument-level authorization evaluates the actual parameters of the call — refund over a threshold, a branch other than a sandbox, SQL that drops a table, a recipient outside the org — and allows, denies, rate-limits, or requires approval based on them. This is the difference between governing access to a tool and governing what the tool is asked to do.