Notifications
Clear all
Topic starter
19/08/2026 3:46 pm
TL;DR: Enterprise-scale MCP works best when auth, access, audit, and data filtering sit in a control plane rather than inside each server, so raw OAuth tokens never reach clients and governance stays centralized, according to Obot. The key assumption that breaks is that security can be bolted on after deployment; in practice, MCP governance has to be designed around identity, least privilege, and logging from the start.
NHIMG editorial — based on content published by Obot: MCP enterprise architecture that actually works, the complete reference
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.
Questions worth separating out
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.
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.
Q: What breaks when MCP access controls stay embedded in each server manifest?
A: Configuration drift breaks first.
Practitioner guidance
- 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.
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.
👉 Read Obot's full MCP enterprise architecture reference →
MCP enterprise architecture: what does a control plane change?
Explore further
19/08/2026 4:23 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP enterprise architecture: the control plane model that scales
