TL;DR
- MCP becomes enterprise-credible only when identity is matched end to end: human user, MCP client, MCP server, and downstream resource. The protocol now defines a real OAuth-based authorization model for HTTP transports, but the spec also makes clear that operational trust still depends on local policy, access controls, and safe tool handling.
- Allowlists are not an optional detail. You need them for trusted clients/domains, approved servers, exposed tools, reachable resources, and outbound discovery URLs. MCP’s current auth guidance explicitly allows domain-based trust policies, and its security guidance warns about SSRF and other discovery-time abuse paths.
- Secrets and tokens need discipline: audience-bound tokens, PKCE, no token passthrough, least-privilege scopes, short lifetimes, and secret storage outside source code. For machine-to-machine access, MCP now has a client-credentials extension, with signed JWT assertions recommended over long-lived client secrets.
- Rollout and revocation are part of the design, not post-launch chores. Local server installs need explicit consent and command transparency; enterprise access should be revocable centrally through the IdP, with short-lived tokens and per-request validation reducing blast radius.
The easiest way to misunderstand MCP is to stop at the demo.
A demo proves that a model can discover a tool, call it, and return something useful. Enterprise deployment asks a different set of questions: which client is asking, on whose behalf, against which server, with what scopes, and how quickly can that access be changed or revoked? MCP now has a formal authorization model for HTTP transports, with the client acting as an OAuth 2.1 client and the MCP server acting as a resource server. But the MCP specification is equally clear about the protocol's limits: implementers still need robust consent flows, access controls, privacy protections, and careful handling of tool invocation, because tools are effectively high-consequence capability surfaces.
The first hard problem is identity matching. In a consumer demo, “the user signed in” sounds sufficient. In an enterprise environment, it is not. You need at least three identities to align: the workforce identity from the corporate IdP, the identity of the MCP client requesting access, and the identity under which the MCP server will actually act on downstream systems. If those do not line up cleanly, your audit trail becomes fiction. MCP’s current authorization work explicitly acknowledges that clients and servers often do not have a pre-existing relationship, which is why the spec now recommends OAuth Client ID Metadata Documents and allows authorization servers to apply trust policies such as domain allowlists, reputation checks, and hostname visibility. Core maintainer guidance also treats client impersonation as a distinct trust problem, especially in desktop and localhost-style flows.
That is why allowlists matter at several layers. Start with a client allowlist: which client IDs, domains, redirect URIs, or attested software identities are acceptable? Add a server allowlist: which MCP servers may this host connect to?
Then a tool allowlist: which tools may this user, team, device posture, or environment invoke?
Then a resource allowlist: which repos, mailboxes, tenants, folders, or datasets are in scope?
And finally, an egress allowlist for metadata discovery and outbound fetches, because MCP’s security guidance explicitly warns that malicious servers can exploit discovery URLs to trigger SSRF against internal services, localhost endpoints, or cloud metadata endpoints. Without these boundaries, “MCP access” becomes an open-ended privilege grant rather than a controlled integration.
Authentication becomes credible only when it is bound to the intended resource and constrained by the principle of least privilege. MCP requires resource indicators, audience validation, and PKCE for authorization-code flows, and its security guidance explicitly forbids token passthrough. In practical terms, that means the token presented by the client should be valid only for the MCP server, and any call the server makes to a downstream API should use a separate token acquired in the server’s own role. Do not let one broad token slosh across the entire chain. The same applies to scopes. MCP supports runtime insufficient-scope errors and step-up authorization, which means you do not have to grant every permission up front. The safer pattern is obvious: read-only discovery first, write scopes later, destructive scopes rarely, and admin scopes only under strong additional controls.
Secrets handling is where many “enterprise” MCP deployments quietly fall back to demo habits. The MCP guidance is direct: do not embed client credentials in code; use environment variables or a proper secret store. For machine-to-machine access, MCP now includes a client-credentials extension precisely because not every integration has a human user available for an interactive browser flow. Even there, the recommended direction is better identity and shorter trust windows: signed JWT assertions are preferred over long-lived client secrets; secrets should live in a secrets manager rather than in source control; permissions should be tightly scoped; and credentials should rotate on a schedule and immediately after suspected compromise. More broadly, raw secrets should never appear in model context, logs, or tool output. The server should broker credentials, not expose them.
Local servers deserve separate treatment. MCP’s security guidance and SEP-1024 both underscore that one-click local server installation can lead to arbitrary command execution unless the client displays the exact command, requires explicit consent, and applies strong sandboxing and privilege restrictions. This is where rollout stops being a packaging question and becomes an operational trust question. An enterprise rollout should use approved packages, version pinning, read-only defaults, audit logging, rate limits, and a kill switch for each server and each tool. In other words: do not import “app store” assumptions into software that can run commands on user endpoints. The protocol can standardize connection semantics, but your rollout process determines whether the deployment is governable.
Finally, design revocation before rollout. MCP now has an Enterprise-Managed Authorization extension for environments where the organization’s IdP should be the policy decision point. That matters because per-user, per-server revocation does not scale: onboarding becomes manual, offboarding becomes brittle, and emergency disablement becomes slow. Central IdP policy gives you a cleaner control plane, but revocation still needs depth: short token lifetimes, per-request token validation, client disablement, group-based policy removal, tool-level deny rules, and emergency server quarantine. If offboarding an employee or disabling a compromised integration still requires touching each MCP server individually, you have not solved the enterprise trust problem. A demo proves capability. Operational trust proves control.
