Building an Enterprise MCP Platform - Vol. III: Ironclad Access & Security
Tackling the critical challenges of authentication, authorization, and secure governance for internal AI protocol servers at scale.
The world, the place you live in, is the sick place. Seahaven is the way the world should be.
— Cristof, The Truman Show
A safe place is important in technology as well, and you cannot ask every single user to implement security on their own.
Previously on Building an Enterprise MCP Platform...
We’ve built the foundation. Before we tackle how to lock down and secure our platform today, let’s quickly review the core decisions we’ve made so far:
Vol. I (Deployment) - The Where: We escaped the localhost trap by moving MCP servers to the cloud. We mapped out our compute options, choosing AWS Fargate for low-latency, persistent SSE connections, and AWS Lambda for sporadic, stateless utility tools.
Vol. II (Delivery) - The How: We automated the journey. We chose Docker to guarantee execution consistency and used Crossplane (or CI/CD pipeline wrappers) to abstract away the cloud infrastructure, letting developers ship code through simple, reusable YAML interfaces.
In today’s email, you will get the answer to the ultimate production question: How do we control who is actually allowed to talk to them?
If you are a Software Engineer trying to understand the main challenges at the time of deploying MCP Servers in Production, this email is for you. Know someone who might be interested in this topic? Forward them the email 👇🏻
Let’s continue with the last topic: Security
You have to implement a single point where all the requests are authenticated through your Identity Provider (a.k.a. IDP).
You should not put that responsibility on the developers of the MCP Servers.
Developers should take care of their MCP Server.
You take care of the platform where they deliver that value, including authentication.
Please note that I say Authentication and not Authorization. In my approach, I decided to tackle Authentication only, leaving the possibility to the developers of the MCP Server to implement Authorization, if they want. Why do I do that?
Simplicity. I wanted to keep the platform simple.
Ownership. Each developer/team could have different needs in terms of Authorization (they will get the JWT anyway).
This is a decision you can make; Remember: tradeoffs.
Following the same pattern as before, you will have to implement an AWS Lambda function to act as an MCP Authentication, implementing the OAuth 2.1 protocol.
Below, you can see the architecture diagram, using AWS pieces.
Even though I will not describe the OAuth 2.1 process, let me describe a bit the flow of that architecture diagram:
The AI Client (Claude Code-alike) has an MCP Server configured, but not authenticated. So the authentication process needs to be executed and, for that, a concrete request.
That goes to your AWS CloudFront and from there to the Application Load Balancer. By the way, I picked an ALB, but it could be an AWS API Gateway; there is a small difference for our use case. If you want details about this decision, drop me an email or reach out to me on Bluesky.
The request arrives at the MCP Authenticator, and from there the IDP that your company uses (such as OKTA, Keycloak, etc) will provide the information required by the AI Client to be able to authenticate against the IDP itself.
The AI Client authenticates against the IDP and then requests again to the MCP Authenticator, so this will provide, through the ID, a Token.
Once the AI Client has the token, the following requests will arrive at the MCP Server, with an authentication check in the middle.
This way, you provide an authentication mechanism, transparent to the developers of the MCP Servers, so developers don’t need to implement by themself.
The last part of this architecture is to have a way by which the users, a.k.a. the developers of the MCP Servers, can make their software available under this Authentication wall. For this, remember that your solution must satisfy the following:
Make your developers autonomous. This means that the owners of the MCP Servers must be autonomous in making their software available in your infrastructure.
CI/CD. This means that the owners must work in CI/CD mode, so your solution should be designed for that from the heart. No dependencies with other repos or systems.
Technology already known; don’t reinvent the wheel. This means that your solution should use a technology that is already familiar to your users, so they don’t have to make an extra effort to learn something else.
If you want to know the 2 options I implemented for this, drop me an email by clicking here 👇🏻 and you will get it for free.
Alright! Let’s close for today and the current series.
✨ Takeaways
Before you go, here is a quick summary of the core principles to keep in mind when securing your enterprise MCP platform:
Security belongs to the platform, not individual developers: Do not put the burden of authentication on MCP Server developers. Centralize it at the platform level to free up dev teams and ensure consistent security standards across the organization.
Authentication != Authorization: Decoupling authentication from authorization keeps the platform architecture simple. Handle authentication centrally via OAuth 2.1 and your Identity Provider (Okta, Keycloak, etc.), while leaving token-based authorization to individual server owners based on their specific business logic.
Decoupled Architecture Pattern: Intercept and validate requests before they hit your MCP Servers by routing traffic through AWS CloudFront and ALB (or API Gateway) to a dedicated AWS Lambda function acting as your MCP Authenticator.
Enable developer autonomy: Your platform solution must empower server owners to make their tools available through self-service CI/CD pipelines, relying on familiar tools and patterns so they don’t have to learn a new stack.
This is it; the end of this 3-issue series dedicated to explaining how to enable MCP Servers in the real world. Hope you like it. If yoy have any questions, feedback, or comments, you can reply to this email, drop a comment in Substack, or reach me in Bluesky.
Best,
Marcos.