When a medical application leaks a single patient record, the financial penalties can exceed millions of dollars and the reputational damage may be irreversible. Regulators expect every system that touches protected health information (PHI) to demonstrate strict access controls, immutable audit trails, and real‑time data protection. Failing to meet those expectations not only invites fines under HIPAA but also erodes patient trust and can halt product development.
Many teams deploy MCP (Model‑Control‑Protocol) gateways to expose AI‑enhanced services to internal tools. In practice, the gateway often runs with a long‑lived service account, and engineers connect directly to the downstream model server using the same credential for weeks or months. The gateway forwards requests without inspecting the payload, and there is little visibility into who issued which inference or why a particular response was returned. Because the gateway sits outside the traditional IAM perimeter, the organization ends up with a black box that can read or write PHI without any record of the action.
This arrangement satisfies the basic requirement that a model is reachable, but it leaves three critical gaps: the request still reaches the model server directly, there is no audit of which user triggered a request, and no mechanism masks sensitive fields in the model’s output. The setup alone cannot guarantee PHI compliance; it merely provides connectivity.
Why the data path must enforce compliance
Compliance cannot be achieved by identity checks alone. An OIDC or SAML token can confirm who a user is, but without a control point that inspects each request, the organization cannot enforce least‑privilege, prevent accidental exposure of PHI, or produce evidence for auditors. The enforcement point must sit in the data path, between the authenticated identity and the model server, so that every request can be examined, approved, or transformed before it reaches the backend.
Introducing hoop.dev as the compliance gateway
hoop.dev is a layer‑7 gateway that sits exactly in that data path. It verifies OIDC/SAML tokens, derives group membership, and then applies policy decisions before forwarding traffic to the MCP target. Because hoop.dev is the only component that sees the request in transit, it can provide the enforcement outcomes required for PHI compliance.
Setup: identity and least‑privilege grants
The first step is to configure an identity provider (Okta, Azure AD, Google Workspace, etc.) to issue short‑lived tokens for engineers and service accounts. hoop.dev acts as the relying party, validating each token and extracting claims that describe the user’s role. By assigning narrowly scoped groups, such as clinical‑read or research‑write, the organization ensures that only the right people can request PHI‑related operations. The token itself never reaches the model server, so credential leakage is eliminated.
Data path: the gateway that enforces policy
Once a request arrives at hoop.dev, the gateway becomes the sole enforcement point. It can:
- Require just‑in‑time (JIT) approval for any request that includes PHI, routing the request to an authorized reviewer before it proceeds.
- Mask sensitive fields, such as patient identifiers, dates of birth, or medical record numbers, in the model’s response, ensuring that downstream consumers never see raw PHI.
- Block commands or queries that exceed predefined risk thresholds, preventing accidental data exfiltration.
- Record the entire session, including request payload, response payload, and the identity that initiated it, so that auditors can reconstruct any interaction.
All of these outcomes are performed by hoop.dev, because the gateway is the only component that can see and transform the traffic.
Enforcement outcomes that satisfy HIPAA
hoop.dev generates the evidence auditors need: logs that tie each request to a verified identity, timestamps, and the applied masking policy. The logs are collected centrally by the gateway, providing a reliable audit trail that can be reviewed independently of the model server. Session recordings enable replay of any interaction, supporting forensic investigations. Inline masking ensures that even if a downstream analyst inadvertently stores output, the PHI has already been removed.
Practical steps to make your MCP gateway PHI‑compliant
- Configure your identity provider with short‑lived tokens and map users to compliance‑oriented groups.
- Deploy hoop.dev using the getting‑started guide. The quick‑start includes built‑in OIDC validation and a default policy framework.
- Define masking rules for all PHI fields in the learn section. Rules can target JSON keys, CSV columns, or plain‑text patterns.
- Enable JIT approval for any request that matches a PHI‑sensitive pattern. Approvers receive a concise summary and can grant or deny access in seconds.
- Turn on session recording for the MCP connector. Recordings are kept separate from the model server, providing an untampered audit trail.
- Regularly review audit logs and replay recordings to verify that masking and approval workflows are functioning as intended.
Common pitfalls
- Relying on a single static service account for the gateway. This defeats the purpose of JIT and makes credential rotation painful.
- Defining overly broad groups. If a group includes both clinicians and developers, the developer may inadvertently gain PHI access.
- Neglecting to test masking rules against real payloads. An untested rule can let a PHI field slip through.
FAQ
Do I need to modify my existing MCP client code?
No. hoop.dev proxies standard MCP traffic, so existing clients continue to use the same endpoint and protocol. The only change is the network address, which now points to the gateway.
Can hoop.dev work with multiple identity providers?
Yes. The gateway can be configured to accept tokens from any OIDC or SAML provider, allowing a hybrid environment where clinicians use one IdP and researchers use another.
How long are the audit logs retained?
Retention is a configuration choice made when deploying the gateway. hoop.dev itself does not impose a limit; you can set policies that align with your organization’s data‑retention schedule.
Get started
To see the full implementation details, clone the open‑source repository and follow the documentation. Explore the code on GitHub and begin securing your MCP gateways today.
