Overview
As enterprises rapidly adopt AI agents, securing their access to internal tools, data, and LLMs is critical. In this demonstration, Sheikh Ahmed, Senior Sales Engineer at NetFoundry, explains how to establish identity-first, zero-trust connectivity for AI workloads. By integrating Okta for identity authentication with NetFoundry’s zero-trust network, organizations can ensure AI agents only access explicitly authorized resources, eliminating the risks of broad network reachability and exposed public IP addresses.
3 Key Takeaways
- Identity is the Foundation: AI agents require dedicated, verified identities (such as M2M applications in Okta) to ensure they only reach specific, authorized internal tools and services.
- Network Reachability Must Be Controlled: Authentication alone is insufficient; a zero-trust network layer like NetFoundry must enforce exactly where the authenticated agent can connect, preventing independent network connection attempts.
- Purpose-Built AI Gateways Deliver Strict Control: NetFoundry’s MCP and LLM gateways provide centralized visibility, load balancing, tool filtering, and strict policy enforcement to maintain least-privilege access for AI enclaves.
FAQs
Why is network reachability a concern for AI agents? If internal services like MCP servers or LLM gateways are exposed through a public IP and open port, network connections can be attempted independently of the identity used at the application layer. Controlling network paths ensures that even authenticated agents cannot move laterally beyond their explicitly authorized services.
How do Okta and NetFoundry work together in this architecture? Okta acts as the external identity provider to authenticate the AI agent’s credentials by creating a dedicated M2M application. NetFoundry uses that validated identity to dynamically establish a private, encrypted network path strictly to the authorized service before the connection is allowed.
What does the NetFoundry MCP Gateway do? The NetFoundry MCP Gateway manages aggregation, tool filtering, and per-client session isolation across different internal tools, ensuring AI agents only interact with what they are explicitly permitted to access.
Transcript
(Assuming you wanted the provided text transcribed based on its actual contents, please note the requested speakers—David Spark, Howard Holton, Galeal Zino—are not present in the source material. The transcript below reflects the sole speaker, Sheikh Ahmed.)
Sheikh Ahmed Hi, I’m Sheikh Ahmed, senior sales engineer at NetFoundry. We are seeing enterprises rapidly adopt AI agents, and these agents need to access the same internal tools, data and LLMs that their employees and applications rely on. Security teams are naturally looking to the IDP infrastructure they already have in place to establish and verify that identity. And yes, that’s an important foundation. But as AI agent start interacting with internal applications and services, there is another question to answer. Once we know who the agent is, how do we make sure it can only reach the specific resources it’s authorized to access? That’s the gap. Knowing who the agent is isn’t the same as controlling where it can connect and what it can reach. Identity needs to actively govern the network as well as the application access. And that’s what I’ll demonstrate today with NetFoundry and Okta.
The same identity provider your workforce already uses to authenticate can also be used to establish a dedicated identity for the AI agent, authenticate it onto the network, and then provide it with secure, policy-based access to the specific tools and services it requires. The IDP answers an important question: Is this a valid, authenticated identity? But when an AI agent starts accessing internal services, authentication is only one part of the picture. We also need to control where that identity can connect and what it can access. First, there is network reachability. If an MCP server or LLM gateway is exposed through a public IP and open port, the network connection can be attempted independently of the identity used at the application layer. The token is then evaluated by the application or service after the connection reaches it.
Second, a token is a bearer credential. If it is copied or reused outside its intended context, the application may have limited visibility into where the credential is being used. The identity provider establishes and validates the identity, but it isn’t necessarily enforcing the network path between that identity and the resource. What I’ll show is how NetFoundry extends Okta identity into the zero trust connectivity layer, so identity can be used not just to authenticate the agent, but also to control which services it can reach and how securely it reaches them, without introducing a separate identity system. This means the authentication happens before the connection.
In our demo, NetFoundry is configured to trust Okta directly as an external JWT signer. Okta provides the identity, while NetFoundry uses that identity to enforce zero trust, secure policy-based access to the services the AI agent needs. Here is how the two come together. The AI agent requests access to the protected services or MCP tools. The security or the platform team reviews and approves that access through the governance workflow. Once access is approved, two things happen. First, a dedicated M2M application is created in Okta, establishing the application identity and the credentials used to authenticate on the agent’s behalf. Second, a corresponding identity is created in NetFoundry with appropriate policies governing which services that identity can access. The agent’s Okta credentials are used to obtain a token. When that token is presented to NetFoundry, NetFoundry validates it against the trusted Okta signer and authenticates the agent against its NetFoundry identity.
Once the identity is authenticated and authorized by the applicable service policy, NetFoundry establishes the private, encrypted network path to the service. Separately, when the AI agent calls the MCP tool, the same Okta token is presented again. The MCP server independently verifies that token directly with Okta before allowing the tool access.
Now let me show you how this works in practice. We start with the AI agent requesting access to the protected services or MCP tools. At this point, there is no NetFoundry identity or Okta M2M application provisioned for this agent. So it does not have access to the protected MCP tools, first at the network layer and then at the application layer. The request is then presented to the security or the platform team for approval. The team reviews the request and approves the access.
Now, we provide the agent identity a name. And at the backend, a dedicated M2M application is created in Okta for this AI agent. This establishes the application identity that authenticates the agent. At the same time, the corresponding identity is created in NetFoundry for that AI agent with appropriate service policies governing what it is allowed to access. At this point, the AI agent has an identity in Okta and the corresponding identity in NetFoundry.
Now let’s verify the identity. Here we can see the Okta identity and the corresponding NetFoundry identity. There are two actually distinct things happening here. The first is access governance. NetFoundry trusts Okta as an external JWT signer. When the Okta issued token is presented, NetFoundry authenticates the agent’s identity. Then, NetFoundry services and service policies determine which services this identity is allowed to reach. The second is authentication to the application itself. That same Okta issued token is presented again to the MCP server. The MCP server independently verifies the token before allowing the tool request to proceed. That’s a different check at a different layer.
Now let’s access the calculator MCP tool. Let’s stop and actually look at what just happened. A minute ago this AI agent had no access at all, not at the network layer and not at the application layer. Now it can reach the MCP tool because the connection is allowed over NetFoundry zero trust network, authenticated with the Okta issued token. And the MCP server independently authenticates that same token before granting tool access. That’s the whole story, one identity enforced at both layers. We also have service and service policies in place for the AI agent to access the LLM over the NetFoundry zero trust network. So what we have demonstrated is a complete trust chain. NetFoundry provides identity first connectivity, leveraging Okta as the identity provider and as a workload identity source. The MCP server independently authenticates the AI agent using that same identity.
Let’s actually look at what is behind this. First over in Okta, here is the M2M application that got created the moment the request was approved. You can see it has its own client ID. Now let’s switch over to the NetFoundry console. Here is the auth policy set up ahead of the demo to trust Okta as an external JWT signer. If you look inside the JWT signer, you will see the issuer, the audience, and the JWKS endpoint. This actually verifies that the token signature has come from this Okta tenant. Now here is the agent identity. Notice that the external ID field that is set to the exact same client ID we saw in the Okta. And finally, here is the service. The service defines least privilege access to the MCP server. And then we have the service policy. The dial policy defines which agent can reach which service or tool.
NetFoundry offers a comprehensive zero trust approach for securing AI enclaves. The foundation is identity first connectivity, where AI workloads are authenticated before connectivity is established, and the policy is enforced to achieve least privilege access. When services are embedded behind the NetFoundry rather than exposed directly, this eliminates inbound ports, limits each workload’s reachability to only specific services it is explicitly authorized for. On top of that, we have purpose built gateways for exactly two things an AI agent needs. The NetFoundry MCP gateway handles aggregation and namespacing across tools, tool filtering, and per client session isolation. The NetFoundry LLM gateway gives you Open AI compatible routing across multiple providers, semantic routing, load balancing, and full open telemetry metrics. And across all of it, you get centralized visibility and control. You always know which AI workload is accessing which service, with one consistent policy model enforcing it. Thank you.