How can you run an MCP server that handles PHI without exposing patient data or breaking audit requirements?
Most teams deploy MCP (Model Control Proxy) services with a single long‑lived API key, expose the endpoint on the internal network, and let any service that knows the key call the model. The key is often shared across dozens of micro‑services, CI pipelines, and even test environments. Engineers push new code, bots invoke the proxy, and the request travels directly to the model without any visibility into who asked for what. No request‑level logging, no real‑time masking, and no approval workflow exist. In practice, that static credential model gives every caller unrestricted read‑write access to the model’s responses, which may contain PHI.
When PHI appears in a language‑model response, the lack of controls creates a compliance nightmare. Regulators expect that any system handling PHI can prove who accessed the data, what they saw, and that sensitive fields were protected. Without session records, you cannot demonstrate intent‑based access. Without inline masking, a stray token or debugging session can leak a patient’s name or diagnosis. And without a just‑in‑time approval step, a compromised service can exfiltrate large volumes of PHI in a single burst.
What PHI compliance looks like for an MCP server
Compliance programs typically require four technical safeguards for PHI:
- Strong identity verification so that only authorized identities can invoke the proxy.
- Real‑time data masking that redacts PHI fields before they leave the model.
- Immutable audit logs that capture who made each request, the request payload, and the masked response.
- Just‑in‑time approval for high‑risk queries, ensuring a human reviews any request that could expose sensitive information.
These controls must be enforced at the point where the request passes between the caller and the model. Any enforcement that lives only in the client or in an upstream identity provider cannot see the actual payload, and therefore cannot guarantee that PHI is protected.
Why the data path is the only place to enforce PHI safeguards
The identity layer, OIDC, SAML, or any other token service, decides who may start a session. It can issue short‑lived tokens, assign groups, and enforce least‑privilege policies. That setup is essential, but it does not see the model’s output. If the token‑validation step approves a request, the request still travels directly to the model, bypassing any PHI‑specific checks.
Enforcement must therefore sit in the data path, the exact hop that carries the request and response. By placing a gateway between the caller and the MCP server, you gain a single point where every byte can be inspected, altered, or logged. This architecture prevents a compromised client from sidestepping controls, because the gateway does not trust the client’s view of the data.
How hoop.dev provides the required PHI controls
hoop.dev is a Layer 7 gateway that sits in the data path for MCP connections. It authenticates callers via OIDC or SAML, reads group membership, and then decides whether to allow the request. Once a request is allowed, hoop.dev can:
- mask PHI fields in real time, ensuring that any response leaving the model is scrubbed of protected health information;
- record each session end‑to‑end, capturing the original request, the masked response, and the identity that initiated it;
- require a human approver for queries that match a high‑risk pattern, such as those that contain diagnostic codes or patient identifiers;
- block commands that attempt to extract raw model weights or other unsafe operations before they reach the model.
Because hoop.dev is the only component that sees the full payload, every enforcement outcome originates from it. hoop.dev generates the audit evidence that auditors look for when assessing PHI compliance, and it does so without requiring changes to existing MCP client code.
Deploying hoop.dev is straightforward. The quick‑start guide walks you through launching the gateway with Docker Compose, configuring OIDC, and registering an MCP target. The gateway holds the model credentials, so callers never see them. For deeper guidance on masking policies and approval workflows, see the learn section and the getting‑started documentation.
FAQ
Do I need to modify my MCP client code?
No. hoop.dev acts as a transparent proxy. Your client continues to point at the same host and port, but the traffic now flows through the gateway, which applies the PHI safeguards.
Can hoop.dev work with my existing OIDC provider?
Yes. hoop.dev is an OIDC relying party, so any standards‑compliant provider (Okta, Azure AD, Google Workspace, etc.) can issue the tokens that hoop.dev validates.
How are audit logs retained and protected?
hoop.dev writes immutable session records to a storage backend of your choice. The logs include the identity, request, and masked response, providing the evidence needed for PHI audits.
Ready to see how the gateway works in practice? Explore the source code on GitHub and start building a PHI‑compliant MCP deployment today.
