Series: Enabling MCP at Enterprise Scale — Post 10 of 10
Ten posts. One series. This is where it all comes together.
We’ve covered OAuth complexity, identity sprawl, Dynamic Client Registration, token brokering, IdP integration, access controls, auditing, prompt injection, and PII leakage. This final post pulls it into a single reference — the MCP enterprise architecture, the layers, and a checklist you can use to evaluate where you are and what’s left to do.
Everything in this series connects back to one decision: where does auth and governance live in your MCP stack?
The answer that scales is a control plane. Not auth in every MCP server. Not governance bolted on after the fact. A single layer between your MCP clients and your MCP servers that handles identity, access, tokens, filtering, and audit logging — once, for everything.
Your MCP servers get to focus on tools, resources, and prompts. The control plane handles the rest.
That’s the MCP enterprise architecture. Everything else is configuration.
What the Stack Looks Like
The architecture has four components. Each has a distinct role:
MCP clients — IDEs, chat interfaces, agent frameworks, custom applications. They authenticate to the control plane using your enterprise IdP. They receive scoped tokens. They call tools.
The control plane — sits between clients and servers. Handles DCR so clients can register dynamically. Manages OAuth to your IdP and to MCP authorization servers. Brokers tokens so raw OAuth credentials never reach clients. Enforces registry-based access controls. Filters tool responses for PII and prompt injection. Logs every tool call with full user identity and timestamp.
MCP servers — tools, resources, prompts. No OAuth code. No token storage. No access control logic. They connect to the control plane and inherit everything.
Your enterprise IdP — Entra, Okta, or equivalent. The source of truth for user identity and group membership. Access follows IdP group membership; revocation is automatic when group membership changes.
Here’s the data flow for a typical tool call:
MCP client authenticates to the control plane via enterprise IdP
Control plane issues a scoped token to the client
Client calls a tool using the scoped token
Control plane validates the token, checks registry access, applies filters
Control plane exchanges internally for the OAuth token and calls the MCP server
Tool response passes back through the filter layer
Filtered response returned to client
Everything logged with user identity, timestamp, server, and tool identifier
The Four Layers of MCP Enterprise Architecture
It helps to think about this in layers, because you can build them incrementally and each one adds meaningful value on its own.
Identity Layer
Who can authenticate and how. Enterprise IdP integration, DCR endpoint for MCP clients, token brokering so raw OAuth tokens stay inside the control plane. This is the foundation. Get this right first.
If you’re new to why this matters, MCP authentication is harder than it looks — the first post in this series walks through exactly what production-ready OAuth for MCP actually requires.
Access Layer
Who can reach what. Registry-based MCP server access scoped to IdP groups. Tool-level controls within each server. Agent-scoped composite servers for autonomous workloads. This is where least-privilege becomes operational rather than aspirational.
For a deeper look at how access control for MCP servers works in practice — including IdP group sync and tool-level permissions — that post covers the implementation in detail.
Audit Layer
What happened and when. Every tool call logged with full context. Filterable, exportable, retained according to your compliance requirements. Token revocation that’s immediate and audit-logged. This is what your security team needs to say yes.
Data Layer
What flows through the stack. PII detection and redaction in tool responses before they reach LLM context. Prompt injection filtering before injected content can influence agent behavior. Configurable per tool, with every filtering decision logged.
You don’t have to build all four layers at once. But you should know which layer you’re on and what it will take to get to the next one.
Try Obot Today
⬇️ Download the Obot open-source gateway on GitHub and begin integrating your systems with a secure, extensible MCP foundation.
Building It Incrementally
Starting out: Get the identity layer in place first. Consolidate OAuth into a control plane, integrate your enterprise IdP, and get token brokering working. Even with no access controls or filtering yet, this is a significantly stronger posture than OAuth in every MCP server.
First production deployment: Add the access layer. Create registries, assign them to IdP groups, and configure server-level access. This is enough to get through most security reviews for non-sensitive workloads.
Mature deployment: Add the audit and data layers. Tool-level access controls, comprehensive logging, PII filtering on tools that touch sensitive data, prompt injection filtering for tools that retrieve external content. This is what enterprise-grade looks like.
The sequencing matters. It’s easier to start with tighter controls and expand access as trust is established than to start open and try to restrict after people are already relying on it.
If you want a broader framework for thinking about where your organization sits today, the MCP Maturity Model maps these stages to a full readiness framework with stage definitions and implementation guidance.
The MCP Enterprise Architecture Checklist
Use this to evaluate where you are. It maps to the four layers above.
Identity Layer
OAuth handled in the control plane, not in individual MCP servers
DCR endpoint available to MCP clients
Enterprise IdP integrated (Entra, Okta, or equivalent)
Token brokering in place — MCP clients don’t hold raw OAuth tokens
Token revocation tested end-to-end
Access Layer
MCP server access scoped by user group via registries
Registries synced to IdP group membership
Tool-level access controls configured per registry
Agent-scoped composite servers defined for autonomous workloads
Offboarding process verified — IdP group removal ends MCP access automatically
Audit Layer
Audit logging enabled for all tool calls (tools/call, resources/read, prompts/get)
Logs include user identity, timestamp, server, and tool identifier
Log filtering and export working
Retention policy set to match compliance requirements
Auditor role assigned to compliance and security reviewers
Data Layer
MCP tool responses audited for PII exposure
PII filters configured for high-risk tools
Prompt injection filtering enabled for tools that retrieve external content
Filtering decisions logged
Filter configuration reviewed and tuned against real tool response samples
The Questions You Should Be Able to Answer
Before you call an MCP deployment production-ready, you should have confident answers to these:
Who has access to which MCP servers, and how is that controlled? Registry-based access tied to IdP groups, with tool-level controls within each registry.
What happens when someone leaves or changes roles? Their IdP group membership changes and MCP access follows automatically.
Do we have an audit trail of every tool invocation? Yes — user identity, timestamp, server, tool identifier, logged centrally.
Can we revoke access immediately if something goes wrong? Yes — revocation at the control plane level, effective immediately, audit-logged.
Are OAuth tokens secure? They stay inside the control plane. MCP clients hold scoped tokens that can’t be used outside of MCP.
What sensitive data flows through MCP tool calls? Known, documented, and filtered at the control plane before it reaches LLM context.
How are we protecting against prompt injection? Filtering at the control plane, agent-scoped tool sets, and audit logging as a detection layer.
If you can answer all of these, you’re ready for production. If some are still open, you know what to work on.
Where to Start If You’re Greenfield
Start with the MCP gateway control plane pattern from day one. The cost of retrofitting auth consolidation onto MCP servers that are already in production is high — both technically and organizationally. Getting the identity layer right before you have more than a handful of MCP servers is significantly easier than doing it after.
If you already have MCP servers in production without a control plane, the migration path is real but manageable. Start by identifying which servers have the weakest OAuth implementations and highest data sensitivity. Migrate those first. The rest can follow on a schedule that works for your team.
Bottom Line
MCP is going to be a significant part of how enterprises deploy AI agents. The teams that get the governance model right early will move faster later — because they won’t be retrofitting security controls onto something that’s already in production with users who depend on it.
The MCP enterprise architecture isn’t complicated. A control plane that handles auth, a registry system that handles access, audit logging that handles visibility, and filters that handle data protection. Build it in layers, start with identity, and expand from there.
That’s the path from “we have some MCP servers” to “we run MCP as a platform.”
This post is the final entry in Obot’s series on enabling MCP at enterprise scale. If you’re ready to get started, Obot is an open source MCP gateway that implements everything in this post — identity control plane, registry-based access, audit logging, token brokering, and filtering. Try it on GitHub or learn more at obot.ai.
