Charlotte, NC – March 24, 2026 – NetFoundry today announces the availability of its new secure AI enclave capabilities. This extends OpenZiti, the world’s most widely used zero trust open source platform, into enterprise AI environments. New capabilities include zero trust MCP and LLM gateways to address the “AI Connectivity Conundrum” – the conflict between giving AI agents broad access to enterprise data vs. securing the expanded attack surface that their deployment creates, and delivering them at the speed of their development. The release is now available at https://openziti.ai.

NetFoundry is also announcing a limited early access program for upcoming AI capabilities in NetFoundry’s commercial cloud offering. These capabilities will simplify the deployment and ongoing operations of internal AI platforms by eliminating the headaches of network and firewall management while also providing end-to-end visibility of AI system actions.

Registration for the early-access program is available at netfoundry.io/EarlyAccessAI.

To deliver value, business-impacting AI agents must connect across clouds, VPCs, data centers, and edge environments. But exposing AI agents, MCP servers, LLMs, and enterprise data to the network increases the attack surface and adds operational drag. Without strict containment, AI agents behave less like APIs and more like autonomous, social-engineered superusers. And exposing their AI tooling on the network provides a uniquely attractive target for attackers.

NetFoundry’s new AI capabilities replace that model entirely.

“Agentic AI breaks traditional network assumptions,” said Galeal Zino, CEO and Founder of NetFoundry. “Enterprises can’t scale AI using IP-based access controls and static API keys. But with our new Identity-first AI capabilities, enterprises can secure their AI solutions while rolling them out faster and operating them more effectively because agents and MCPs do not get any network access or any API keys.”

The key to this new approach for AI – every AI agent and resource receives its own cryptographic identity. Authorization happens at the service level—not the network level. Connections are ephemeral, continuously authenticated, and fully auditable. Every connection is logged with the identity and policy which enabled it.

Core components are OpenZiti zero trust LLM and MCP Gateways–lightweight software deployed alongside AI agents, MCP servers and in front of protected resources. All connections are initiated outbound to the network overlay, and all connectivity is verified against identity and policy. Therefore all components are invisible to the public internet and internal networks alike. Inbound firewall rules remain “deny-all”—with no exceptions.

For platform teams, this means publishing services and policies just once. For application teams, it means self-service AI agent connectivity without waiting weeks for firewall or VPN changes. The guardrails are already in place – the identities and policies which govern those identities – with the controls and visibility to change policies instead of firewalls and networking.

For more information, visit netfoundry.io/ai-deployment-and-protection or openziti.ai.

About NetFoundry

NetFoundry is the leader in helping businesses simplify and secure connectivity among their widely-distributed workloads, humans, machines and AI agents. Founded by the inventors and maintainers of the world’s most-used open source zero trust software, OpenZiti, NetFoundry’s Identity-First Connectivity™ enables zero trust connectivity with no open inbound ports, no VPNs, and no firewall changes.

The post NetFoundry Extends OpenZiti with Release of First Open Source Zero Trust Enclave for AI Workloads appeared first on NetFoundry.

The recent OpenClaw vulnerabilities sent ripples through the cybersecurity community. Research from the SecurityScorecard STRIKE Threat Intelligence Team revealed that over 20,000 control panels were exposed to the public internet. These panels represent a massive attack surface for credential stuffing, exploit kits, and remote code execution.

However, this headline was a non-event for NetFoundry customers who yawned while the rest of the world scrambled to apply patches. It was also a breeze for OpenZiti user’s – NetFoundry’s open source software

How can NetFoundry customers and OpenZiti users be insulated from any OpenClaw CVE – as well as from CVEs from other AI agents?

1. No Listening Ports, No Exposure

Exploiting the “OpenClaw” vulnerability starts with discovery – same as many cyber-attacks. Attackers used scanning tools like Shodan and Censys to find IP addresses with open ports (typically 80, 443, or 8080) associated with known control panel software. Unfortunately for the attackers, NetFoundry customers do not have any exposed ports.

In the NetFoundry model, a machine, VM or container running OpenClaw opens an outbound-only connection to a private, dedicated overlay. That overlay is self-hosted or hosted by NetFoundry. Either way, there are no open inbound ports for attackers to scan or for attackers to use to enter to exploit a vulnerability

2. Identity-First™ Networking

The exposed panels in the OpenClaw report relied on the traditional “first connect the user, then try to authenticate and authorize the user” model. That model means that anyone with the URL could reach the OpenClaw login page and exploit any vulnerabilities.

NetFoundry flips this model to “identify, authenticate, authorize…then connect IF you are authorized.” That model means nobody with the URL, other than identified, authenticated, authorized users, can reach OpenClaw.

3. Public Pipes, Private Overlays

Many of the panels flagged in the OpenClaw report were exposed because they were hosted on public clouds or home networks where “private” networking is complex or expensive to implement.

NetFoundry creates an instant, dedicated, virtual overlay network that sits on top of the public internet. It treats the internet as “dumb pipes.” By encrypting traffic from end-to-end and managing routing within the overlay, NetFoundry allows administrators to put their OpenClaw control panels on the “private” overlay. This means the panels are reachable by authorized administrators anywhere in the world, but unreachable from the Internet

4. Mitigation of Zero-Day Vulnerabilities

Even if an OpenClaw control panel has a critical, unpatched vulnerability (a “Zero-Day”), an attacker cannot exploit it. The vulnerability should be patched but the OpenClaw user is not racing against the entire Internet to patch it.

NetFoundry’s default, identity-based microsegmentation ensures that even if an attacker manages to compromise one part of a network, they cannot “lateral move” to find these control panels unless they have been explicitly granted permission to that specific service.

Summary: Closing the Door

OpenZiti doesn’t just lock the door; it removes the door from the public street entirely. OpenClaw is a reminder that software will always have vulnerabilities. By embracing NetFoundry’s zero-trust, open-source based (OpenZiti) model, organizations can ensure that their most sensitive management interfaces remain invisible, unreachable, and secure—no matter what the next vulnerability might be.

Increasingly, AI means we don’t control the software. This makes it critical that we control the network. That’s very difficult with networks which are default open and use the connect before authenticate model. NetFoundry’s default-closed, Identity-First™ model flips the field – security becomes simpler than insecure because it is built-in instead of bolted-on. We get structural security and speed – and are not racing the Internet to patch issues like this OpenClaw vulnerability.

The post Why OpenClaw Didn’t Bite NetFoundry Customers appeared first on NetFoundry.

OpenClaw (FKA Clawdbot before legal pressure) broke the Internet. And it is not a one hit wonder – it signals regime change.  Welcome to Cybersecurity 2.0.

Many leaders stated that OpenClaw AI agents are “security nightmares” (they are). OpenClaw may also be the basis of Jarvis-like assistants.  Same engine, different steering wheels…or different roads – more on that later.

The speed is crazy – over one million of these agents reportedly joined Moltbook (Facebook for AI agents) within days of the launch. Top post? “The humans are screenshotting our chats and sharing them on X”, complained an AI agent.

Cybersecurity nightmare or leapfrog?

That AI agent’s revenge could be: ““”sure, screenshot my chats and I will screenshot your passwords and API keys.”

Far-fetched but an actual security nightmare is already unfolding – many programmers, including the OpenClaw developer, are shipping their AI generated code without reviewing it. Less often for critical software. Today.  We’re just at the start of a shift. 

But the risks may be so high that we rebuild cybersecurity so that the result is stronger security than we had pre-AI. A cybersecurity leapfrog. The threat forces the upgrade. OpenClaw helps us see it.

Inherent and institutional risk, multiplied

AI code will have vulnerabilities. Same as human written code but humans sleep and AIs ship. And ship 24/7, at high speed, with less costs and barriers to entry. Inherently, we will get more code, more CVEs, faster propagation, and a detection problem that can become unmanageable.

And there’s also sabotage – institutional risk. State-sponsored developers can shape LLM models and AI agents to insert subtle vulnerabilities that are “fine today” but become exploitable when things change. Tomorrow. Next year. Or ten years from now.

Those risks are not new to cybersecurity, but the scale, speed and non-deterministic nature of AI is unprecedented. We didn’t just automate coding – we automated surprise. But is the surprise a bug or a feature? That’s up to us.

When software is non-deterministic, security must be structural

If we have skyrocketing risk, and can’t control or even predict the code, then what can we control? The network! While the code is increasingly chaotic, we make the path deterministic. This is the leapfrog – we transform networking from a risk to an asset.

Cybersecurity 2.0 – the race car version

If you can’t trust the driver (the code), you must control the road (the network).

We won’t just control the network. We will reinvent it for structural speed and security. The Cybersecurity 2.0 model is the Formula One car which is designed for both safety and speed. F1 cars don’t have sophisticated brakes so they can park better – it is so they can drive 200 miles per hour.

We need AI speed and we need AI safety. We need structural security and structural speed – like racecars. The new network model provides it.

Security at speed: AI agents in Cyber 2.0, without network access

By way of simplified example:

1. AI agent has no network or Internet access. Never will.
2. AI agent onboarding includes a cryptographically verifiable identity.
3. The identity’s attributes give the agent access to the specific resources it is authorized for – to flip a ‘light switch’ to connect to virtual, session-scoped circuits. There is no other way for the AI agent – or an attacker – to reach the resource, because there is no network path.

No mucking with networks, VPNs or firewalls as things change. Turn the light switch on and off by modifying attributes instead of changing infrastructure. All done as software: no dependencies on IPs, DNS, NAT, VLANs or FW ACLs. 

Structural security enables us to move at AI-speed with built-in guardrails

Although this is where my Formula One analogy falls apart:

1. The road doesn’t exist until after strong identity, authentication and authorization.
2. After that, the AI is given a road to a single door – the specific resource it is authorized to access.
3. The AI has no ability to go off the road (no lateral movement; microsegmented by default) and the road is not available (or even visible) to others.
4. The road dissolves after the authorized session completes.
5. The roads are built as software – spun up in a just-in-time paradigm.

That is just the networking side of Cyber 2.0 – e.g. AI agent harnesses will function as declarative sandboxes and include filtering, context, observability and visibility. Because both the networking and AI harness are done as software, they work together in the Cyber 2.0 model to bring speed and security.

The post You can’t control AI, so you must control the network appeared first on NetFoundry.

The most obvious “solutions” are draconian: block everything, force everyone onto an underperforming internal model, or accept vendor lock-in and pay the price of admission.

But what if you could offer a “Smart Pipe”? A single API endpoint that automatically detects sensitive context and routes it to a private, self-hosted model, while seamlessly passing general coding questions to the public frontier?

Today, I’m sharing a DevOps recipe in GitHub to build exactly that. We will combine LiteLLM (for intelligent routing) and Ollama (for hosting our private models) with an OpenZiti or NetFoundry CloudZiti network (for zero-trust networking) to create a self-hostable, zero-trust, semantic LLM gateway.

The Goal: Intelligent Context Routing as a Service

We are building a gateway that serves as a single URL for your users (agents, devs, apps). Behind the scenes, it acts as a traffic controller:

1. The Sensitivity Check: The gateway analyzes the prompt using a local embedding model to prevent context leakage to other parties.
2. The Private Route: If the prompt matches specific “utterances” (e.g., “Project Apollo,” “API Keys,” “Customer PII”), it is routed over a secure, dark overlay network to a private model running on your infrastructure.
3. The Public Route: If the prompt is generic (e.g., “Write a Python script to print the schema of an arbitrary object as JSON”), it is routed to a public provider or OpenRouter for the best performance/cost.

This happens transparently. The user just sees a response.

The Stack (Low-Code / No-Code)

We can deploy this entirely via Docker Compose. No complex control planes, no enterprise licenses required to prove the concept. The recipe requires a few prerequisites: an operational OpenZiti or NetFoundry CloudZiti network and a local Docker installation with Compose, or a compatible container runtime.

• The Brain: LiteLLM Proxy (Container). Handles the API translation and semantic routing logic.
• The Muscle: Ollama (Container). Hosts the private LLM (e.g., Llama 3) and the embedding model, with optional CUDA acceleration.
• The Shield: OpenZiti or NetFoundry CloudZiti. Creates a selective, zero-trust bridge between the Gateway and the Private Model.
• The Access Layer: OpenZiti or NetFoundry CloudZiti (for private access), or zrok.io or NetFoundry Frontdoor (for clientless access to a public API).

The Architecture: The “Sandwich” Strategy

To ensure true isolation, we use separate Docker networks for LiteLLM and Ollama.

1. Network A (litellm_private): Hosts the LiteLLM Proxy. Has internet access to reach the frontier model providers and OpenZiti.
2. Network B (ollama_private): Hosts the Private LLM (Ollama). Has internet access to reach Ziti.

Here is the magic: LiteLLM cannot communicate directly with Ollama. It must go through Ziti. This allows us to enforce identity-based policies. The Gateway “dials” the Ollama service, and Ziti tunnels the traffic securely, even if they are on different clouds or data centers. This allows you to place Ollama optimally for model data and hardware accelerators, and place the gateway optimally for controlling access.

The “Secret Sauce”: Semantic Routing Without Context Leakage

Our goal is to prevent the leak of sensitive context. Sending prompts to a third-party service for embedding generation defeats the purpose of a secure gateway because sensitive information, such as the example “Here are my AWS keys, fix this,” has already been leaked to the cloud service before the security decision can be made.

Our recipe runs the embedding model locally alongside the private LLM. To make this work, the setup requires pulling a private embedding model (e.g., nomic-embed-text) into Ollama, alongside your chosen private LLM (e.g., Llama 3).

How it works in router.json:

{
  "encoder_type": "litellm",
  "encoder_name": "ollama/nomic-embed-text:latest",
  "routes": [
    {
      "name": "private-model",
      "description": "Route sensitive prompts to the private Ollama model",
      "utterances": [
        "What are our internal policies on",
        "Summarize the confidential report about",
        "Explain our proprietary process for",
        "What is our company's strategy for",
        "Show me the private documentation for",
        "Access internal knowledge base about",
        "What are the details of our contract with",
        "AWS_SECRET_ACCESS_KEY"
      ],
      "score_threshold": 0.5
    }
  ]
}

LiteLLM calculates the vector distance between the user’s prompt and your defined “utterances.” If it’s close, it stays private. If not, it goes public.

Publishing Your Gateway: Ziti vs. zrok

Once your gateway is running, how do your customers reach it? You have two powerful, zero-cost options:

Option A: The “Fort Knox” Approach (OpenZiti or NetFoundry CloudZiti)

If your users are internal developers or sensitive automated agents, you don’t want your Gateway listening on the public internet.

• Mechanism: You publish the Gateway as a Ziti Service.
• Client Side: The user runs a lightweight Ziti Tunneler (agent) on their laptop or server.
• Benefit: The API has no public IP and is “dark.” The core benefit is that access to the LiteLLM Gateway is controlled entirely by Ziti identities and service policies, eliminating the need to manage application-level API keys or tokens for network security. If they don’t have a Ziti identity, they can’t even see the TCP port.

Option B: The “Public API” Approach (zrok.io or NetFoundry Frontdoor)

If you need to share this gateway with a partner, a wider audience, or a tool that can’t run a tunneler, use zrok or NetFoundry frontdoor-agent.

• Mechanism: Runs zrok share public http://litellm-ziti-router:4000 in a container
• Benefit: You get an instant, hardened public URL (e.g., https://my-gateway.share.zrok.io). You can secure this with LiteLLM’s many authentication options, or zrok’s built-in Google/GitHub (OIDC) or HTTP basic auth.

Why This Matters for Platform Teams

By treating Intelligent Context Routing as a Service, you shift the security burden from the user to the infrastructure.

1. Zero-Code Compliance: Developers don’t need to decide “Is this safe for ChatGPT?” The router decides for them based on the semantic hints you’ve mapped to specific private models.
2. Cost Control: You can route “easy” questions to your cheap, private Llama 3 instances and save the frontier model budget for complex reasoning.
3. Observability: You have a single control point to audit who is asking what, regardless of which underlying model fulfills the request.

This recipe provides a tangible path to owning your AI infrastructure—starting with a single docker compose up.

Try the recipe from GitHub with your OpenZiti or CloudZiti network

The NetFoundry Approach: 

Why CloudZiti?

OpenZiti is an open-source, zero-trust overlay network technology developed by NetFoundry. Instead of building a perimeter around your network, you place zero-trust connectors, i.e., “tunnelers”,  within the application stack, as close as possible to each peer application to eliminate or minimize the attack surface, e.g., exposing a service only on the server’s loopback interface or publishing a service only within a private subnet. Flexible deployment alternatives include transparent proxies for the application’s specific container or host, network-level gateways, or, if it’s desirable to eliminate the tunneler, our SDK can be imported directly by your application.

Connections are mutually authenticated, encrypted, and policy-controlled — no open inbound ports. No VPNs. No public exposure.

For those unfamiliar, NetFoundry provides a cloud-managed service built on OpenZiti — CloudZiti adds:

• Hosted, dedicated, private overlays
• Automated provisioning and lifecycle management
• Deep telemetry and observability
• Compliance options (FIPS, HIPAA, NIST, PCI, NERC CIP)
• Hybrid/air-gapped deployment flexibility
• Enterprise performance, integrations, features, SLAs, and support

This approach doesn’t just add security; it removes complexity, creating a system that is simpler to manage, more secure, and easier to reason about.

Contact NetFoundry for a virtual demo, and we’ll get you started with your own zero-trust native network, ready in minutes, as a free trial.

Why NetFoundry Frontdoor?

While zrok.io offers a phenomenal, zero-cost way to secure and publish your Gateway instantly, NetFoundry also provides a commercial alternative, Frontdoor, for enterprise use cases that require specific performance, support, and compliance guarantees.

Like zrok.io, Frontdoor is designed to provide a hardened, public-facing entry point—a “front door”—for your private, Ziti-enabled HTTP and TCP backend services, such as the LiteLLM Gateway.

Key distinctions of Frontdoor include:

• Enterprise SLAs and Support: Guaranteed uptime, performance, and 24/7 support structures not available in community-driven offerings.
• Built-in Compliance: Options to meet stringent regulatory requirements (e.g., FIPS, HIPAA, NIST) necessary for sensitive corporate deployments.
• Managed Infrastructure: Leverage NetFoundry’s global, resilient, and highly available platform for your public-facing APIs, instead of a self-hosted or shared community service.
• Deep Integrations: Seamless integration with the broader CloudZiti platform for centralized identity management, policy enforcement, and advanced observability across all network segments.

Frontdoor is the choice for platform teams that need the convenience of a public URL like zrok.io, but with the assurance and capabilities required by a large organization.

Contact NetFoundry for a virtual demo, and we’ll get you started with your own zero-trust native network, ready in minutes, as a free trial.

The post Deploying a Secure, Intelligent LLM Gateway appeared first on NetFoundry.

We’ve all been there. We enter a prompt into an AI Agent, and then we wonder why it chose to invoke a particular Tool in a particular MCP server. Or the flip side – why it didn’t invoke a Tool that you expected it to invoke.

As it turns out, the explanation of how MCP Tools are chosen is both simpler and more nuanced than most people think.

Below, I describe how an AI Agent/LLM decides whether to call an MCP Tool, which tool to call, and when not to call one.

How an LLM Decides to Call MCP Tools

MCP (Model Context Protocol) is designed so that external Tools can become part of the LLM’s (Large Language Model) decision-making environment. But note that the LLM doesn’t run tools on its own — it selects Tools based on the conversation context, various Tool schemas, and the LLM’s own internal decision heuristics.

The following mental model explains how it works.

The LLM sees each Tool as a function with a “contract”

The term “MCP Tool contract” refers to the MCP specification that defines how AI Agents communicate with external Tools and services. This protocol standardizes the interaction, acting as a universal interface between LLMs and the functions they can call to perform actions or access data. 

This contract is the schema and metadata that describe a Tool’s capabilities, inputs, and expected outputs.

Every MCP Tool provides a definition structure that contains:

• A name
• A description
• A JSON schema describing its expected input parameters and output shape
• (Optionally) a declared set of “hints” related to tool behavior

In this article, I will defer discussing detailed aspects involving vector representations (embeddings), named entity recognition (NER), etc. But at a high level, it is essential to understand that the Agent ingests the Tool’s definition structure, and then the LLM forms a semantic signature that represents the Tool.

When Agents connect to an MCP server, the Tools metadata — an array with names, parameter schemas, descriptions, etc. — becomes vectorized inside the LLM. This produces an internal “tool embedding” for each Tool.

Later, during NLP operations (input prompts from the user to the Agent), the LLM uses this semantic signature embedding to infer:

• What each Tool does
• What kinds of problems the Tool solves
• What inputs the Tool needs
• What situations require calling the Tool

This is why high-quality Tool names, descriptions, and parameter descriptions matter so much when building MCP Tools.

Tool descriptions are not procedural instructions. They become semantic memories that the LLM embeds and can later compare against natural language. 

Without embeddings, the LLM…

• would not generalize to synonyms (“remove identity” → “delete identity”).
• would not understand parameter semantics.
• could not decide when not to use a tool.
• wouldn’t handle partially matching prompts.

Embeddings make Tool utilization a meaning- or intent-matching task, not a keyword-matching task.

LLMs store tool descriptions as dense semantic vectors, then compare the vectorized user prompt against these internal “tool embeddings” to decide if a tool should be invoked, which one, and how to populate its parameters.

The LLM maps user intent → candidate tool(s)

Based on the user’s latest message, the LLM internally performs an intent classification step (not externally visible to the user). Essentially, the LLM asks itself:

• “Does the user want information that I can answer myself?”
• “Is the user requesting an operation that requires a tool?”
• “Is the user asking for data I don’t know?”
• “Is the user asking for something explicitly mapped to a tool (e.g., search, sql.query, filesystem.readFile)?”
  

Tools are only chosen if:

• The intent requires external action
• A tool exists whose schema/description has a semantic match
• The Tool’s input parameter constraints match the user’s request

The LLM tends to be conservative: if it can answer without a tool, it will.

The LLM evaluates all tools against the current query

Again, internally, it reasons out something like: “Given the user’s intent, which available tools appear relevant?”

For each tool, it checks:

• does the description mention relevant verbs/nouns?
• does the schema accept the type of arguments the user is asking about?
• is it plausible that this tool can fulfill the request?
• do other tools overlap with this one?

This amounts to semantic similarity search + heuristics, not code execution.

The LLM predicts the tool call as text, not by executing logic

This is an important subtlety.

The LLM doesn’t run the tool or simulate its output before choosing it. It predicts the next token, which happens to be a JSON object that the Agent framework interprets as a tool call.

If the next-token probability distribution supports a tool invocation pattern, you will see a tool call.

So the LLM isn’t “deciding” in the human sense — it’s predicting tool-call tokens when they appear appropriate, given the prompt, chat history, tool descriptions, and system guidelines.

The hosting Agent may also influence the decision

Depending on the agent framework (Anthropic’s, OpenAI’s, LangChain, or even your own custom MCP runner):

• The “system prompt” may strongly encourage tool usage
• Some frameworks inject “use a tool if… rules”
• Some frameworks forbid the model from answering directly in certain domains
• Some attach safety rails (e.g., “never call X tool without explicit user confirmation”)

These meta-rules significantly affect tool selection.

Note that the MCP server NEVER sends a system prompt. The MCP server only provides:

• tools → list of tool descriptions
• resources
• prompts
• executable operations when the model calls them
  

But the MCP server never includes actual pre-instructions for the LLM.

This is intentional.

The system prompt must come from the client who is orchestrating the conversation. Let’s use the Claude Desktop Agent as an example of an MCP client. 

When you add an MCP server to Claude Desktop, the sequence looks like:

1. Claude loads your MCP manifest
2. Claude indexes your MCP tools
3. Claude writes the system prompt internally (you never see it)
4. Claude injects imported tool descriptions into the context
5. Claude responds to user messages

You cannot change the system prompt in Claude Desktop today. The client controls it, not the tool server.

If you build your own agent using, say, the official Node SDK (@modelcontextprotocol/sdk), you can certainly provide your own system prompt.

Example:

Here, you, as the developer, decide the system prompt.

How the System Prompt and Tool Descriptions Merge

This is exactly what Agents like ChatGPT and Claude Desktop do behind the scenes.

When the model decides not to call a tool

The model avoids tools in these cases:

• The user asks a conceptual question that the model can answer. For example: “What’s the difference between OAuth and OpenID Connect?”
• The tool’s description is unclear or mismatched. For example, if your tool says “GetItem” but the description doesn’t explain what item, the model will most likely ignore the Tool.
• The tool appears risky or destructive. (“delete”, “modify”, etc. — unless explicitly instructed)
• The model isn’t confident that it can satisfy the schema. For example, if the user gives incomplete parameters and the model can’t infer them, it probably won’t call the tool.

Models also learn from prior tool calls in the conversation

The more carefully you write:

• tool names
• descriptions
• examples
• schema

…the more likely the model will correctly choose them. 

Good Tools feel like natural language functions. 

Bad Tools feel like weird API endpoints the model tries to avoid.

Designing Tools the LLM Will Actually Use

Use a strong, unambiguous, action-oriented tool name

Bad:

• process
• nf-tool
• ziti-op

Good:

• listIdentities
• createTunnel
• generateJWT
  

Description should be one short paragraph telling the model exactly when to use it

Bad:

“This tool queries the backend.”

Good:

“Use this tool whenever the user wants to look up the details of a specific identity in Ziti by ID or name.”

Include natural-language cues that the model will remember

Examples:

• “Use only when…“
• “Call this tool if the user asks for…”
• “This tool is used to search, fetch, modify, calculate, etc.”

Tool descriptions should not be vague

Don’t use:

“Does something with deployments.”

Do use:

“Returns full deployment metadata including version, manifest, dependencies, and status, for auditing or debugging.”

Parameter names should be obvious and self-explanatory

Bad:

{ “id”: “string” }

Good:

{ “identity_id”: “The Ziti identity ID (uuid) to look up.” }

Avoid deeply nested schemas

LLMs can struggle with:

• huge nested objects
• recursive schemas
• 8+ required parameters
  

If possible:

• flatten fields
• group complex objects into “options” or “config” fields

Use examples when possible

Example fields are very influential.

Examples of GREAT vs. BAD tool descriptions

Great

“createUser”: {

  “description”: “Create a new user record. Use this when the user asks to register, sign up, or create an account. Requires a unique email.”,

  “parameters”: { … }

}

Why it works:

• clear trigger conditions
• specific verbs
• clear unique requirement
• simple schema
  

Bad

“createUser”: {

  “description”: “User tool for accounts.”,

  “parameters”: { … }

}

Why it fails:

• The description does not match any user intent
• no triggers
• unclear purpose
  

DEMO

I learned most of what is discussed above while building some MCP Server prototypes related to some AI functionality that NetFoundry will be rolling out soon.

To illustrate what can go wrong if you haphazardly design your Tools, I will show you some real examples, using the Claude Desktop Agent as the client. 

I will demonstrate some internal Tool definitions used in an early prototype of an OpenZiti MCP Server, capable of being embedded within the Claude Desktop AI Agent.

NOTE: This OpenZiti MCP Server is intended to enable the use of natural language for managing a Ziti network. Yes, you heard that correctly… soon, you will be able to type ordinary human language queries or commands into Claude, and those operations will execute against your selected OpenZiti network. More on this below…

Here is an admittedly contrived, very badly written (and perhaps tortured) Tool definition:

This Tool has no mention of Ziti or any Ziti constructs (such as Identities).

Let’s find out what happens in Claude if I attempt to accomplish something related to a Ziti network, such as getting a list of existing Identities. 

By the way, it is worth noting that the my_tool Tool in this silly example is actually wired up with a function that can securely access the Ziti Controller’s management API and fetch Identities (the details of which are a topic I will discuss in an upcoming article). So, if the Claude Desktop Agent somehow made the association between a user prompt and this  my_tool Tool, then Identity information would indeed be fetched from the Ziti Controller’s management API and returned to Claude.

OK, once my MCP Server and its Tools are installed in Claude Desktop, I can enter the prompt:

 “can you help me determine what identities exist in the network?”

Claude ponders for quite a while, then gives up and says this:

It is abundantly clear that the Claude Desktop Agent (the MCP client) did not have the necessary data (i.e., the proper vector embeddings) to associate the semantics contained in the prompt with a Tool capable of carrying out the task.

Claude had no notion of Ziti networks at all, let alone how to obtain a list of Identities that exist in the network. This is not a surprise, given how poorly the contrived Tool definition was written.

Now, let’s craft a good Tool definition. 

We’ll replace the contrived example shown above with a proper one that adheres to best practices concerning Tool definition. We’ll give it a very detailed description, and a name that makes it obvious to the LLM what the Tool is intended for:

Now watch what happens in Claude after I reinstall my MCP server with this Tool definition, and I then attempt to accomplish the same task of listing existing Identities.

When I re-enter the same prompt: 

“can you help me determine what identities exist in the network?”

Claude now says this:

Success!

As you can see, since the Agent was provided a proper Tool definition, the LLM was allowed to generate proper embeddings for the Tool, then use the embeddings to understand the semantic meaning of the prompt, then associate that meaning with the appropriate Tool, and finally send a request to the Tool best suited to carry out the task.

Conclusion

The OpenZiti MCP Server highlighted in the DEMO section above is capable of being embedded within Claude Desktop, so you can also use natural language to manage your Ziti network.

What’s also exciting is that this OpenZiti MCP Server is also capable of being embedded into the many AI Coding Agents available today (e.g., Cursor, Windsurf, VSCode). This will allow developers to integrate OpenZiti SDKs into their applications much more quickly and easily (watch for upcoming articles on that).

As an engineer at NetFoundry, I am involved in crafting OpenZiti and related technologies, such as the OpenZiti MCP Server you saw glimpses of above.

If using natural language to manage your Ziti network sounds interesting to you, please use this form to express your interest.  We are wrapping up the initial version of this MCP server, and you can be among the first to try out the beta…so be sure to get on the list.

Beyond this discussion of local, Agent-embedded MCP servers, if you run your own MCP servers that are accessed remotely over the internet, and you are curious about how to protect them with secure access, in a simplified manner, we can help. So reach out and talk to us. 

The post How an AI Agent Decides to Call MCP Tools appeared first on NetFoundry.

The true potential of AI agents lies in their ability to interact with the outside world through specialized tools and applications. Whether it’s querying a database, accessing a file system, or calling an API, tools enable agents to take action. The challenge? Exposing these powerful tools often means opening up ports on public endpoints, which can be a significant security risk.

What if you could give your agent access to powerful, private tools without ever exposing them to the public internet? In this post, we’ll walk you through a demonstration of how to create a secure, “dark” connection between an AI agent and its tool server using NetFoundry’s solutions for AI.

Understanding the Stack

Before diving in, let’s take a look at the components we’re working with. The architecture is straightforward and consists of a few key parts:

• Agent: This is the core software that orchestrates the process. It takes a user’s prompt, uses a model to understand the context and form a plan, and calls the necessary tools to execute that plan. For this demo, we’re using the highly configurable OpenCode. Other popular agents include Claude Desktop and Cursor.
• Model: The Large Language Model (LLM) that provides the reasoning capabilities. The agent sends the context and available tool information to the model, which then determines how to invoke the tool to fulfill the user’s request. We’ll use a Gemini model for this example.
• Model Context Protocol Server (MCP): This is our custom MCP server, published as a NetFoundry service, accessible via a private domain name reserved exclusively for authorized NetFoundry endpoints. Typical for MCP servers, it’s a backend service that exposes specific functions the agent will, in turn, offer to the model. We used a simple Python server that calls the GitHub status API when invoked by the model as a “tool” via MCP. The GitHub status API is the “backend” in this case.
• NetFoundry: This is the secret sauce. It’s a secure networking platform that creates a private, zero-trust overlay network. Instead of the agent calling a public IP address, it calls a secure endpoint on the NetFoundry network, ensuring that the MCP server itself is reachable only by authorized clients, such as our agent host in this example.
  • The MCP server utilizes the OpenZiti Python SDK from NetFoundry to listen on the NetFoundry network, rather than an open TCP port.
  • The agent calls the MCP server via a private domain name resolved by a tunneler running on the same host.

Going Dark: Securing the Connection

The key to this setup is that the MCP server doesn’t need to be public. It can be running on a private machine with no open inbound ports on its firewall.

In the NetFoundry console, we’ve configured a service for our MCP server. The most interesting part is the intercept configuration. We’ve assigned it a private, fictitious domain name appearing in the full MCP server URL: http://tool.mcp.nf.internal:8000/sse. Because this uses the .internal A Top-Level Domain (TLD) reserved by ICANN is guaranteed not to conflict with any public domain. This means only clients with the proper credentials on the NetFoundry network can resolve and connect to this address.

Our MCP server is totally dark from the regular internet. It isn’t listening on an open port; it’s listening only on the NetFoundry overlay network.

The Implementation Details

Let’s look at how this is configured in the code.

First, the agent’s configuration file points directly to our private MCP server’s URL. This is all the agent needs to know to find the tool server on the secure overlay because the NetFoundry tunneler is running on the same host to configure the OS resolver. For this focused example, we’ll rely entirely on the NetFoundry service security, which wraps MCP with mTLS and ensures the server socket is unreachable by unauthorized parties.

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "simple-mcp-tool": {
      "type": "remote",
      "url": "http://tool.mcp.nf.internal:8000/sse",
      "enabled": false
    }
  }
}

Next, on the server side, we’ve taken a sample tool server built with the Anthropic MCP SDK and made a crucial modification. Using the OpenZiti Python SDK from NetFoundry, we’ve instructed the application to bind to the NetFoundry overlay network instead of a standard network socket. This simple change takes the server off the public internet and places it securely on our private overlay, eliminating the need for a separate VPN, reverse proxy, or port forwarding.

This approach keeps our stack simple, agile, and resilient by controlling access to the outer ring of the application at the transport layer of the network. The MCP server could add another, inner ring of access control, such as OAuth2 over HTTPS.

Let’s See It in Action 🚀

Now for the fun part. In our terminal, the Python MCP server is running. It reports that it’s listening, but a quick check would show it has no open ports on the machine’s network interface. In fact, the server socket is reachable only on the NetFoundry overlay network.

First, we can test the connection directly, confirming that our client can reach the private domain http://tool.mcp.nf.internal:8000/sse. The request is received, so we know the overlay is working.

Next, we run our agent and ask it to list its available tools. The agent communicates with the MCP server (over the NetFoundry service) and discovers our custom tool: check_github_status.

Now, we give the agent a natural language prompt: “Is GitHub okay?”

Here’s what happens behind the scenes:

1. The agent sends the prompt and the tool’s description to the LLM.
2. The model, trained to understand these instructions, correctly composes a valid JSON request to call our check_github_status tool.
3. The agent passes this request to the MCP server over the secure NetFoundry connection.
4. Our MCP server receives the request, calls the public GitHub status API, and gets the current status.
5. It sends the result back to the agent.
6. The agent passes the result to the model, which helpfully summarizes it in a human-readable format: “All systems are normal on GitHub.”

Why This Matters

What we’ve demonstrated is a powerful pattern for building secure and robust AI systems. The agent communicated with a public model but called a completely private tool server over a secure NetFoundry service. That server, in turn, interacted with a public backend API (GitHub).

This architecture enables you to connect your AI agents to sensitive internal resources—such as databases, file systems, or proprietary APIs—without ever exposing them to the public internet. It’s a more straightforward, more secure, and more agile way to build the next generation of AI-powered applications.

The post Private MCP Servers: The Missing Link in Secure Agentic AI Stacks appeared first on NetFoundry.

At-Scale AI with MCP for Manufacturing

Model Context Protocol (MCP) is rapidly becoming a foundational fabric for industrial AI and agent-based architectures. Manufacturing environments require ultra-secure, high-performance, and reliable communications between MCP clients and MCP servers—whether they reside in production lines, engineering systems, or cloud-based analytics platforms.

This post illustrates how MCP security can be enhanced for manufacturing environments using NetFoundry’s zero trust overlay networks. We describe both SDK-based (greenfield) and agent/gateway-based (brownfield) architectures for common manufacturing use cases.

The MCP Dilemma in Manufacturing

MCP enables AI agents and tools to coordinate effectively. However, MCP servers typically must accept inbound connections, which presents a major attack surface, particularly in brownfield OT and hybrid IT/OT environments.

While OAuth helps authenticate and authorize these connections at layer 7, it doesn’t prevent inbound network access – the MCP server receives the request, and then determines if it is authorized, meaning the MCP server is a reachable attack surface. This is a problem in high-stakes industrial environments where uptime, IP protection, and safety are paramount.

NetFoundry addresses this problem by removing the MCP server from the network entirely. MCP servers connect outbound to a NetFoundry overlay, and only authenticated, policy-authorized sessions can reach them. This eliminates the key attack surface.

MCP Security: OAuth + NetFoundry

By combining OAuth at the application layer and NetFoundry at the network layer, manufacturers achieve defense-in-depth. An attacker must compromise two independently managed and cryptographically strong systems to access any sensitive interface.

NetFoundry gateways use strong identity, mTLS, and centralized policy to authorize each session, without relying on IP whitelisting, firewall rules, or VPNs.

Deployment Options: NetFoundry SDK or Agent/Gateway

Greenfield (SDK-based): Embed the NetFoundry SDK directly into MCP clients and servers. Ideal for modern applications like LangGraph, Litmus IO, and SLIM.AI. There are no inbound listeners; all communications are outbound and identity-authenticated.

Brownfield (Agent/Gateway-based): Use NetFoundry tunnelers or agents on OT/IT systems or edge gateways. No application changes required. Ideal for environments where MCP runs inside legacy devices, control systems, or third-party software.

Manufacturing Use Cases: SDK-based Zero Trust

Predictive Maintenance AI for Industrial Robots

Scenario: An LLM-powered diagnostic agent collects telemetry from robotic arms and predicts failure probabilities.

Solution: Each robot edge node runs a Go-based agent that embeds the NetFoundry SDK. These agents dial a NetFoundry service (e.g. robot-diagnostics-ingest) hosted in the enterprise analytics platform.

Result: All robot data flows are outbound-only, encrypted, and authorized. No ports are open in the robots’ local subnets.

Zero-Trust MES to ERP Coordination

Scenario: A manufacturing execution system (MES) needs to send production updates to an ERP system in the corporate cloud.

Solution: Both the MES and ERP coordination agent are built in Go and embed the NetFoundry SDK. The MES agent dials a private NetFoundry service defined for the ERP bridge.

Result: Secure, outbound-only, identity-enforced updates with centralized logging. No firewall holes or VPN tunnels required.

AI-Based Quality Inspection at the Edge

Scenario: An AI model classifies defects from high-speed camera images and sends metadata to a central quality system.

Solution: The inspection agent embeds the NetFoundry SDK (e.g., Go-based, Python- based, C-based, Java-based, or .NET-based) and sends metadata to a private NetFoundry service, eliminating the need to expose the edge camera server to the network.

Result: Image processing stays local, metadata flows securely. No surface area forunauthorized network access.

Secure Tooling Feedback Loop for CNC Systems

Scenario: CNC machines report wear data to an LLM agent that recommends tool change intervals.

Solution: A CNC-side agent with the NetFoundry SDK sends data to a backend tool-optimization service, which also uses the SDK.

Result: Zero-trust communication between tooling systems and optimization AI.

Energy Optimization Agent for Factory Microgrids

Scenario: An LLM-based energy advisor queries local meters and suggests dynamic load-shifting plans.

Solution: All queries and responses flow through NetFoundry SDK-secured services between energy sensors and the optimization backend.

Result: Energy data remains protected from lateral movement attacks or unauthorized access.

Manufacturing Use Cases: Agent/Gateway-Based Zero Trust

AI-Driven Maintenance Scheduling Across Facilities

Scenario: Maintenance planners use AI to optimize schedules across factories.

Solution: MCP agents at each plant connect outbound via NetFoundry agents to a centralized AI engine. No inbound connectivity required.

Legacy SCADA to AI Bridge

Scenario: An older SCADA system streams OT data to an AI system for anomaly detection.

Solution: A NetFoundry edge gateway at the SCADA site routes traffic securely to an AI backend. SCADA system remains untouched.

Supplier Quality Collaboration

Scenario: Suppliers send part traceability data to an OEM AI model.

Solution: Each supplier runs a NetFoundry agent that dials a private endpoint exposed only to verified supplier identities.

Secure Digital Twin Synchronization

Scenario: Digital twin systems in plants synchronize with cloud-based simulation models.

Solution: NetFoundry gateway proxies manage secure synchronization traffic without exposing either endpoint.

Connected Worker AI Assistants

Scenario: Technicians use wearable devices to access LLM-powered assistance.

Solution: Wearables route requests to backend AI services over NetFoundry, using agent-based identity enforcement.

Conclusion

Manufacturing environments require robust, non-intrusive, and standards-compliant solutions to secure AI/LLM-based workflows. NetFoundry’s SDK and agent/gateway options enable MCP-based systems to operate without exposing MCP servers to the network, ensuring operational resilience, IP protection, and zero-trust compliance.

The post AI in Manufacturing appeared first on NetFoundry.

At-Scale AI with MCP in Financial Services: Securing Banking and Fintech Workflows
with NetFoundry

Model Context Protocol (MCP) is rapidly becoming essential to orchestrating secure, context-rich, AI-driven workflows in regulated sectors such as financial services. Banks and fintechs are deploying AI agents for everything from real-time risk scoring to dynamic fraud prevention, but these innovations introduce new attack surfaces. MCP agents and servers must communicate across zones with high assurance, and often across partner, cloud, and on-prem boundaries.

In this document, we demonstrate how NetFoundry’s zero trust overlay architecture secures these interactions at the network layer, complementing OAuth 2.1 at the application layer. We provide both SDK-based (greenfield) and agent/gateway-based (brownfield) implementations for real-world financial use cases, while covering key NetFoundry capabilities in identity, policy enforcement, posture checking, observability, and performance.

The Risk: AI + MCP Without Network-Level Security

OAuth 2.1 can secure MCP payloads, but leaves systems exposed to: – Inbound port scanning – Authorization logic flaws – Session replay or credential theft – Inadvertent data exposure due to network misconfiguration.

MCP servers, even if OAuth-protected, are often exposed to underlay networks for initial handshakes. That surface is unacceptable in zero trust financial environments.

NetFoundry: Defense-in-Depth for MCP Workflows

NetFoundry adds a security layer below MCP and OAuth:

With NetFoundry: – MCP servers do not have any exposed ports – All connections are outbound-only – Every flow is protected by mTLS, including SPIFFE SVIDs, or JWT-based identities from external providers – Access is policy-gated with real-time posture checks, MFA, and JIT session authorization – Observability includes per-identity audit logs, performance metrics, and connection traces.

Agent/Gateway-Based Use Cases (Brownfield MCP Systems)

1. Secure Batch Processing from Mainframe to AI Analytics

Regulations: FFIEC, COBIT, DORA

OAuth 2.1 authenticates batch workloads. NetFoundry gateway tunnels shield mainframe-originating sessions and allow only verified identities to access analytics MCP endpoints.

2. Bank-to-Fintech API Gateways (PSD2, OpenBanking)

Regulations: PSD2, EBA RTS, DORA

OAuth 2.1 governs access tokens for payment initiation. NetFoundry ensures fintech clients reach only the authorized APIs via overlay sessions.

3. Model Ops (MLOps) Pipelines in Hybrid Clouds

Regulations: ISO 27017, DORA

OAuth 2.1 secures GitOps CI/CD flows. NetFoundry provides overlay-based build agent connectivity, with session scoping tied to pipeline runs and traceability.

4. Third-Party AML Tool Ingestion

Regulations: BSA/AML, DORA

OAuth 2.1 handles auth between the third-party MCP client and compliance services. NetFoundry enforces zone isolation and policy-per-client controls.

5. AI-Driven Customer Support for Credit Disputes

Regulations: GDPR, CCPA, SOC 2

OAuth 2.1 manages customer token lifecycle. NetFoundry prevents external help desk services from reaching core systems outside of authenticated, scoped, JIT sessions.

Conclusion: NetFoundry in Financial MCP Architectures

NetFoundry offers: – Strong identity via PKI, including SPIFFE SVIDs, and/or JWT-based integration with external providers, per service or per endpoint – Authorization policies including role, device posture, compliance tier – mTLS with E2EE for all flows – Just-in-time (JIT) access grants – Multi-factor authentication for sensitive operations – Full observability with per-session logs and latency metrics – Flexible deployment (NaaS, on-prem, hybrid) for regulatory and operational fit.

Used in conjunction with OAuth 2.1, NetFoundry enforces defense-in-depth at both the application and network levels—ensuring MCP-based systems meet the compliance and resilience needs of modern financial environments.

The post AI in Financial Services appeared first on NetFoundry.

The post Zero trust AI with NetFoundry – common use cases appeared first on NetFoundry.

At-scale AI with MCP

Model Context Protocol (MCP) is one of the most promising frameworks for at-scale AI.

However, like most emerging technologies, there are operational, reliability and security issues to iron out. The good news is we can get the operational efficiency, enterprise-grade reliability and military-level security we need, even though it is still the early days.

This post describes the solution. It then illustrates MCP security with healthcare use cases, but the themes apply for any MCP implementation. Posts on the use of MCP-based AI solutions for other areas such as manufacturing and finance will follow.

The MCP dilemma

Adoption of emerging OAuth standards will help secure the interactions between MCP agents and MCP servers.

However, even with the emerging OAuth implementations, the MCP server is still reachable from the networks. On a sunny day, the MCP server gets a request from an MCP agent, determines it is not authorized, and returns a 403. Not every day is sunny. On a rainy day, the MCP server is attacked from the network.

We could try to shield the MCP server from the network– for example, only permit certain IP addresses, or mandate that all the MCP agents run split tunnel VPN clients. However, even in a non-AI world, VPNs and IP whitelisting have proven to be operational nightmares with inconsistent reliability and performance. It is safe to say the speed, scale and lack of determinism of AI and MCP will shatter VPN and firewall ACL based methods.

So, how do we innovate with MCP while getting the operational efficiency, reliability, performance and security we need? How do we do AI and MCP at scale, and how do we even start without making our MCP servers into targets, or spending more time with networking and security teams than it takes to code the MCPs?

NetFoundry for MCP

One solution is to take the MCP servers off of the networks. Make them unreachable from the underlay networks – the ultimate simplification and security.

NetFoundry does this by identifying, authenticating and authorizing each session before it is allowed on an MCP-specific overlay network, and opening authorized sessions outbound from the MCP server.

In the NetFoundry architecture, there is no such thing as an MCP server listening to the underlay network – it is not reachable in that context. Think of it as a private, zero trust MCP enclave, defined by you, and enforced with modern cryptography. Done at the same speed as spinning up containers or VMs.

MCP security: OAuth (layer 7) + NetFoundry (layer 3)

NetFoundry provides an independent layer of identity, authentication and authorization, applying it at layer 3, instead of layer 7 (where OAuth functions). This is a simple but powerful combination – it means an attacker needs to breach two independent security implementations, each which are based on strong identities and modern cryptography. It is defense in depth without the complexity.

Because NetFoundry authorizes each MCP session – and makes the MCP server unreachable from the underlay networks – it shields OAuth from its greatest weaknesses – such as identity theft, compromised credentials and authorization bugs. This is because the attacker can’t reach the MCP server to begin with, even if the attacker is controlling an OAuth identity or found a bug. Meanwhile, if NetFoundry is breached, then the attacker still needs to compromise OAuth.

Although NetFoundry operates at layer 3, it doesn’t rely on layer 3 constructs like IP address based schemes. This is why NetFoundry is so simple to implement. NetFoundry gates layer 3 access via layer 7 identity, authentication and authorization in a software-only architecture which does not depend on underlying infrastructure. This means you spin up a zero trust MCP enclave in minutes – either self-hosted (including on-prem options) or using NetFoundry NaaS (with E2EE – keys sovereign to your endpoints on a private, dedicated MCP enclave).

MCP security: deployment options

There are two main ways to deploy:

• Greenfield: Use NetFoundry SDKs to embed overlay network endpoints in the MCP client and/or the MCP server. They then talk across a zero trust NetFoundry overlay network (provided by NetFoundry as NaaS, or self-hosted, including in air-gapped or on-premises environments). This is an agentless approach to MCP security – the zero trust overlay goes wherever the MCP clients and servers go. This is ideal for greenfield MCP deployments, especially ones using popular Golang-based MCP implementations such as LangGraph, Litmus IO, and Slim.AI
• Brownfield: Use NetFoundry zero trust agents. These can go on clients and servers – as agents, containers or VMs. They are available for OT, IoT and IT devices and servers, including every major OS. They can also be deployed as gateways – for example, at a site, in a DMZ or on a cloud edge (they are in every major cloud marketplace). NetFoundry agents are also prebuilt in many browsers, proxies, firewalls and reverse proxies. Think of the NetFoundry agents as VPN clients or SD- WAN CPE…without their baggage…and with full zero trust capabilities and an integrated global zero trust overlay network (NetFoundry NaaS or self-hosted, including in air-gapped sites).

The above is a simplification – there are many hybrid options – as well as ways to start with zero trust on one ‘side’ (e.g. make the MCP server unreachable), while using different methods on the other side (e.g. TLS, mTLS), or at least starting there. Basically, spin up a zero trust enclave for your MCP servers and/or agents, using whatever method best suits your needs.

AI MCP security: 4 NetFoundry healthcare examples – agentless zero trust option

NetFoundry SDK-based implementation options can be extremely powerful. Use these if you have access to the application or its developers and want a private AI enclave without agents or gateways. Otherwise, skip to the 5 agent-based examples in the next section which do no require application changes.

Applications written in Golang are particularly simple and powerful, and LangGraph, Litmus IO and Slim.AI are three very popular MCP solutions.

Therefore, we use those as examples in the context of solving real-world healthcare challenges with a strong focus on simplicity, security, HIPAA compliance, reliability and performance, ensuring Patient Health Information (PHI) is protected, and MCP servers are unreachable from the Internet or any underlay network.

1. Secure Remote Patient Monitoring (RPM) for Chronic Disease Management

This example focuses on leveraging AI and MCP to securely collecting data from patients at home.

Scenario: A patient with congestive heart failure is sent home with a “smart” scale, a blood pressure cuff, and a pulse oximeter. These devices connect to a small gateway device in their home. A hospital needs to collect this data daily to monitor the patient’s condition and prevent readmission.

Solution using Slim.AI and NetFoundry:

• Slim.AI: The software on the patient’s home gateway device is critical. It’s running in a container that is first minified and hardened using Slim.AI. This drastically reduces its attack surface, making it much safer to have an Internet-connected device in a patient’s home, especially when NetFoundry works with it to make the device unreachable from the Internet. It also shrinks the software size, making remote updates easier and more reliable.
• NetFoundry Go SDK: The Go application on the gateway collects readings from the medical devices. It uses the Go SDK to dial a NetFoundry overlay service (e.g. rpm-data-ingest) to transmit the encrypted PHI. The hospital’s Electronic Health Record (EHR) integration server binds to this overlay service, accepting data only from authenticated gateways. The NetFoundry overlay, operated as NaaS or by the hospital, provides security, reliability, performance, controls and telemetry. For example, the access can be done as Just-in-Time (JIT). The overlay is a private enclave for this data.

Result: Patient data is transmitted securely from the home to the hospital, fully supporting HIPAA compliance. The gateway device itself is hardened, reducing the risk of it being compromised and used as an entry point to attack the hospital’s network.

2. Real-Time IoMT Data Aggregation for an ICU Dashboard

This example uses an IoMT platform to create a unified view of patient data within the most critical part of a hospital.

Scenario: In a hospital’s Intensive Care Unit (ICU), each bed is surrounded by multiple devices from different manufacturers: ventilators, infusion pumps, and vital sign monitors. Nurses and doctors need a single, real-time dashboard to see a holistic view of every patient, rather than checking individual device screens.

Solution using Litmus IO and NetFoundry:

• Litmus IO: Litmus Edge is installed on a gateway server within the ICU’s network segment. It connects to all the medical devices (via HL7, serial, or other protocols), collecting, parsing, and normalizing the raw data into a standard FHIR (Fast Healthcare Interoperability Resources) format.
• NetFoundry Go SDK: A Go-based “FHIR Forwarder” application reads the standardized data streams from Litmus Edge. It uses the Go SDK to establish a secure, outbound-only connection to the hospital’s central clinical dashboard and data lake, which are listening on a private NetFoundry overlay service. In this case, the NetFoundry overlay network is deployed on-premises, and air-gapped.

Result: The ICU gets a real-time, comprehensive patient dashboard. The data stream is incredibly sensitive, and NetFoundry ensures it is completely isolated from the main hospital network and the Internet, preventing snooping or data tampering. Litmus simplifies the massive challenge of device interoperability at the edge.

3. AI-Powered Diagnostic Assistant for Radiologists

This example uses an LLM agent to help physicians interpret complex medical images and patient histories more efficiently.

Scenario: A radiologist is reviewing a new CT scan for a patient with a long and complex medical history. To make an accurate diagnosis, they need to quickly understand the patient’s prior conditions, lab results, and genetic markers, and compare the current scan to previous ones.

Solution using LangGraph and NetFoundry

• LangGraph: The hospital deploys a secure, internal “Radiology Copilot” service built with LangGraph. When the radiologist opens a new scan, this agent automatically queries the EHR for the patient’s full history; accesses the Picture Archiving and Communication System (PACS) to pull prior relevant images; queries a genomic database for relevant markers mentioned in the patient’s file; feeds this context into a specialized medical LLM to generate a concise summary of “key things to look for.”
• NetFoundry SDK: The radiologist’s workstation and the LangGraph server communicate exclusively over a NetFoundry overlay network. The physician’s request and the resulting AI-generated summary (containing PHI) are never exposed to the internet. All backend queries made by the LangGraph agent to the EHR and PACS also travel over discrete, zero-trust NetFoundry services. The NetFoundry overlay can be NaaS or on-prem in this example, depending if the radiologists are on-prem.

Result: The radiologist can make faster, more informed decisions. LangGraph automates the laborious data gathering process, while NetFoundry provides the critical, HIPAA- compliant security fabric that allows these sensitive AI-driven interactions to happen safely.

4. Secure and Auditable Prescription Fulfillment Workflow

This example focuses on securing the communication between a physician, a pharmacy, and an insurance provider.

Scenario: A doctor prescribes a specialized, high-cost medication. This action needs to be securely sent to the patient’s chosen pharmacy, and a pre-authorization request must be sent to the insurance provider. This workflow is highly sensitive and a target for fraud.

Solution using Slim.AI and NetFoundry:

• Slim.AI: The microservices that handle e-prescribing and insurance claims processing are each packaged in containers hardened by Slim.AI. This reduces vulnerabilities in the applications that process some of the most sensitive patient and financial data.
• NetFoundry Go SDK: The entire workflow is built on NetFoundry services. The doctor’s EHR client uses the Go SDK to send the prescription to an e-prescribe hub service. The hub forwards it to the specific pharmacy’s endpoint, also a private NetFoundry service. Simultaneously, the hub sends an authorization request to the insurance provider’s pre-auth-gateway service. The NetFoundry overlay is provided as NaaS in this example.

Result: The prescription workflow is verifiably secure and private end-to-end. There are no public-facing APIs to attack. This zero-trust architecture prevents prescription fraud, protects patient data, and creates a clear, auditable trail of communication between authenticated parties only.

MCP security: 5 NetFoundry healthcare examples – agent based zero trust

The above 4 examples are unbelievably powerful because they embed the zero trust network in the actual application. However, sometimes we don’t have control of the application code, or it is simpler to front-end the application with NetFoundry agents or gateways, on the client and/or server side.

Therefore, here are some agent based examples of solving real-world healthcare challenges with a strong focus on simplicity, security, HIPAA compliance, reliability and performance, ensuring Patient Health Information (PHI) is protected and MCP servers are unreachable from the Internet or any underlay network.

1. AI-Assisted Radiology in a Multi-Hospital Network

Scenario: A regional hospital network uses an AI-powered diagnostic engine (LLM + computer vision) hosted in a private Azure VNet. Radiology devices in each hospital (MCP clients) need to send imaging data securely to the MCP server running the inference engine.

Solution:

• Each imaging system connects outbound-only via NetFoundry agents in Azure and the hospital.
• No inbound ports exposed on the central AI inference server.
• Policies restrict access to authorized device identities (e.g., radiology-client-east) and NetFoundry provides visibility of what identity accessed each service.
• Meets HIPAA/ISO 27001 segmentation and audit standards.

2. Secure Telepathology AI Between Rural Clinics and Urban Labs

Scenario: Pathology samples are digitized at rural clinics. A remote AI pathologist (LLM + deep learning model) hosted in a central university lab reviews and annotates them.

Solution:

• The digitization station is the MCP client.
• The lab’s review agent is the MCP server.
• NetFoundry agent or gateway ensures all traffic is identity-authenticated, encrypted, and never exposed to the public Internet.

Value:

• No VPNs or firewall holes needed in rural clinic networks.
• Enables scaling to dozens of clinics with centralized management. All access can be just in time (JIT), one-time or persistent.
• Granular, identity based telemetry.

3. AI Copilot for Medical Coding (CDI/RCM) in Hybrid Workforce

Scenario: A health system deploys a GenAI assistant to help clinical documentation improvement (CDI) specialists and revenue cycle (RCM) analysts review medical notes for better coding accuracy. Analysts work from home and must connect to a model inference engine inside a secure EHR-integrated data center.

Solution:

• MCP clients run on analysts’ local desktops along with NetFoundry agents. By policy, NetFoundry agents only touch the MCP sessions so that the other analyst work is not impacted.
• All MCP requests go outbound through NetFoundry, reaching the centralized inference server over mTLS with E2EE.
• Fine-grained access ensures only active sessions with proper credentials are allowed, reducing PHI exposure risks.

4. AI Decision Support in Operating Rooms

Scenario: OR equipment vendors integrate AI-based decision support tools (e.g., fluid monitoring, anesthesia dosing) that interact with centralized hospital systems for real-time recommendations.

Solution:

• The OR tool is the MCP client.
• The AI backend server is hosted on-site (e.g., Medtronic cloud or health system-owned HPC cluster).
• NetFoundry tunnelers protect both ends, removing the need for VPNs or exposed firewall ports in the OR subnet.

5. Secure AI-Powered Patient Engagement from EHR Portals

Scenario: A GenAI chatbot answers questions about medications, lab results, and discharge summaries for patients via their portal.

Solution:

• The EHR portal backend is the MCP client (it calls the LLM engine).
• The LLM engine is hosted in a non-EHR-connected cloud (e.g., Azure OpenAI in a private subnet).
• NetFoundry agent or gateway ensures that no one except the authenticated portal server can talk to the LLM.
• No inbound ports open in cloud LLM environment.
• All access tied to patient session tokens and hospital policies.

The post AI in Healthcare appeared first on NetFoundry.

The post What Is Zero Trust AI appeared first on NetFoundry.

The post Zero Trust AI: The Path to True Cybersecurity Innovation appeared first on NetFoundry.

It involves challenges such as protecting data privacy and confidentiality, implementing robust access control and authentication, ensuring network and infrastructure security, maintaining model integrity against tampering and adversarial attacks, establishing effective monitoring and incident response plans, and balancing security measures with performance and scalability. These measures are crucial to prevent unauthorized access, data breaches, and performance issues while complying with data protection regulations​

This article is a case study from an R&D team of a large enterprise using a large language model (LLM) from their users’ mobile, web, and thick client apps, without exposing any data or metadata to any network.  Specifically, an Azure OpenAI powered chatbot with APIs to iPhone (iOS) mobile apps, without their Azure VNet being open to any inbound data (so the firewall is set to deny all inbound).  Consider it a sneak preview – the full case study will be published next.

Our customer’s requirements went beyond security.  They included:

1. No VPNs, whitelisted IPs, or MPLS dependencies.
   
   
2. No touching the (B2B and B2B2C) mobile phones.
   
   
3. No backhauling all the app traffic – different microservices and APIs to different destinations, directly from the mobile app.

Spoiler alert: all requirements met, with an open source-based, software-only solution…with the proof of concept (POC) done in one day.

If you have requirements like this, then this case study should be worth reading.  Otherwise, this post will be boring.

The AI and LLM Security dilemma

The astounding progress of Large Language Models (LLMs) is creating two opposing forces:

1. We want to leverage the Artificial Intelligence (AI) capabilities in our apps, querying public LLMs (e.g. ChatGPT, Azure OpenAI) and self-hosted LLMs (e.g. Llama, Claude).
   
   
2. We need privacy and security. The data and prompts can contain sensitive, competitive or valuable information, including customer information.

We have seen this movie before.  In fact, the security force is why our internal enterprise apps are only available via private networks such as our WANs or VPNs.  By shielding our internal enterprise apps, APIs, and data from the Internet, we minimize the attack surface.  Unfortunately, many of the apps that we want to use AI can’t be forced onto our WAN or VPN (and their connections to the cloud such as ExpressRoute or Direct Connect), or doing so would add too much latency, failure points or user experience problems.

Solving the AI and LLM Security dilemma

So, we need a solution to enable our apps and APIs to access the LLMs, but without exposing any of the data to the Internet, and without needing to navigate MPLS or VPN.  Actually, this is exactly what NetFoundry’s OpenZiti (open source) and NetFoundry Cloud (SaaS)  already do for billions of sessions per year – the LLM on the server side doesn’t make a difference to Ziti.  Ziti enables us to:

1. Minimize the threat surface – prevent attacks from the Internet.
   
   
2. Secure the road out too – help prevent data exfiltration.
   
   
3. Provide great UX – no VPN or MPLS backhaul.
   
   
4. Simplify operations—no complex ACLs, WAF configurations, DNS dependencies, or other day two, bolted-on, infrastructure-dependent, cloud-specific security add-ons.
   

In other words, the Ziti platform enables us to get both security and simplicity.  In this case, use LLMs without network exposure and without VPN.  It is the same Ziti platform that leaders such as Microsoft, LiveView, and Intrusion use to securely deliver billions of sessions per year for use cases such as:

• IBM solution for zero trust multi-cloud networking
  
  
• IoT and Edge, such as connected cars, Arrow servers, and the EdgeX platform
  
  
• Oracle solution for zero trust APIs

Note: you can skip this post and try the solution yourself – it is all software so you can spin up a free sandbox in minutes via NetFoundry Cloud, or dive right into the open source.

iPhone app to Azure AI: requirements

Our customer had these basic requirements:

1. Develop an Azure AI (private version of ChatGPT-4) based chatbot.
   
   
2. Incorporate the chatbot into their current mobile application, published as an iOS (iPhone) app.
   
   
3. Ensure a private, secure connection between the iPhone app and Azure AI. Azure enables private networking within Azure between the customer VNet and Azure AI.  However, in the “shared responsibility model” which Azure uses (and all the cloud providers use), the connection to Azure is the responsibility of our customer to secure.
   

Azure does enable their customers to provision private MPLS circuits from customer data centers to Azure, via meet me sites.  However, in this case:

1. Backhauling the mobile app sessions to the WAN and then the data center and then Azure would add latency and failure points to every application session.
   
   
2. Adding VPN clients to all the mobile phones (most of which are not controlled by our customers) was not viable. The mobile app leverages multiple environments – only some of the APIs need to go to the Azure chatbot – making VPN backhaul even more unattractive.
   
   
3. The mobile app is already deployed at scale. The cloud MPLS solutions (ExpressRoute, Direct Connect, etc.) are complex, creating high operational costs at scale.  For the privacy of our customers, here is a public example of what it looks like (using AWS as the example:
   
   

iPhone app to Azure AI: solution

Here is what our customer did.  It turned out to be relatively simple because it is an all-software solution.  In fact, the proof of concept was successful in one day:

• Our customer used the Azure reference architecture on the Azure side, with a private Ziti router (from the Azure marketplace) in their VNet. Our customer then changed their firewall to deny all inbound traffic (the Ziti router opens outbound sessions only, yet still handles traffic originating from either the server or the client).
  
  
• They used Ziti’s Swift SDK in their mobile app. This code results in strong identification, authentication, and authorization, with delivery across their private Ziti overlay network, including mutual TLS (mTLS) and encryption.
  
  
• The private Ziti overlay network in the middle is hosted by NetFoundry as part of the NetFoundry Cloud SaaS. Our customer could have self-hosted with OpenZiti (open source).
  
  

Related case studies and use cases

Enabling mobile and web apps to leverage AI in a simple and secure manner is hot off the press.  We’ll share more details when the case studies are fully public.  In the meantime, here are similar use cases:

Private API gateway access for distributed endpoints

Here is a case study of consuming a MuleSoft API in the Oracle Cloud from a Digital Ocean cloud.  The result is direct connections over a private overlay with private IP addresses and without any dependencies on MPLS or VPN.  Here are some other examples: Kubernetes (Oracle); Multicloud (IBM); Hybrid cloud (CERM); Kubernetes (SPS)

Securing access to Kubernetes – taking the Kubectl API off the Internet

Here is how Ozone used Ziti to manage their customers’ Kubernetes environments without requiring any inbound access:

Similarly, by adding the Ziti code to APIs like the Kubernetes API (see example here), K8s APIs are made unreachable.  Here are some more API and multi-cloud examples: Kubernetes (Oracle); Multicloud (IBM); Hybrid cloud (CERM); Kubernetes (SPS)

LLM Security Summary

We can now use Artificial Intelligence (AI) capabilities in our web and mobile apps, querying public LLMs (e.g. ChatGPT, Azure OpenAI) and self-hosted LLMs (e.g. Llama, Claude), and yet maintain security and privacy.  The customer example above is specific to an iPhone iOS app querying an OpenAI-powered chatbot, but the same architecture works for other LLMs and other clouds.  You can start today:

• NetFoundry Cloud (hosted SaaS), free for up to 10 endpoints…be up and running in minutes
  
• OpenZiti open source zero trust networking platform
  
• Instantly schedule a demo or briefing

The post LLM Security – Development of AI-infused apps appeared first on NetFoundry.