AI in Healthcare

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.