MCP enterprise architecture: the control plane model that scales

At a glance

What this is: This is a reference architecture for enterprise MCP that places identity, access, audit, and data protection in a central control plane rather than inside each server.

Why it matters: IAM and NHI teams need this model because it changes where least privilege, token handling, logging, and data filtering must be enforced for MCP deployments to scale safely.

Context

MCP enterprise deployments fail when identity and governance are dispersed across each server, because that pushes OAuth handling, access decisions, and logging into places that are difficult to standardise. The article argues for a control plane model that keeps those decisions central while MCP servers focus on tools, resources, and prompts.

For identity and access teams, the architectural issue is not whether MCP can connect AI clients to enterprise systems, but where trust is established and how it is revoked. Centralising that layer changes how organisations think about MCP governance, especially when clients, servers, and enterprise IdPs all have to align.

Key questions

Q: How should teams design MCP so identity and access scale across many servers?

A: Use a central control plane to authenticate clients, broker tokens, and enforce registry-based access so each new server inherits the same governance model. That prevents per-server auth logic from becoming a fragmented trust boundary and makes revocation, audit, and policy updates consistent across the estate.

Q: Why do raw OAuth tokens create risk in MCP environments?

A: Raw tokens expand the compromise surface because they can be reused outside the intended workflow and often outlive the session that created them. Keeping token custody in the control plane lets the enterprise scope, revoke, and audit access without exposing long-lived credentials to every client or integration.

Q: What breaks when MCP access controls stay embedded in each server manifest?

A: Configuration drift breaks first. Inline controls are easy to copy incorrectly, hard to audit centrally, and difficult to retire when the schema changes. Over time, the same permission logic diverges across manifests, which creates inconsistent tool exposure and makes least privilege impossible to prove at fleet level.

Q: How do security teams decide when an MCP deployment is production-ready?

A: A deployment is production-ready when identity is centralized, access is group-scoped, tool calls are logged, revocation is tested, and sensitive data is filtered before it reaches model context. If those controls are missing, the system may be functional but it is not yet governable.

Technical breakdown

Why a control plane is the governing boundary for MCP

MCP uses a client-server pattern, but enterprise scale adds a separate governance boundary above the protocol itself. A control plane sits between clients and servers to authenticate users, broker tokens, enforce registry-based access, filter tool responses, and log every invocation. That separation matters because it removes security logic from each server and turns it into a central policy layer. In practice, the control plane becomes the place where identity, access, and data handling are normalised across multiple MCP servers and environments.

Practical implication: treat the control plane as the enforcement point for access, token handling, and audit rather than duplicating those controls per server.

How token brokering changes OAuth exposure in MCP

The architecture keeps raw OAuth tokens inside the control plane and gives MCP clients only scoped tokens for the MCP session. That matters because clients can authenticate to the enterprise IdP without becoming long-term holders of reusable credentials. The control plane then exchanges internally for the actual OAuth token when it needs to call a server. This reduces token sprawl, simplifies revocation, and prevents clients from retaining credentials that can be reused outside the intended MCP path.

Practical implication: design MCP so clients never receive reusable OAuth credentials and revocation can happen centrally without touching each server.

Why audit logging and data filtering belong in the same layer

Enterprise MCP needs more than access checks. It also needs a record of who called what, when, and through which server, plus filtering for PII and prompt injection before responses reach LLM context. The article ties these together because visibility without filtering leaves sensitive data exposed, while filtering without logging weakens investigations and compliance evidence. In a mature deployment, the control plane records every tool call, applies response filtering, and makes the whole chain auditable.

Practical implication: align logging, filtering, and retention in one governance layer so you can detect risky tool use and prove what data moved where.

Threat narrative

Attacker objective: The objective is to reach enterprise tools and sensitive data through MCP paths that lack centralised identity, access, and filtering controls.

1. Entry occurs when an MCP client authenticates to enterprise systems without a central control plane, forcing each server to handle its own OAuth and access logic.
2. Credential exposure follows when raw OAuth tokens are stored or passed through clients instead of remaining inside a governed token-brokering layer.
3. Escalation happens when access controls, filtering, and audit logging are inconsistent across servers, creating unmanaged paths to sensitive tools and data.
4. Impact is centralised control failure: the organisation loses visibility, revocation speed, and reliable enforcement over AI-driven tool use.

Breaches seen in the wild

• Gemini AI Breach — Google Calendar Prompt Injection: Gemini AI assistant prompt injection attack leaks sensitive Google Calendar data.
• Gemini CLI prompt injection flaw 2025: Tracebit showed a poisoned README could make Gemini CLI run hidden commands and exfiltrate developer secrets; Google fixed it in 0.1.14.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Control plane governance is the only MCP model that scales cleanly: once identity, access, filtering, and audit are distributed into individual servers, every deployment becomes a custom security project. A central control plane turns those concerns into a reusable policy boundary instead of a per-server implementation problem. That is the architectural shift enterprises should evaluate first.

Per-server auth is an identity sprawl problem in disguise: MCP servers that each manage their own OAuth, access rules, and logging create inconsistent trust zones and weak offboarding behaviour. The result is not just operational duplication, but uneven revocation and audit quality across the stack. The practitioner takeaway is that governance has to be standardised before scale creates drift.

Identity does not select or combine tools dynamically mid-session was designed for a world where control is anchored in stable server boundaries: that assumption fails when MCP clients, tool calls, and filtering decisions are coordinated across a shared control plane. The implication is that organisations should stop treating MCP security as a collection of server settings and instead treat it as platform governance.

Named concept: control plane security boundary: the place where enterprise identity, authorisation, token handling, filtering, and audit are enforced consistently for all MCP traffic. Once that boundary exists, the server layer can be simplified and the control model becomes auditable, testable, and portable across environments. Practitioners should assess whether their current MCP design already has this boundary or only the appearance of one.

What scales in MCP is governance, not fragmentation: the article’s layered model shows that teams can add identity first, then access, then audit, then data controls without rebuilding the stack each time. That sequencing matters because it lets organisations expand safely while preserving a single source of truth for access and visibility. The practical conclusion is to build for central enforcement, not retrofitted consistency.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Control plane security boundary: enterprise MCP becomes governable only when identity, access, filtering, and audit live in one place instead of being reimplemented per server. That boundary is what lets teams scale without multiplying security exceptions.

Access reviews and offboarding controls work better here when they inherit IdP group membership and central token revocation, because the control point is shared across all clients and servers. The practical shift is from server-by-server trust to platform-level enforcement.

The same design also reduces the chance that prompt injection or PII leakage becomes a blind spot, because filtering decisions can be logged and applied before responses reach model context. That makes the MCP control plane a governance layer, not just an integration layer.

For practitioners

• Implement a central MCP control plane Move authentication, token brokering, access policy, and audit logging out of individual servers and into one governed layer that all clients must traverse.
• Keep raw OAuth tokens out of clients Issue scoped tokens to MCP clients and perform any exchange for backend OAuth credentials inside the control plane so client-held credentials cannot be reused elsewhere.
• Bind server access to IdP group membership Sync registries with enterprise IdP groups so joiner-mover-leaver changes automatically alter which server groups, tools, and resource paths remain reachable.
• Log every tool invocation centrally Capture user identity, timestamp, server, and tool identifier for each tools/call, resources/read, and prompts/get event, then retain and export those logs for review.
• Filter tool responses before LLM context Apply PII redaction and prompt-injection filtering at the control plane for tools that touch sensitive data or ingest external content, and log every filtering decision.

Key takeaways

• MCP scales more safely when identity, access, filtering, and audit are centralised in a control plane rather than distributed across servers.
• The architectural choice is also a governance choice, because it determines where tokens live, where revocation happens, and where evidence is recorded.
• Teams that standardise MCP governance early are better positioned to expand access without rebuilding security controls after deployment.

Key terms

• MCP Control Plane: The policy layer that governs which identities can reach which MCP servers and tools. In practice, it centralises registration, authorisation, and audit so access does not depend on the specific AI client a person or workflow happens to use.
• Token Brokering: Token brokering is the process of mediating downstream access by exchanging, forwarding, or minting credentials on behalf of an agent. It lets a central identity layer decide which upstream service gets which privilege, which is why it is a core design pattern for controlled agent access.
• Registry-based access: A permission model where MCP server access is assigned through a registry mapped to IdP groups rather than hardcoded into each server. It makes least privilege, review, and offboarding easier to apply consistently across many tools and deployments.
• Audit logging layer: The part of an architecture that records who did what, when, and against which resource or tool. For MCP, it captures user identity, timestamps, server names, and tool identifiers so security and compliance teams can reconstruct activity and prove governance.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.