HIPAA for MCP servers: securing tool access without losing the audit trail (on on-prem)

Untracked tool access on on‑prem MCP servers can instantly invalidate a HIPAA audit.

Most organizations run MCP (Model‑Control‑Plane) servers behind a firewall and grant engineers a handful of privileged accounts. Those accounts are often shared, their passwords rotate on a schedule, and the servers accept any connection that presents the correct secret. The result is a single point of failure: a compromised credential lets an attacker issue arbitrary commands, extract PHI, or tamper with logs, and there is no reliable record of who did what.

Even when teams adopt modern identity providers and issue short‑lived tokens, the connection still terminates directly at the MCP process. The token proves the caller’s identity, but the server sees the request as a raw protocol stream. No inline guardrails inspect the payload, no just‑in‑time approval step blocks risky operations, and no session is recorded for later review. In short, the setup decides *who* can connect, but it does not enforce *how* the connection is used.

hipaa requirements for on‑prem MCP servers

HIPAA’s Security Rule focuses on three core safeguards: administrative, physical, and technical. For on‑prem services that handle electronic protected health information (ePHI), the technical safeguards are the most visible:

• Access control: each user must have a unique identifier, and access must be limited to the minimum necessary functions.
• Audit controls: hardware or software mechanisms must record and examine activity on information systems that contain or use ePHI.
• Integrity controls: mechanisms must protect ePHI from improper alteration or destruction.

When an MCP server is accessed without a dedicated gateway, organizations typically satisfy the first bullet by issuing unique tokens, but they fall short on the second and third. Without a point where traffic can be inspected and logged, there is no guarantee that a privileged command was not executed by an unauthorized actor, nor that the response data was not altered before reaching the client.

Why a gateway is the only place to enforce technical safeguards

Enforcement must occur where the request passes through a component that the service itself cannot bypass. This component is the data path. By inserting a Layer 7 proxy between the identity provider and the MCP server, every protocol command can be examined, approved, masked, or blocked before it reaches the target. The gateway also captures the full request‑response exchange, providing a tamper‑evident log that auditors can review.

In practice, this means:

• All connections are terminated at the gateway, which validates the OIDC or SAML token.
• The gateway checks the user’s group membership and applies policy that may require a manager’s approval for destructive commands.
• Before the command is forwarded, the gateway can redact or mask any PHI that appears in the response, ensuring that downstream logs do not leak sensitive data.
• Every session is recorded, enabling replay for forensic analysis.

These capabilities directly satisfy HIPAA’s audit‑control and integrity requirements, while the identity check satisfies the access‑control requirement.

Introducing hoop.dev as the HIPAA‑compatible gateway

hoop.dev is an open‑source Layer 7 gateway that sits in the data path for MCP servers. It authenticates users via OIDC or SAML, reads group membership, and then applies policy before any traffic reaches the MCP process. Because hoop.dev is the only point that can see the raw protocol, it is uniquely positioned to provide the technical safeguards HIPAA demands.

hoop.dev records every session. When an engineer runs a query or issues a control command, hoop.dev captures the full request and response, timestamps each line, and stores the record securely for audit. Auditors can retrieve these logs to prove who accessed ePHI and when.

hoop.dev masks sensitive fields inline. If a response contains patient identifiers, hoop.dev can apply a masking rule that redacts those fields before they are written to downstream logs, preserving privacy while still providing operational insight.

hoop.dev enforces just‑in‑time approvals. For high‑risk commands, such as deleting a database or modifying access policies, hoop.dev can pause the request and route it to an approver. The command only proceeds after explicit consent, adding a human safeguard against accidental or malicious actions.

hoop.dev blocks disallowed commands. Policy can specify forbidden patterns (for example, attempts to export full tables of PHI). When such a pattern is detected, hoop.dev rejects the request and logs the attempt.

All of these enforcement outcomes exist only because hoop.dev resides in the data path. The identity system alone cannot provide them; the gateway is the enforcement engine.

Setting up the compliance envelope

The compliance envelope begins with a well‑designed setup phase. Organizations provision an OIDC or SAML provider, define groups that map to HIPAA roles (e.g., “clinical‑read”, “admin‑write”), and configure hoop.dev to trust the provider. The gateway then uses those groups to make real‑time decisions.

Once the gateway is deployed, engineers connect to the MCP server using their usual client tools (psql, curl, etc.). The client talks to hoop.dev, which authenticates the user, applies policy, and forwards the request. No credential ever leaves the gateway, and the MCP server never sees the raw user token.

Because hoop.dev is open source, teams can inspect the code, verify that no backdoors exist, and even extend the masking or approval logic to meet organization‑specific requirements.

Evidence generation for HIPAA audits

HIPAA auditors request logs that demonstrate:

• Who accessed the system.
• When the access occurred.
• What actions were performed.
• Whether any protected data was exposed.

hoop.dev generates this evidence automatically. Each session log includes the user’s unique identifier, a timestamp, the full command, and the masked response. Approval events are also recorded, showing who granted permission and when. Because the gateway controls the entire data path, the logs cannot be altered by a compromised MCP process.

When auditors request proof of compliance, teams can export the session archive from hoop.dev’s storage backend and provide it as part of the audit package. The logs satisfy the “audit controls” and “integrity controls” sections of the HIPAA Security Rule without requiring additional tooling.

Getting started

To begin protecting your on‑prem MCP servers with hoop.dev, follow the getting started guide. The documentation walks you through deploying the gateway, configuring OIDC trust, defining HIPAA‑aligned groups, and enabling session recording and masking. For deeper insight into policy configuration, see the feature documentation.

FAQ

Does hoop.dev replace the existing identity provider?

No. hoop.dev relies on your existing OIDC or SAML provider for authentication. It consumes the token, extracts group membership, and then enforces HIPAA‑specific policies in the data path.

Can I use hoop.dev with existing on‑prem monitoring tools?

Yes. hoop.dev stores session logs in a configurable backend that can be read by SIEM or log‑aggregation solutions. The logs are already enriched with user identifiers and timestamps, making correlation straightforward.

Is the masking performed on the client side?

No. Masking happens inside hoop.dev before the response leaves the gateway. This ensures that downstream systems never see raw PHI, and the original data remains protected at rest.

View the open‑source repository on GitHub for the latest code, contribution guidelines, and issue tracker.