I’ve been writing the last few weeks about enterprise adoption of the Model Context Protocol (MCP) and how it gives organizations a standardized way to connect AI agents and tools with internal applications, systems, and data. I’ve talked about security risks, mcp gateways and proxies. But I feel like I’ve not spent enough time talking about how organizations manage access to MCP servers.
This feels like a big oversight, because if you’re planning to provide MCP servers as an enterprise service, you are going to need to implement enterprise-grade access control that works with your existing identity platforms, scales across teams, is easy to manage by IT and will comply with whatever regulations your industry requires.
In this post, I’ll break down the fundamentals of MCP access control, the risks of neglecting it, and how we approached the problem when we were building the Obot MCP Gateway.
Why MCP Access Control Matters
The power of MCP servers comes because they open up connections to valuable enterprise resources: email systems, CRMs, data, cloud platforms, monitoring tools, and pretty much anything you can imagine. Obviously, without access control, this useful access can quickly turn into risk, including:
- Exposing sensitive data – giving unauthorized user visibility into sensitive systems
- Compliance gaps – failure to enforce role-based permissions that auditors expect
- Operational sprawl – no central control over local MCP servers calling into critical systems
If an MCP server is floating around unsecured, especially with any kind of API access, you’ve recreated the chaos of unmanaged SaaS sprawl—only faster.
Core Principles of MCP Access Control
So, if we’re going to address this risk, and not repeat the mistakes of previous technology generations, we need to adopt some sensible principles around MCP publishing and adoption:
- Centralize MCP access via an MCP Gateway that Integrates with your existing identity provider
– MCP Gateways host MCP servers, and allow you to control access to them using identity providers like Okta, Microsoft Entra, Google, or GitHub. Users should authenticate with the same identity they already use, not allow a new silo to emerge specific to AI. - Granular group-based visibility
– Different teams need different MCP servers. Admins must be able to say:
“Marketing gets Salesforce + Hubspot, Engineering gets GitHub + Datadog, Executives get Tableau and SAP, and everyone gets Office365.” - Proxy enforcement and auditing
– Access rules shouldn’t just live on paper. Every MCP call needs to go through a proxy layer that enforces policy, audits requests, and prevents misuse.
Access control for tools within an MCP server
It might not be enough to control access at the MCP server level. There are certainly times where you may want to restrict access to specific tools within an MCP server. For instance, I might allow an agent to call tools that read data from Salesforce, but not want it to have access to any write capabilities. When you’re setting access control rules for an MCP, consider whether the authorized human or agent needs access to all of the tools within it, and if not, only allow whatever access is necessary.
How Obot MCP Gateway Approaches Access Control
When we built the Obot MCP Gateway, access control was a key requirement we set out to address. To do that, we identified four key elements that we needed to address:
- Global MCP Directory
The biggest challenge with MCP access today is the “grey market” of MCP servers passing between employees who are trying to do their jobs. To address that, it was critical for IT teams to publish a curated catalog of approved and secure MCP servers available across the organization. Whether you are building MCP servers, onboarding them from clients, or leveraging popular servers we provide out of the box, they need to be centralized and under IT governance. - Access Control Integration
We prioritized integration with common Identity profivers (such as Okta, Entra, Google and GitHub) that map users or groups to specific MCP servers. Then provide admins with the ability to define and update access control policies for MCP servers published on the gateway. - Proxy Enforcement
Whether the MCP server is hosted through Obot (on your Kubernetes) or provided remotely by one of your vendors (e.g., AWS, Zapier), every call flows through Obot’s proxy for access verification, auditing, logging, and compliance. - User Experience
Most importantly, for users, getting access to MCP servers needs to be simple and easy. Users should easily be able to discover MCP servers they are authorized to access in their directory. When they connect, Obot issues a unique URL that can be plugged into developer agents (Claude, Cursor, VSCode, etc.) or used inside Obot’s web-based chat client to query multiple MCPs at once.
What Enterprises Gain
By managing access control for MCP servers, organizations can hit all the key issues necessary to scale MCP adoption:
- Security: Users only see and access what they’re entitled to.
- Compliance: All MCP interactions are logged and auditable.
- Efficiency: IT has a single control plane to manage MCP adoption at scale.
- Adoption: Employees gain safe, discoverable access to AI-powered workflows without friction.
Next Steps
If your organization is exploring MCP adoption, don’t wait to bolt on access control later. Build it into your rollout from the start. Obot MCP Gateway provides the secure, scalable foundation to make MCP an enterprise-ready service. You can view the open source project on GitHub, or schedule a demo with one of our field engineers.
