Preamble
- Title: Fine grained authorization behaviour
- Author: David Savage
- Status: Proposal (still drafting)
- Created: 2025-08-26
- Updated: 2025-08-30
Abstract
The current authorization specification focusses primarily on authentication e.g. how a client can obtain credentials to access an MCP server. However once identity of the client is established it says very little on how a client or server should implement authorization for individual protocol events.
In enterprise scenarios different principals may need to be limited in the sets of protocol operations they are be allowed to perform, both clients being limited on server operations and servers being limited on the set of client operations. This SEP focusses on guidance for SDK implementors, Client applications and Service providers such that there is a consistent approach to fine grained authorization that works across the MCP eco-system.
There are a range of authorization tools that can be used to implement authorization including open source libraries such as cedar and casbin or commercial offerings such as AuthO, Asserto or Amazon Verified Permissions therefore rather than being opinionated on how this should be implemented this proposal focusses on the documentation/guidance on the expected behaviour of fine grained authorisation in an MCP environment. Specific policy enforcement and policy decision implementation details are left to SDK, client and/or service providers to pick their preferred approach.
Motivation
Deployment of mcp clients and servers in an enterprise context require a clear and consistent approach to providing fine grained authorization.
This SEP will describe how the various actors such as users, LLM agents or servers should expect the protocol to behave under misuse cases (either accidental or malicious) where a user, an LLM agent or a server attempts to perform an operation that is not permitted by either the client or another server application.
Currently the specification states that the server operations that generate errors should return the standard HTTP 401, 403 or 400 response codes however this not sufficient under the following scenarios:
- When a client is required to deny a specific operation initiated by the server - streaming http uses a long lived HTTP GET initiated by the client to send MCP requests to the client via the HTTP response therefore there is no HTTP request for the client to deny in this case
- When a http server needs to deny a specific request from a client it exposes the transport protocol details to the client
- When a stdio server needs to deny a request there is no standardised way of doing this as the authorization documentation explicitly calls this behaviour out of scope
- There is no guidance for other protocol bindings other than 'follow protocol best practice'
Instead this SEP will introduce specific JSON RPC error codes agnostic of the transport implementation with well defined meanings. It will also define the expected behaviour of fine grained authorization checks for each protocol level operation such that both clients and servers can interoperate in a hetrogeneous environment made up of many different vendor solutions.
The following are some examples of the sorts of permission boundaries that it is useful to set for each protocol feature
Client Permissions
In general clients SHOULD be able to limit features on a per server basis
- Roots
- ability to filter roots to prevent sensitive content being shared with individual servers based on an allow/deny policy
- Sampling
- ability to introspect sampling requests and responses from/to individual servers and allow/deny based on a policy defined by the client
- Elicitation
- ability to introspect elicitation requests and responses from/to individual servers and allow/deny based on a policy defined by the client
Server Permissions
In general servers SHOULD be able to limit features on a per client principal basis
- Prompts
- ability to limit prompts to specific client principals based on a policy that is consistent for all list/get/changed events, e.g. a client should not be able to list a prompt it cannot get and it should not receive a change event if list changed would show no change due to permissions
- Resources
- ability to limit resources to specific client principals based on a policy that is consistent for all list/get/changed events, e.g. a client should not be able to list a resource it cannot get and it should not receive a change event if list changed would show no change due to permissions
- Tools
- ability to limit tools to specific client principals based on a policy that is consistent for all list/get/changed events, e.g. a client should not be able to list a tool it cannot get and it should not receive a change event if list changed would show no change due to permissions
- ability to allow/deny a call tool request/response from/to a specific client principal based on request/response content
- Logging
- ability to allow/deny changes to log levels to specific client principals based on a policy
Specification
TODO: The technical specification should describe the syntax and semantics of any new protocol feature. The specification should be detailed enough to allow competing, interoperable implementations. A PR with the changes to the specification should be provided.
Rationale
TODO: The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
This SEP focusses on standardising error codes and documentation updates to enable clients and servers to apply fine grained authorisation as this is easy to do and provides obvious benefits with no backwards compatibility issues.
The author suggests that it is unlikely there is a single policy engine that is will be accepted across the eco-system therefore any attempts to mandate this in the specification in the short to medium term are unlikely to succeed.
Assuming this SEP is accepted future SEP requests might focus on use cases such as:
- Standardised protocol messages to request permission when a deny response is received - e.g. GrantPermissionRequest/GrantPermissionResponse
- Standardised notifications to emit to security monitoring solutions - PermissionDeniedNotification
- Using OAuth On Behalf Of Token Exchange to enable servers and clients to distinguish permissions decisions based on whether the action was initiated by: a user; an LLM agent; or prompted by server sampling requests
WIP: One area that does need further elaboration is the relationship to #835 if MCP protocol level errors are introduced should these also include scope information when a client may request more scopes from the authorization server to enable the request to succeed? This behaviour is tightly coupled with OAuth specification and it is not currently clear to the author how this interoperates in a STDIO server scenario
Backward Compatibility
This SEP does not seek to make any backwards incompatible changes at this time rather to clarify best practice and set standardise error codes when permission is denied.
Reference Implementation
Python SDK pull request 1032 provides a reference implementation of the server side behaviours described in this SEP.
Security Implications
The author is not aware of any negative security implications of this proposal at this time. This section will be updated based on feedback in the comments.
Preamble
Abstract
The current authorization specification focusses primarily on authentication e.g. how a client can obtain credentials to access an MCP server. However once identity of the client is established it says very little on how a client or server should implement authorization for individual protocol events.
In enterprise scenarios different principals may need to be limited in the sets of protocol operations they are be allowed to perform, both clients being limited on server operations and servers being limited on the set of client operations. This SEP focusses on guidance for SDK implementors, Client applications and Service providers such that there is a consistent approach to fine grained authorization that works across the MCP eco-system.
There are a range of authorization tools that can be used to implement authorization including open source libraries such as cedar and casbin or commercial offerings such as AuthO, Asserto or Amazon Verified Permissions therefore rather than being opinionated on how this should be implemented this proposal focusses on the documentation/guidance on the expected behaviour of fine grained authorisation in an MCP environment. Specific policy enforcement and policy decision implementation details are left to SDK, client and/or service providers to pick their preferred approach.
Motivation
Deployment of mcp clients and servers in an enterprise context require a clear and consistent approach to providing fine grained authorization.
This SEP will describe how the various actors such as users, LLM agents or servers should expect the protocol to behave under misuse cases (either accidental or malicious) where a user, an LLM agent or a server attempts to perform an operation that is not permitted by either the client or another server application.
Currently the specification states that the server operations that generate errors should return the standard HTTP 401, 403 or 400 response codes however this not sufficient under the following scenarios:
Instead this SEP will introduce specific JSON RPC error codes agnostic of the transport implementation with well defined meanings. It will also define the expected behaviour of fine grained authorization checks for each protocol level operation such that both clients and servers can interoperate in a hetrogeneous environment made up of many different vendor solutions.
The following are some examples of the sorts of permission boundaries that it is useful to set for each protocol feature
Client Permissions
In general clients SHOULD be able to limit features on a per server basis
Server Permissions
In general servers SHOULD be able to limit features on a per client principal basis
Specification
TODO: The technical specification should describe the syntax and semantics of any new protocol feature. The specification should be detailed enough to allow competing, interoperable implementations. A PR with the changes to the specification should be provided.
Rationale
TODO: The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
This SEP focusses on standardising error codes and documentation updates to enable clients and servers to apply fine grained authorisation as this is easy to do and provides obvious benefits with no backwards compatibility issues.
The author suggests that it is unlikely there is a single policy engine that is will be accepted across the eco-system therefore any attempts to mandate this in the specification in the short to medium term are unlikely to succeed.
Assuming this SEP is accepted future SEP requests might focus on use cases such as:
WIP: One area that does need further elaboration is the relationship to #835 if MCP protocol level errors are introduced should these also include scope information when a client may request more scopes from the authorization server to enable the request to succeed? This behaviour is tightly coupled with OAuth specification and it is not currently clear to the author how this interoperates in a STDIO server scenario
Backward Compatibility
This SEP does not seek to make any backwards incompatible changes at this time rather to clarify best practice and set standardise error codes when permission is denied.
Reference Implementation
Python SDK pull request 1032 provides a reference implementation of the server side behaviours described in this SEP.
Security Implications
The author is not aware of any negative security implications of this proposal at this time. This section will be updated based on feedback in the comments.