MCP enterprise architecture: the control plane model that scales

At a glance

What this is: This is an architectural reference for enterprise MCP deployments, and its core claim is that a centralized control plane is the only scalable way to govern identity, access, tokens, logging, and data filtering.

Why it matters: It matters because IAM, NHI, and agent governance teams need a model that prevents auth sprawl, reduces token exposure, and creates consistent enforcement across AI clients and MCP servers.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• NHIs now outnumber human identities by 144:1 in enterprise environments, a 44% increase year-over-year driven by AI agents, CI/CD automation, and third-party integrations.

👉 Read Obot's full MCP enterprise architecture reference

Context

MCP enterprise architecture is the governance question underneath the protocol: where do identity, access, token handling, and audit responsibilities live when AI clients connect to enterprise tools. In this series, the central answer is a control plane, because pushing auth logic into every MCP server creates the same sprawl identity teams have spent years trying to remove.

That framing fits broader NHI governance patterns as well. When service accounts, API keys, tokens, and AI clients all participate in the same access path, the problem is not the protocol itself but whether the enterprise has a stable place to enforce policy, revoke access, and inspect tool use.

The article’s model is typical of what mature teams eventually converge on: centralized governance first, then layered controls for access, logging, and filtering. The architectural shape is familiar even if the protocol is newer.

Key questions

Q: How should teams govern MCP server access as their fleet grows?

A: Start by moving away from per-server handwritten policies and toward named roles, IdP group bindings, and a separate narrowing layer for sensitive servers. That structure keeps tool access auditable, reduces drift, and prevents every new server from becoming a custom authorization project. Governance becomes scalable when access is expressed in reusable policy objects, not isolated files.

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.

NHI Mgmt Group analysis

Enterprise MCP needs a governance control plane because distributed auth is an identity anti-pattern. The article’s architecture solves the same problem NHI teams face when secrets, tokens, and access checks are scattered across systems. Centralizing identity, token brokering, registry policy, and audit logging reduces the number of places where governance can fail. The practical conclusion is that MCP should be treated as an identity platform decision, not a server-by-server integration choice.

Standing token exposure is the wrong default for MCP client design. The post correctly pushes raw OAuth credentials out of clients and into the control plane. That matters because every place a long-lived token exists becomes both a compromise target and an operational dependency. For practitioners, the lesson is that token custody belongs where revocation, logging, and scope enforcement can be governed together.

Identity blast radius is the right way to evaluate MCP server sprawl. The article’s registry and group-scoping model is really about containing the impact of tool access. Once an MCP deployment grows beyond a few servers, the question becomes how much damage one mis-scoped client or tool can do. Practitioners should measure the number of servers, tools, and sensitive paths reachable from any one identity.

Auditability is not a reporting feature in MCP, it is the control that makes the model defensible. Logging user identity, timestamp, server, and tool identifier turns tool use into an accountable event stream. Without that layer, access reviews and incident response both lose the evidence they need. The operational implication is that production MCP governance must assume every tool call will need to be explained later.

Incremental deployment only works if the first layer is identity, not convenience. The series is right to sequence identity before access control and data filtering. That sequencing matters because once business teams depend on the system, retrofitting governance becomes harder than designing it upfront. Teams should use that ordering to set migration priorities and production-readiness gates.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which is why credential custody has to be centralized.
• That visibility gap is the reason to review Ultimate Guide to NHIs , Key Challenges and Risks as you map MCP governance to identity controls.

What this signals

Identity control planes are becoming the practical boundary between experimentation and governed MCP deployment. As more enterprises connect AI clients to internal systems, the difference between a pilot and a platform is whether revocation, logging, and policy live in one enforceable place. Teams that wait until server sprawl is established will find that the governance problem is already embedded in the architecture.

Identity blast radius: the meaningful unit of MCP risk is no longer a single server but the set of tools, resources, and data paths reachable from one client identity. That shifts programme planning toward registry design, group-based scoping, and response readiness rather than isolated server hardening.

With 96% of organisations storing secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, per the Ultimate Guide to NHIs, the same discipline must be applied to MCP token custody and tool-response filtering. The next governance step is to decide which integrations are safe enough to bring under a central control plane first.

For practitioners

• Centralize MCP authentication in a control plane Move OAuth handling out of individual MCP servers and into one governed layer that brokers tokens, enforces scopes, and keeps raw credentials out of clients.
• Tie server access to IdP group membership Use registry-based access so user and role changes in the enterprise IdP automatically change which MCP servers and tools are reachable.
• Log every tool invocation with identity context Capture user identity, timestamp, server, and tool identifier for tools/call, resources/read, and prompts/get so access and incident review have a single source of truth.
• Filter sensitive responses before they reach LLM context Apply PII redaction and prompt injection filtering at the control plane for tools that return external or sensitive content, and log every filtering decision.

Key takeaways

• MCP governance fails when auth, access, and audit are distributed across servers instead of centralized in a control plane.
• The most important control decision is token custody, because raw credentials in clients turn protocol convenience into identity exposure.
• Production-ready MCP depends on group-scoped access, full tool-call logging, and data filtering before sensitive content reaches model context.

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.
• 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.
• 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.
• Tool-call audit trail: A record of every MCP interaction that captures who acted, what tool was called, when it happened, and which server responded. In practice, this is the evidence base for access review, incident investigation, and compliance reporting.

What's in the full article

Obot's full post covers the operational detail this post intentionally leaves for the source:

• Step-by-step MCP gateway sequencing for identity, access, audit, and data layers.
• Checklist items for production readiness, including revocation testing and tool-call logging.
• Practical filtering guidance for PII exposure and prompt injection in tool responses.
• Migration guidance for teams moving from server-level auth to centralized governance.

👉 Obot's full post covers the control-plane model, layered rollout, and production checklist in operational detail.

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 building or maturing an IAM or NHI governance programme, it is worth exploring.