MCP access governance patterns for teams and tenants
Kuldeep Paul outlines how to enforce fine-grained MCP access control across teams, tenants, and third-party integrations using tool-scoped credentials, allow-lists, and per-call audit logging — gaps the MCP protocol itself does not fill.
Score breakdown
Teams deploying MCP-connected agents in production should implement tool-level allow-lists and per-tenant audit trails now, since the protocol's own OAuth 2.1 model only secures the server entry point and leaves individual tool access and supply chain risks unaddressed.
- 01MCP's OAuth 2.1 authorization model scopes access to an entire server, not to individual tools, leaving any two agents with the same token sharing an identical tool surface.
- 02The 2025-06-18 revision of the MCP authorization specification added an OAuth 2.1 authorization model for HTTP transports.
- 03Microsoft's developer team has described 'tool poisoning' attacks, where malicious instructions inside MCP tool descriptions are interpreted by the model as real commands.
Kuldeep Paul's article argues that MCP access governance — the policy layer controlling which agents, teams, tenants, and applications can invoke specific tools on specific MCP servers — is a critical gap that the Model Context Protocol does not address on its own. While the 2025-06-18 revision of the MCP authorization specification introduced an OAuth 2.1 authorization model for HTTP transports, that model scopes access at the server level, meaning any two agents presenting the same token receive an identical tool surface. Fine-grained, tool-scoped access control across a shared pool of agents and customers must be handled at the deployment layer.
The article identifies three structural problems that make MCP access control brittle without a dedicated gateway.
The article identifies three structural problems that make MCP access control brittle without a dedicated gateway. First, per-tool authorization is not native to the protocol. Second, tool metadata is itself an attack surface — Microsoft's developer team has described "tool poisoning" attacks in which malicious instructions embedded in tool descriptions are interpreted by the model as real commands. Third, every third-party MCP server represents a supply chain dependency whose code was not written by the deploying team but still receives agent-produced inputs and returns model-consumed outputs.
To address these gaps, the article recommends team-scoped credentials that restrict each team to only the tools it needs, and tool-level allow-lists rather than server-level allow-lists, since a typical MCP server bundles read, write, and administrative tools together. For multi-tenant deployments, the recommended controls are per-customer credentials with tool and server restrictions matching each tenant's contracted feature set, per-tenant budgets and rate limits to prevent any single customer from exhausting shared spend, and per-tenant audit trails for compliance. Bifrost, the open-source AI gateway built by Maxim AI, is presented as a concrete implementation: it ships virtual keys with attached tool-level allow-lists evaluated on every MCP request, MCP Tool Groups for defining named tool collections resolved at request time in memory, and per-call audit logging.
Key facts
- 01MCP's OAuth 2.1 authorization model scopes access to an entire server, not to individual tools, leaving any two agents with the same token sharing an identical tool surface.
- 02The 2025-06-18 revision of the MCP authorization specification added an OAuth 2.1 authorization model for HTTP transports.
- 03Microsoft's developer team has described 'tool poisoning' attacks, where malicious instructions inside MCP tool descriptions are interpreted by the model as real commands.