Series: Enabling MCP at Enterprise Scale — Post 5 of 10
MCP and Shared Service Keys: The Right Problem to Solve
The MCP ecosystem is growing fast. There are useful third-party servers for web search, data enrichment, code analysis, and more. Many of them authenticate with a single API key — same as any other service integration your team runs.
Your company has one SendGrid key. One Twilio account. One Google Maps API credential. Nobody expects every employee to register their own account with every SaaS vendor your team touches. The question is how do you manage the MCP server that holds that key without building a bunch of infrastructure yourself?
What You Actually Need to Solve
When you stand up an MCP server backed by a shared service key, three practical problems show up:
Who should have access to it?
Not everyone in the organization needs access to the data enrichment server. You need a way to say “the sales team can use this, the engineering team can’t” — without writing your own auth layer.
What’s actually being done with it? The downstream service sees one credential, so its logs don’t tell you much. You need visibility at the MCP layer: who called what tool, when, with what inputs.
What happens when the key needs to rotate? If the credential is scattered across config files and developer machines, rotation is a fire drill. It should be a one-minute operation.
The Straightforward Model
A control plane handles all three. The service key lives in one place — the control plane’s secret store. Clients authenticate with their normal corporate credentials (Entra, Okta, whatever you already use). The control plane checks whether that user is allowed to reach the MCP server in question, and if so, forwards the request using the stored service credential.
The third-party server doesn’t change. You don’t implement OAuth. You just put one well-managed credential in one place, and let your existing identity infrastructure decide who gets to use it.
Access control comes from the groups and policies you already maintain in your IdP — not from a parallel system built for MCP specifically.
Audit logging happens at the control plane. Every tool call is stamped with the user’s identity, even though the downstream service only ever saw one key.
Rotation is a single operation in your secret store. No hunting down config files.
Try Obot Today
⬇️ Download the Obot open-source gateway on GitHub and begin integrating your systems with a secure, extensible MCP foundation.
The Short Version
The MCP server just needs to be treated like any other service integration your organization runs — one credential, centrally held, with access decided by your IdP, and enough logging to answer “who used this, and when?” A control plane gives you that without building anything custom. For a deeper look at how this works in practice, see managing access control for MCP servers in the enterprise.
Next in the series: What Your Security Team Will Ask Before Approving MCP in Production
