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

Storing patient data on an MCP server without a tamper‑proof audit trail is a direct violation of HIPAA’s security rule.

Most teams on GCP provision an MCP server with a static service‑account key that is copied to developers, CI pipelines, and occasionally to third‑party tools. The key lives in secret stores, in environment variables, or even in plain‑text configuration files. When a developer runs a query, the request travels straight from the client to the MCP server. The server authenticates the service account, executes the command, and returns the result. No intermediary observes the traffic, no central log captures the exact query, and no mechanism masks protected health information (PHI) that may appear in the response. If a credential is leaked, anyone with the key can issue arbitrary commands, exfiltrate data, or delete resources, and the organization has no reliable evidence of who did what.

HIPAA’s Security Rule requires covered entities to implement audit controls that record "who accessed an information system and what they did" (45 CFR §164.312(b)). It also demands mechanisms to protect the integrity and confidentiality of electronic PHI. In practice, that means organizations must be able to prove that every access to an MCP server was authorized, that the data returned was protected, and that any privileged operation received appropriate oversight.

Moving to an identity‑centric model, using OIDC or SAML to issue short‑lived tokens, assigning the minimum set of permissions to each user, addresses the "who may access" part of the equation. However, the request still goes directly to the MCP server. The gateway that could enforce real‑time masking, require just‑in‑time approvals, or capture a complete session log is missing. Without that data path control, the organization still cannot generate the audit evidence HIPAA demands.

hoop.dev inserts a Layer 7 gateway between identities and the MCP server. The gateway validates OIDC tokens, maps group membership to fine‑grained policies, and then proxies the connection to the server using its own credential. Because the gateway sits in the data path, it can record every command, mask PHI in responses, and route risky operations to a human approver before they execute. The result is a verifiable audit trail that includes user identity, timestamp, exact query, and any masking applied.

hipaa evidence requirements for MCP servers

HIPAA expects three core audit artifacts:

• Access logs that show the user, time, and action.
• Integrity controls that ensure logs cannot be altered without detection.
• Confidentiality safeguards that prevent PHI from being exposed unintentionally.

hoop.dev provides each of these directly in the data path. When a request passes through the gateway, the system writes a session record that cannot be modified by the client or the MCP server. The record contains the raw request, the decision outcome (allowed, blocked, or sent for approval), and the masked response that was delivered to the client. Because the gateway owns the credential, the client never sees the underlying service‑account key, eliminating the risk of credential leakage.

How the gateway creates compliant evidence

First, the gateway authenticates the user against an OIDC provider such as Google Workspace or Azure AD. The token’s claims are examined, and the gateway consults policy rules that map groups to specific MCP server operations. If the policy allows the command, the gateway forwards it to the server; if the command is deemed risky, e.g., a DELETE or a query that returns a large number of rows, the gateway can pause execution and require a human approver to confirm.

Second, every byte that traverses the gateway is captured. The session log includes the exact SQL statement, the user’s identity, and a timestamp. When the server returns data, the gateway can apply inline masking rules to redact columns that contain PHI, such as Social Security numbers or medical record identifiers. The masked response is what the client receives, and the original unmasked payload is stored only in the immutable audit record.

Third, the gateway stores the audit record in a tamper‑evident store. Because the record originates outside the MCP server, the server cannot alter it. The system also supports replay, allowing auditors to reconstruct the exact interaction for any point in time. This satisfies HIPAA’s requirement that audit logs be retained for at least six years and be available for inspection.

Operational benefits beyond compliance

While the primary driver is HIPAA evidence, the gateway also reduces blast radius. By enforcing just‑in‑time access, engineers receive temporary permissions that expire automatically, limiting the window for misuse. Inline masking prevents accidental PHI leakage in logs or downstream tools. Human approval workflows add a second set of eyes for high‑risk actions, catching mistakes before they affect production.

Because the gateway is open source, teams can inspect the code, extend policies, and integrate with existing CI/CD pipelines. The same architecture works across other compliance frameworks that require strict audit trails, such as GDPR or SOC 2, without claiming any certification for hoop.dev itself.

Getting started on GCP

Deploy the gateway using the official Docker Compose quick‑start, configure OIDC authentication, and register your MCP server as a connection. Detailed steps are available in the getting‑started guide. For deeper policy examples and masking configurations, see the learn section of the documentation.

FAQ

Does hoop.dev make my MCP server HIPAA certified?
No. hoop.dev provides audit evidence and controls that can be used as part of a HIPAA‑compliant process, but it does not hold any HIPAA certification.

Can I use existing GCP audit logs instead of hoop.dev?
GCP audit logs capture infrastructure‑level events but do not record the exact query text, response masking, or just‑in‑time approvals that HIPAA requires for application‑level access.

What happens if an approver does not respond?
The gateway can be configured to deny the request after a timeout, ensuring that risky operations never proceed without explicit consent.

Explore the open‑source repository to see how the gateway is built and to contribute improvements: https://github.com/hoophq/hoop.