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 eEiciency, 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 – 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. Often flat out impossible at scale – and that’s human scale rather than AI scale. Meanwhile, those mechanisms have proven to be insecure in modern application topologies – again, even pre-AI. Finally, reliability and performance can be problematic in VPN and firewall based architectures.

So, how do we innovate with MCP while getting the operational eEiciency, reliability, performance and security we need?

NetFoundry for MCP

One solution is to take the MCP servers oE the networks. Make them unreachable from the underlay networks. NetFoundry does this by identifying, authenticating and authorizing each session before it is allowed on an 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.

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 an extremely powerful combination – it means an attacker needs to breach two independent security implementations, each which are based on strong identities and modern cryptography.

Because NetFoundry authorizes each network session – 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 – NetFoundry gates layer 3 access via layer 7 identity, authentication and authorization in a software-only architecture which does not depend on underlying infrastructure. What does that mean? Simple, at-scale operations with centralized, network-independent controls and telemetry.

MCP security: deployment options

There are two main ways to deploy – one optimized for greenfield and one for brownfield:

• Greenfield: Use NetFoundry SDKs to embed overlay network endpoints in the MCP client and 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 network 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: add 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 or on-prem 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 diEerent methods on the other side (e.g. TLS, mTLS), or at least starting there.

MCP security: NetFoundry healthcare examples – agentless zero trust

As mentioned above, NetFoundry SDK-based implementation options can be extremely powerful. 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 representative examples in the context of solving real-world healthcare challenges with a strong focus on 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 securely collecting data from patients at home, which is a cornerstone of modern preventative care.

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. It also shrinks the software size, making remote updates easier and more reliable.
• NetFoundry Go SDK: The Go application on the hardened gateway collects readings from the medical devices. It uses the Go SDK to dial a NetFoundry service (e.g. rpm-data-ingest) to transmit the encrypted PHI. The hospital’s Electronic Health Record (EHR) integration server binds to this service, accepting data only from authenticated gateways. The NetFoundry overlay, operated as NaaS or by the hospital, provides reliability, performance, controls and telemetry. For example, the access can be done as Just-in-Time (JIT).

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 diEerent 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 service. In this case, the NetFoundry network is deployed on-premises, and air-gapped.

Result: The ICU staE 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 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: NetFoundry healthcare examples – agent based zero trust

The above 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 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 traEic 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 oE-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.