Many think that simply running an MCP server behind a cloud firewall automatically satisfies HIPAA because the infrastructure is “secure by default.” In reality, HIPAA audits demand concrete evidence of who accessed protected health information, when, and under what controls.
Why the current approach falls short of HIPAA
Today, most teams launch MCP servers that query PostgreSQL directly with a shared service account. The credential lives in a configuration file or an environment variable, and every developer can connect with the same password. A gate does not route any request, so the system cannot record the exact SQL statement, mask patient identifiers, or require an approval before a risky query runs. When a breach occurs, the logs only show a generic connection event. They do not prove that the individual who issued the query was authorized, nor do they demonstrate that protected data was protected at the moment of access.
What a minimal fix looks like, and what it still misses
Introducing non‑human identities, such as short‑lived OIDC tokens, and assigning least‑privilege roles to those tokens is a necessary first step. The token tells the PostgreSQL instance who the caller is, and the role limits the tables that can be read. However, the request still travels straight from the MCP server to the database. No component sits on that path to capture the full query, no inline masking protects PHI in the response, and no workflow can pause a dangerous operation for a compliance officer’s sign‑off. Without a data‑path gateway, the organization cannot produce the audit artifacts that HIPAA auditors require.
How hoop.dev creates an audit‑ready data path
hoop.dev acts as a Layer 7 gateway that sits between the MCP server and PostgreSQL. Every connection is proxied through the gateway, which inspects the wire‑protocol traffic before it reaches the database. Because hoop.dev is the only point where traffic flows, it can enforce the controls that HIPAA expects.
When a developer’s OIDC token is presented, hoop.dev validates the token, extracts group membership, and decides whether to grant a just‑in‑time session. If the request is allowed, hoop.dev records the full SQL statement, the identity that issued it, and the exact timestamp. hoop.dev keeps the session data available for later query, providing the evidence needed for compliance.
In addition to logging, hoop.dev can mask protected fields in query results. For example, a column containing Social Security Numbers is replaced with a placeholder before the data leaves the gateway, ensuring that downstream tools never see raw PHI unless explicitly permitted. If a query matches a risk pattern – such as a DELETE without a WHERE clause – hoop.dev blocks the command and routes it to a human approver, creating a documented approval trail.