ToolHive has an authorization framework which is described in https://github.com/stacklok/toolhive/blob/main/docs/authz.md and https://dev.to/stacklok/secure-by-default-authorization-for-mcp-servers-powered-by-toolhive-1hp6 .
This was good to kick off the concept of authorization for MCP servers, however, the implementation could still be enhanced.
The Discovery part of the MCP protocol shouldn't be explicitly guarded (tools/list). Instead, everyone with some access should be allowed to call it. Then, we should apply the authorization policy on the result. Only outputting the tools that the user is allowed to leverage.
The same requirement applies to listing resources and prompts.
This requires more in-depth integration with the MCP protocol, but will lead to a smoother integration and even context optimizations, since the context won't be polluted.
ToolHive has an authorization framework which is described in https://github.com/stacklok/toolhive/blob/main/docs/authz.md and https://dev.to/stacklok/secure-by-default-authorization-for-mcp-servers-powered-by-toolhive-1hp6 .
This was good to kick off the concept of authorization for MCP servers, however, the implementation could still be enhanced.
The Discovery part of the MCP protocol shouldn't be explicitly guarded (
tools/list). Instead, everyone with some access should be allowed to call it. Then, we should apply the authorization policy on the result. Only outputting the tools that the user is allowed to leverage.The same requirement applies to listing resources and prompts.
This requires more in-depth integration with the MCP protocol, but will lead to a smoother integration and even context optimizations, since the context won't be polluted.