Fine-Grained MCP Access Control: Beyond Server-Level Permissions

Series: Enabling MCP at Enterprise Scale | Post 7 of 10

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 Access Control

The fix is configuring MCP access control at the tool level — 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. Read tools on, write tools off, destructive tools definitely off. 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. 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.

Obot MCP Gateway includes tool-level access control, IdP-mapped registries, and composite server support out of the box. Try Obot on GitHub — it is free and open source.

Registries as the Organizing Unit

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, or Google.

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. When someone changes roles, you update their IdP group membership and their registry access follows automatically.

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.

Agent-Scoped Tools

There is a related problem on the agent side worth addressing: agents 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. 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.

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 that is all the agent sees. Its blast radius is limited to what it can actually call.

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.

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.

But plan for tool-level MCP access control from the beginning. 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.

A practical maturity path looks like this:

1. Server-level registries — Map IdP groups to approved MCP servers. Users only see what they are assigned.
2. Tool-level filtering — Within each server, enable only the tools each group actually needs. Disable write and destructive tools by default.
3. Agent-scoped composites — For each autonomous agent, build a composite server with only the tools that agent requires.
4. Audit and review — Log every tool call. Review periodically to tighten permissions that have drifted.

When your security team asks “what can this agent actually do” — you want to have a specific, accurate answer ready.

Next in the series: Prompt Injection via MCP: A Risk Your Agents Cannot Defend Against Alone

Get Expert Help Deploying MCP Access Control

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.

Book a call with an Obot architect — get expert guidance tailored to your infrastructure and team structure.

Or try Obot on GitHub and start building your access control foundation today.

Get Started with Obot

Try Obot on GitHub · Schedule a demo · Read the docs