When teams first think about MCP access control, they think about server access — who can connect to which servers. That is a reasonable starting point, but in practice it is not granular enough.
Granting a user access to an MCP server often means granting access to every tool that server exposes. Some of those tools read data. Some write it. Some delete it. Server-level access does not distinguish between them.
This post covers how to get MCP access control right at the tool level — and why it matters more than most teams expect.
The Problem with Server-Level Access
Take a HubSpot MCP server as a concrete example. It might expose tools for reading contacts, updating contacts, creating new records, batch-deleting objects, and managing associations. Useful tools, all of them — but not equally appropriate for every user.
A marketing analyst probably needs read access. Maybe the ability to update a contact field. They almost certainly do not need hubspot-batch-delete-objects
Server-level access gives them all of it. The principle of least privilege — give users only the access they actually need — does not apply if your only control point is the server boundary.
This is not just a theoretical risk. In practice, it means:
A user who should not be able to delete records can — and if an agent acts on their behalf, the agent can too.
An agent scoped to a read-only task still has write and delete tools available to it.
Your security review gets harder when you cannot answer “what can this user actually do in HubSpot” with anything more specific than “they have access to the HubSpot server.”
Tool-Level MCP Role Based Access Control
The fix is configuring MCP access control at the tool level, with authentication and authorization as the basis for fine-grained control, where tool-level governance limits which specific functions an AI model can invoke — selectively enabling the tools a user group actually needs and disabling the ones they do not.
In practice, that looks like this: rather than granting a user group access to the HubSpot MCP server wholesale, you create a configured view of that server that exposes only the tools they need. Modern OAuth-based controls are a better fit than older API keys used for simpler or legacy integrations, but getting MCP authentication right at enterprise scale is harder than it looks and requires careful scope and token management. Read tools on, write tools off, destructive tools definitely off. Without access control, an AI could accidentally delete important files or share private company data. That configured view is what gets added to their registry.
A few things this enables that server-level access does not:
Role-appropriate tool sets. Your marketing analysts get read tools and a limited set of write tools. Your CRM admins get the full set. Sensitive tools should only be exposed to roles or claims that require them. Instead of broad server access, authorization decides what tools and data a specific identity is allowed to use. Neither group sees tools irrelevant to their role, and neither can accidentally or intentionally call something they should not.
Guardrail visibility. Tools that modify or delete data carry risk. Surfacing that clearly in the interface — flagging a tool as a “Data Modification Warning” before someone enables it — gives admins the context they need to make the right call.
Customization without forking. If a tool default name or description is ambiguous, you can override it for your environment. That is useful for improving agent tool selection and for making audit logs easier to read — a tool called update-crm-contact is a lot clearer in a log than hubspot-batch-update-objects, and it keeps access in a least-privilege operational scope that reduces data leaks and unauthorized actions. Fine-grained authorization logic also supports better authorization decisions by adapting to tool risk and data sensitivity, especially when paired with centralized MCP identity management strategies that keep OAuth sprawl under control.
Implementing this well requires workload identity verification, context classification, and a runtime policy engine that evaluates who is asking, what tool is needed, and how sensitive the data is.
Obot MCP Gateway includes tool-level access control, IdP-mapped registries, and composite server support out of the box. Try Obot for free.
Registries as the Organizing Unit in Model Context Protocol
The way tool-level MCP access control works in practice is through registries — named groupings that map a set of MCP servers (and their tool configurations) to a set of users and groups from your identity provider (IdP), such as Okta, Microsoft Entra, Google, or Keycloak. Access Control Lists (ACLs) can also group tools by team permissions within those registries. IdP integration centralizes authentication for registry assignment, supports mcp authentication, and helps enforce policy consistently in enterprise deployments, and following step-by-step MCP authentication best practices helps teams implement OAuth 2.1 securely.
MCP clients can use automated discovery of OAuth endpoints and dynamic client registration instead of manual configuration.
An engineering registry might include GitHub, Kubernetes, and AWS, with full tool access across all three. A marketing registry might include HubSpot and MixPanel, with write tools enabled for the CRM team and read-only access for analysts. Legal gets their own registry with access to contract search tools and nothing else.
Users only see the registry they are assigned to. They do not see other registries exist. This scales better across enterprise systems and existing APIs than configuring each server separately. When someone changes roles, you update their IdP group membership and their registry access follows automatically. Enterprises often combine OAuth 2.1, context-based access control, and Access Control Lists (ACLs) to manage access permissions, aligning tool exposure with top MCP security risks and best practices.
This also gives you a clean answer to the organizational ownership question: who decides which tools are available to which teams? The platform or security team owns the registry definitions. Business units can request changes. There is a clear process and a clear audit trail, and audit logging is essential for compliance and security oversight because it records access and actions by agents and users and helps trace decisions back to identities, context, and policy factors, which directly answers many of the questions in enterprise MCP security reviews. Registries also help standardize secure access across enterprise deployments.
AI Agent-Scoped Tools
There is a related problem on the agent side worth addressing: mcp access control governs how an AI agent and Large Language Models (LLMs) interact with enterprise tools and sensitive datasets, and agents may also need to use sensitive tools as part of their job, but they do not need every tool in a user registry.
An agent built to run a weekly CRM data quality report needs read access to contact records; depending on scope, it might also check calendars or send email. It does not need write access, delete access, or tools for managing associations — even if the user who owns it does. Giving an agent the full registry is the same mistake as giving a user the full server, and it needlessly broadens the impact of compromised or over-scoped OAuth tokens.
The fix is composite MCP servers – sometimes known as virtual MCP servers. Purpose-built tool sets scoped to what a specific agent actually needs. You pull in only the tools relevant to the agent task, and tool-level governance limits which specific functions the model can invoke. Its blast radius is limited to what it can actually call. That narrower scope also reduces the chance of credential theft leading to wider access, especially when paired with an MCP proxy that centralizes security and observability.
This matters especially for autonomous agents running on a schedule or in response to events — the ones where no human reviews each tool call before it happens. The narrower the tool set, the smaller the potential impact of something going wrong, which helps mitigate AI-specific risks like data exfiltration, unauthorized actions, and prompt injection attacks that agents cannot fully defend against alone, and that narrow scoping also matters for end user trust because the agent is acting on a person’s behalf.
What to Build Toward
If you are just getting started with MCP access control, server-level registries tied to IdP groups are a reasonable first step. They are better than nothing, and they give you the foundation to layer on tool-level controls later.
I recommend that you plan for tool-level MCP access control from the beginning. Policies should enforce least privilege so users receive only the permissions necessary for their tasks, which limits the damage from compromised tokens; avoid long lived tokens and prefer short-lived OAuth tokens, and be wary of dangerous MCP OAuth shortcuts that undermine security. It is easier to start with tighter permissions and loosen them as needed than to start open and try to restrict access after users are already relying on it.
Tool-level filtering: Within each server, enable only the tools each group actually needs. Authentication in MCP is primarily built on OAuth 2.1 for secure API access, and OAuth flows should scope tokens to specific MCP servers. Use granular OAuth scopes to define the specific actions the MCP server may perform. Disable write and destructive tools by default, and add control-plane filtering to prevent PII leaks from MCP tool responses.
Agent-scoped composites: For each autonomous agent, build a composite server with only the tools that agent requires. For autonomous agents with no end-user redirect, machine-to-machine access can use client credentials, and many teams evaluate MCP gateways for secure, scalable composites as part of this design.
Audit and review: Log every tool call. Centralized auditing and logging should automatically record model-initiated actions with parameters and timestamps. Review everything periodically to tighten permissions that have drifted. The MCP specification formalizes the authorization code flow with PKCE for user-facing access.
Audit logs should also cover access token handling, token validation, and tool invocation for accountability, including JSON Web Token claim checking where JWTs are used. MCP is open source, which lets organizations swap cloud models or connect developer tools without redesigning their security architecture, and broader learning center resources on MCP gateways and security can help teams plan those integrations.
Automated discovery, dynamic registration of each client, and reduced prior coordination make it easier to connect public APIs and other API integrations securely, including via mutual TLS where required, especially when paired with MCP token brokering so clients never hold raw OAuth tokens.
When your security team asks, “what can this agent actually do,” you want to have a specific, accurate answer ready. If a client reaches a protected server without credentials, the server responds with PRM, including metadata such as the server URL and OAuth authorization server details needed to authenticate. The MCP server should validate each token’s signature, expiry, issuer, and scopes as the resource server, while the authorization server issues the token; in OAuth 2.1 and the authorization code flow, the client can then present that token to the protected API, and resource indicators help bind OAuth tokens to the right resource server so only tokens meant for that server are accepted.
Designing the right permission model for your MCP deployment takes more than a checklist. If you are working through how to structure registries, scope agent tool sets, or integrate with your IdP, our team can help.
