In this demo, NetFoundry Sales Engineer Jerome Mills shows how to add the NetFoundry (OpenZiti) SDK to a LangChain agent. The agent then connects to an MCP gateway and an LLM over a private, identity-based overlay network instead of public endpoints.
Most MCP servers and LLM gateways today are reached through public endpoints. That means firewall rules that allow connections before anyone is authenticated. MCP servers hold critical business data, so they become attack vectors. They also create friction between governance and networking teams, which pushes some teams toward shadow IT that nobody can monitor.
NetFoundry takes a different approach. All connections go outbound over port 443, with no inbound ports, firewall rules or port forwarding. Every connection is authenticated and authorized with an X.509 certificate identity before it’s made, and access is checked continuously against service policy.
In the walkthrough, Jerome:
- enrolls the agent from a Jupyter notebook using a one-time JWT
- connects the agent to the MCP gateway and LLM through intercept addresses that hide where the real services live
- removes one attribute in the management console and shows the agent immediately lose LLM access
Three key takeaways
- Identity before connectivity. Each agent gets an X.509 certificate identity, and every connection is authenticated and authorized before it’s made. Authorization keeps running, so a policy change cuts off access immediately.
- AI workloads go dark. All traffic is outbound-only on port 443, so MCP servers, LLMs and their dependencies have no exposed inbound ports. That shrinks the AI attack surface while agents keep access to the data they need. With the SDK embedded, traffic stays dark even on the local host.
- Full visibility and session isolation. Because access is tied to identity, you can see who accessed what, when and for how long, in the NetFoundry console or streamed to your SIEM and SOAR tools. The MCP gateway adds per-client tool aggregation and session isolation.
FAQs
What does this demo show?
It shows how to embed the NetFoundry SDK in a LangChain agent so the agent connects securely to an MCP gateway and an LLM over NetFoundry’s zero trust overlay, with no public endpoints.
Why are public MCP and LLM endpoints a risk?
They need firewall rules that allow connections before authentication. Because MCP servers expose critical business information, those open endpoints are attack vectors for malicious actors, including ones running their own agents.
Do I need to open firewall ports or set up port forwarding?
No. All connections are made outbound over port 443. You don’t need inbound ports, ACL changes or port forwarding rules.
How does an agent get its identity?
It enrolls with a single-use JWT, which creates an X.509 certificate-based identity stored as a JSON file. In the demo, this takes one cell in a Jupyter notebook.
What happens when an agent’s access changes?
Authorization is continuous. In the demo, removing the “LLM client” attribute from the agent’s identity cut off its LLM access right away, and the next request failed.
How does NetFoundry hide where services are located?
Services are reached through intercept addresses in private RFC 1918 ranges. Those addresses don’t exist on the host, so the real location of the MCP server and LLM stays hidden.
What deployment options are there?
There are three: a router that gives access to a whole network, host-level deployment so apps listen only on localhost, or the embedded SDK, which keeps traffic dark even from the local host.
What does the MCP gateway add?
It aggregates and isolates tools per client and provides session isolation, so each agent sees only the tools it’s authorized to use.
Can I monitor what agents are doing?
Yes. Every connection is tied to an identity, so metrics on who connected to what, when and for how long are available in the NetFoundry console. You can also stream them to your SIEM and SOAR tools.
Full Transcript
Hello, my name is Jerome Mills, I’m a sales engineer here at NetFoundry. And today I’ll be going over how easy it is to add our SDK to a LangChain agent to connect to an LLM MCP server. Via our overlay. Current connections to MCP servers and LLM gateways are done through public-facing endpoints. This means firewall configurations that allow connectivity before authentication. MCP servers access critical business information, which allows for the agents to make good decisions. But ultimately, they’re attack vectors for malicious actors with their own agents. This means governance team needs to work with the networking team to update ACLs and configure port forwarding rules, and because of this, many teams use shadow IT tools to gain access into critical infrastructure with no way to monitor or report usage.
Using NetFoundry. All connections are done via outbound, Port 443. There are no firewall rules, no port forwarding. Everything is hosted with inside the local network, and can even be done down to the local host. All authentic. All connections are authenticated and authorized. with their identity in the form of an X509 certificate before they make the connection. Applications are only available via services, and can be as explicit as one host-port combination, or as wide as a whole subnet. The authorization is ongoing so that any changes in the service policy will immediately disconnect the identities which no longer have the access. And because we’re a software solution, we can be deployed in a multitude of ways. Either as the router that allows access for inside the entire network.
At the host level, meaning the applications only need to listen on the local host. Or even the SDK, keeping the traffic even dark, even from the local host itself. And since all connections are done at the identity level, metrics about who connected to what are readily available via our UI, or you can stream into your company’s SIM and SOAR tools. And now we’ll get right into the demo. Here I have my LangChain agent. It currently has access to the LLM client, the MCP Gateway. using these 2 attributes. I have here the one-time use JOT file that I’ll go ahead and add here into my… Jupyter Notebook. You’ll see I’ve imported the OpenCD library, and this cell here is going to use that single-use jot file. to enroll into the net foundry overlay. and create the Json in the form of the identity. From there you’ll see that the base URL For both the MCP server and the LLM. Are in different 1918 address spaces. These are used in the intercept and can obfuscate where the actual source service is located. And neither of these address spaces exist here within the host.
Go ahead and start the cells. And in a couple minutes, we’ll go ahead and see the output, which is going to show me which tools I have access to. We see here that the agent identity was created in the JSON file. And then here… I have access to the tools. I go back here into the… management console. Click on the identity. First, we’ll see it’s online. And if I go ahead and remove the LLM client attribute. I’ll no longer have access to that LLM. And if I rerun this command. It’ll spit out an error, as we no longer have connectivity. Now, in this demo, we’ve seen And with our tool. We have the identity first zero trust solution. You have that X509 certificate. It allows for policy-based access, and we authenticate before connecting to the service. Because there’s no inbound ports, we can isolate those AI workloads and their service dependencies, reducing the AI attack service within your network, while still allowing access to that critical information that these agents need. Using the MCP gateway, we can further isolate and aggregate The tools on a per-client basis, and allowing for session isolation. And finally, because everything is done at the identity level. We’re able to see who can access what, for how long, and at what time. And so this helps us to further understand the agents and what they’re doing.
Thank you very much for your time. Have a great day.