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 standardizes interactions between ai models and enterprise systems, handling identity, access, tokens, filtering, and audit logging without custom integration code.
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 shown here is the enterprise deployment view with four components, while the underlying model context protocol (MCP) uses a client-server model over a lightweight JSON-RPC interface. Each has a distinct role:
MCP clients — IDEs, chat interfaces, agent frameworks, custom applications. The protocol is an open standard that connects AI agents and LLM-based applications to internal company data sources and business tools across existing business systems. 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, with core components covering tools for actions, resources for read-only access, prompts for templated instructions, transports for communication, and a handshake for capability discovery.
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.
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 Control Layer
This defines who can reach what. Registry-based MCP server access scoped to IdP groups becomes role based access with fine grained access control over specific server groups, tools, or resource paths, using centralized access control policies and a scalable enterprise MCP registry to enforce least privilege. Logical isolation can be implemented with namespaces or server groups aligned to environments or business units, so each business capability stays separated for multi-tenant and compliance needs. This is where least-privilege becomes operational rather than aspirational.
Practical implementation of access control for MCP servers requires IdP group sync, tool-level permissions, and consistent enforcement across every environment where servers are deployed.
Audit Logging Layer
This records what happened and when. Every invocation to a tool, resource, or prompt is logged with rich metadata, including timestamps and user identifiers, creating comprehensive audit trails and clear audit trails. This is filterable, exportable, and retained according to your compliance requirements. Token revocation that’s immediate and audit-logged is what your security team needs to say yes. These records can also feed SIEM and event management tooling for monitoring, alerting systems, and compliance reports.
Try Obot Today
Click here to check out Obot’s Hosted MCP Platform for free, or visit GitHub to deploy our open-source gateway on your own infrastructure.
Data Layer
This is what flows through the stack and includes elements like PII detection and redaction in tool responses before they reach LLM context to support data security, or prompt injection filtering before injected content can influence agent behavior. The MCP server validates requests and responses against registered JSON schemas as part of input validation and output validation, automatically rejecting anything that deviates from the schema to ensure data security and reduce injection risk. It’s configurable per tool, with every filtering decision logged, and should align with critical MCP security best practices.
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.
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. In production environments, MCP deployments need horizontal scaling with load balancing and autoscaling across regions, enabling scalable capacity for concurrent requests while maintaining low latency responses and high availability.
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, especially as emerging MCP security risks make retrofitting governance increasingly expensive.
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
Sensitive tools and resource paths enforce role based access controls with least-privilege policies, aligned with standard OAuth/OIDC flows and RBAC
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. MCP also supports context-aware interactions that pull real-time enterprise data and securely execute actions within enterprise environments.
How are we protecting against prompt injection? Filtering at the control plane, agent-scoped tool sets, and audit logging as a detection layer. That matters because integrating AI into business systems often means AI tools can run multi-step, stateful workflows across multiple systems without human coding intervention, so strong governance controls are essential.
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, and choosing between a single MCP gateway and multiple MCP servers is much easier when governance is centralized from the start. An open MCP architecture supports AI integration across AI models and any backend system, which helps avoid vendor lock-in early. 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. MCP servers provide a standardized bridge for AI applications to reach enterprise data, tools, and workflows without point-to-point integrations, reducing integration sprawl and supporting seamless integration. 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, and they’ll be better positioned to evaluate enterprise MCP gateway options against a clear architectural baseline.
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. By standardizing how AI models connect to diverse systems, the MCP server exposes internal capabilities as Tools, Resources, and Prompts, which simplifies integration, reduces development overhead, and strengthens enterprise security.
That’s the path from “we have some MCP servers” to “we run MCP as a platform,” with centralized governance and audit logging at the gateway level across the broader MCP ecosystem.
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. Get started today for free or try it on GitHub.
