Enterprise MCP Authorization
What are the options to secure and authorize your enterprise MCP servers?
Nearly all the publicly available enterprise MCP servers don't have any access control whatsoever. The information was released by security researchers who discovered that around 1,800 MCP servers are publicly exposed. From those, they analyzed less than 10% to confirm their suspicions. All the analyzed MCP servers were totally available to unauthenticated clients. While you might feel the risk is low, remember that some enterprise MCP servers connect directly to internal resources that would otherwise be protected from public access. If you're running or are planning on running an MCP server, perhaps you should think about authorization. What are the available options? Keep reading to learn more.
This article is brought to you with the help of our supporter: Speakeasy.
Turn your API platform into an AI platform with Gram by Speakeasy. Create tools from OpenAPI, curate into custom toolsets, and deploy hosted MCP servers.
The stakes are high. Enterprises want their AI systems to access internal resources. But not all AI systems are well-equipped to handle modern authorization properly. It's this combination that makes releasing unauthenticated MCP servers the easiest possibility for many enterprises. To create a better perspective, let's analyze the timeline that led us here. Anthropic released MCP publicly in September 2024. However, it was not until March 2025 that it had proper authorization. This gap of around six months was one of the reasons why so many MCP servers were built without any access control. In the rush to offer AI access to enterprise resources, teams launched what they thought would never be accessible outside of protected networks. The reality, however, is different, according to security researchers, as many of those early MCP servers are fully accessible from public networks. In any case, it's not too late to fix the situation. So, how do you add authorization to an MCP server?
One way to secure an MCP server is to make sure it's only accessible inside a protected network. Damage is limited if no one outside your enterprise network can access your MCP server. This is, however, not always possible if the LLM you're using is cloud-based. In other words, if the LLM isn't deployed in the same network as the MCP server, access control requires more than network-based restrictions. The second option is to add OAuth-based authorization to your MCP server. After all, this is the preferred method, according to the MCP standard. But it's not easy to implement, mostly because the proposed OAuth patterns aren't widely used, and tooling is somehow lacking. The third option, and one that is gaining adepts, is to use something popular in the enterprise market: SSO. Through the usage of technologies such as SAML, you can make sure that MCP servers understand who is connecting and activate the appropriate authorization policy. This third approach guarantees the MCP servers are still accessible by the LLM, wherever they are, and users are authenticated to existing and trusted systems.
Securing an MCP server by adding SAML means it has to connect to your preferred identity provider. Typically, the work involves adding the right certificates to your MCP server and protecting all requests by using a well-maintained library. If you work with Ruby, you can use the popular OmniAuth authentication system. I'm one of the contributors to the omniauth-saml gem, and I can tell you it's a great way to implement SSO. The difficulty varies depending on the programming language and framework you're using on your MCP server. If you have one or just a few MCP servers to maintain, implementing authorization yourself is probably the preferred path. Otherwise, you might want to centralize authorization on a gateway. There are open-source and commercial solutions that let you add a layer of SAML to API requests and configure which users and groups of users can access certain endpoints. The offerings are relatively new, but the market is picking up due to existing and growing demand.
As you can see, there is no one-size-fits-all solution. While building the whole thing yourself might be tempting, you'll face maintenance costs in the long term. Adding to that cost is the variety of programming languages and frameworks you need to support. Conversely, if you opt for using an out-of-the-box gateway, you'll be dependent on it for the foreseeable future. In fact, the more you grow the number of MCP servers in your organization, the more the gateway becomes a bottleneck and a point of failure. In the end, it all comes down to weighing the cost of maintaining a custom solution against the long-term cost of subscribing to a commercial gateway service.
Whether or not you decide to go with SAML, you'll have to fix the issue of having open-access MCP servers. The big alternative to SAML is OAuth, which isn't easier to implement and maintain, given how little experience the whole industry has. If I were you, I'd pick a couple of my most-used MCP servers and I'd build a custom SAML-based solution myself. I'd then measure the implementation and maintenance costs against the benefit of having proper access control. With that information, I'd be able to decide how to move forward using one or several of the available options.