At a Glance
- Enterprises get MCP’s business value when approved clients can reach enterprise-hosted MCP servers, and they take on real risk the moment they expose those servers to make that happen.
- Those clients increasingly run outside your network, in an AI provider’s cloud, so identity and connectivity both have to hold across the boundary.
- Enterprise-Managed Authorization (EMA) centralizes delegated authorization through an IdP you already trust for SSO, using OAuth token exchange and the JWT-bearer grant. It decides who may use a service. It doesn’t build the route to reach one.
- NetFoundry MCP Connect supplies the private path and the network-layer enforcement, with or without EMA, so your private MCP servers keep no public IP, no public DNS, and no internet ingress.
The Client Moved Outside Your Network
For years, the AI client and the data it needed sat on the same side of the firewall. That assumption is gone. The MCP clients your teams want to use now run in an AI provider’s cloud, which means the client calling your private MCP server lives in someone else’s network. Strong identity and secure connectivity both have to hold across that boundary every time, or you’re back to publishing a server to the internet and trusting your perimeter to hold.
Two capabilities have to come together to close that gap: a way to decide who is authorized, and a way to carry their traffic without exposing the server. Enterprise-Managed Authorization handles the first. NetFoundry MCP Connect handles the second.
What Enterprise-Managed Authorization Actually Does
Enterprise-Managed Authorization (EMA) is an optional MCP authorization extension that routes delegated access through an identity provider you already trust for single sign-on. Your employees sign in through corporate SSO, and your administrators govern which MCP services they can reach, without a separate consent prompt for every server.
Under the hood, the client takes an identity assertion it already holds and exchanges it for an Identity Assertion JWT Authorization Grant (ID-JAG) using OAuth token exchange. It then presents that grant to the resource authorization server using the JWT-bearer grant and receives an access token for the MCP resource it intends to call. Anthropic documents Okta support for Claude’s managed connectors at launch, and PingFederate 13.1 can both issue and accept ID-JAG. ID-JAG remains an IETF Internet-Draft, and implementations are still catching up.
That’s real progress. Centralized, administrator-governed authorization is exactly what enterprises have been missing as MCP adoption accelerated.
Authorization Isn’t a Network Path
Here’s where many MCP plans stall. EMA decides whether a client may use a service. It doesn’t create the route to reach it, and it doesn’t establish trust across organizational boundaries on its own. When a hosted or desktop client needs to reach an MCP server inside your VPC or data center, you still have to give its traffic a path, along with the authentication endpoints that client depends on.
The default path is a public one, which puts you right back where you started, with a public IP, a DNS record, and internet ingress for attackers to find. The alternative has usually meant VPNs or private-link plumbing, plus asking the third-party client to change how it connects. Neither is a path enterprises want to run at scale.
Private Connectivity That Needs No Exposure
NetFoundry MCP Connect gives authorized MCP traffic a private path to your servers without a VPN, without a public endpoint, and without asking the third-party client to change anything. The server keeps no public IP, no public DNS record, and no direct internet ingress. Third-party clients connect to an MCP Connect landing zone that runs the configured OAuth flow, applies your policy, and forwards only authorized requests. Your MCP servers hold Zero Trust connections to their landing zones, which keeps them off the internet and out of any partner’s network.
Policy decides which identities may reach each service, and you can hand every partner workload its own separately governed network identity. The server stops being something you defend at the perimeter and becomes something that is simply unreachable unless policy says otherwise.
A Kill Switch That Doesn’t Wait for Token Expiry
Tokens carry a well-known weakness. Once the resource authorization server issues an access token, disabling that user at the IdP doesn’t guarantee that every token and active session dies with it. Short lifetimes, revocation, and introspection all help, and they don’t fully close the window.
NetFoundry MCP Connect adds enforcement at the network layer, independent of token expiry. Revoke an identity or change a policy, and the connection can drop in seconds, whether or not the token has expired. For a security team, that’s the difference between hoping a credential ages out and knowing access is gone now.
Work With EMA, or Without It
EMA is nascent, and you don’t have to wait for it. NetFoundry MCP Connect works today, with or without an EMA integration. Where your client, IdP, and resource authorization server all support EMA, you can pair delegated user authorization with the private path. Where they don’t, supported user or workload authentication flows do the job, and centralizing OAuth at the front door can spare you from standing up an authorization server behind every backend.
Public SaaS talking to public SaaS may need nothing more than a well-governed OAuth deployment. The combination of NetFoundry and EMA earns its keep the moment you need consistent, private access across several agents, providers, or partners, which is the moment enterprise MCP gets real.
Frequently Asked Questions
Does EMA secure the connection to my MCP server?
No. EMA governs authorization, meaning who may use a service and under what policy. It doesn’t build the network route to a private server or establish cross-organization trust on its own. You still need a secured path, which is what NetFoundry MCP Connect provides.
Do I have to expose my MCP server to let a hosted AI client use it?
No. With NetFoundry MCP Connect, the server keeps no public IP, no public DNS record, and no direct internet ingress. Hosted clients reach it through a landing zone that applies policy and forwards only authorized requests over Zero Trust connections.
Can I use NetFoundry MCP Connect before EMA is widely available?
Yes. NetFoundry MCP Connect works with or without EMA. Where EMA is supported across the client, IdP, and resource authorization server, you can pair it with the private path. Where it isn’t, supported user or workload authentication flows cover the same ground.
What happens when I revoke access?
NetFoundry MCP Connect enforces at the network layer, independent of token expiry. Revoking an identity or changing a policy can drop the connection in seconds, rather than waiting for an issued token to age out.
Keep Going
See how NetFoundry delivers private, Zero Trust connectivity for AI and MCP workloads on the NetFoundry platform, or talk to us about securing MCP access in your environment.
