When a protected health information (PHI) breach lands on a compliance audit, the financial penalties and reputational damage can dwarf the cost of a well‑designed control framework. Organizations that rely on AI‑enabled services often discover that they have no concrete evidence of who accessed PHI, what was returned, or whether any data was inadvertently exposed. Without that evidence, auditors cannot verify that the entity meets the HIPAA Security Rule, and the organization faces fines, corrective action plans, and loss of trust.
What HIPAA auditors look for from an MCP gateway
The HIPAA Security Rule requires documented safeguards for electronic PHI (ePHI). Auditors expect to see:
- A complete log of every user or service that accessed ePHI, including timestamps and the identity that performed the request.
- Proof that only the minimum necessary data was returned, with any excess or sensitive fields masked or redacted.
- Evidence that privileged commands were approved by a designated authority before execution.
- Replayable session records that demonstrate the exact sequence of interactions with the data source.
These artifacts must be generated at the point where the request traverses the network, not after the fact in a downstream log aggregation system.
The typical gap in MCP gateway deployments
Many teams deploy an MCP gateway to expose an LLM or custom AI service to internal applications. The gateway forwards requests directly to the underlying database or API, and the AI model returns answers that may contain PHI. In practice, organizations often rely on the following assumptions:
- Authentication is handled by an upstream identity provider, so the request is “trusted.”
- Authorization is enforced by the target service, which is presumed to reject unauthorized reads.
- Logging is limited to the target’s native audit trail, which does not capture the AI‑generated response.
Those assumptions leave three critical blind spots:
- The gateway itself does not record the request or response, so there is no end‑to‑end audit trail.
- Any PHI that the AI model includes in its answer is sent unfiltered to the caller, violating the minimum‑necessary principle.
- Risky commands, such as bulk extracts or schema changes, can be executed without a human sign‑off.
Even when the organization has strong identity federation and least‑privilege IAM roles, the lack of a control point in the data path means auditors cannot prove that those safeguards were actually applied.
The data‑path control you need
HIPAA compliance demands that enforcement happen where the traffic flows, not just at the edges of the identity system. A dedicated, protocol‑aware gateway can inspect each request, apply policy, and emit evidence that auditors can verify. The gateway must be able to:
- Capture the full request and response payload for every session.
- Mask or redact PHI fields in real time, based on configurable patterns.
- Pause execution of high‑risk commands and route them to a human approver.
- Store session recordings in a store that preserves their integrity and can be queried directly by auditors.
When these capabilities sit in the data path, the organization gains the concrete artifacts required by the HIPAA Security Rule.
How hoop.dev provides the missing pieces
hoop.dev is built exactly for this role. It sits between the identity provider and the target resource, acting as a Layer 7 gateway that understands the wire protocol of the MCP service. Because the gateway is the only path the request can take, hoop.dev can enforce every safeguard and generate the evidence auditors expect.
Session recording for auditability
Every connection that passes through hoop.dev is recorded from the first byte to the last. The recording includes the authenticated identity, the exact query sent to the MCP service, and the response that was returned. Auditors can replay a session to verify that no PHI was leaked or that a privileged operation was performed only after approval.
Inline data masking
hoop.dev can apply real‑time masking rules to response payloads. By configuring patterns that match PHI fields, such as Social Security numbers, medical record numbers, or dates of birth, hoop.dev replaces those values with a placeholder before the data reaches the caller. The original values remain hidden, satisfying the minimum‑necessary requirement while still allowing the AI model to function.
Just‑in‑time approvals for risky commands
When a request matches a high‑risk signature, e.g., a bulk SELECT that exceeds a row‑count threshold, hoop.dev automatically pauses the request and forwards it to an approval workflow. A designated reviewer can approve or deny the operation, and hoop.dev records the decision alongside the session log. This workflow provides the “human authorization” evidence that HIPAA auditors look for.
Centralized evidence store
All recordings, masking decisions, and approval events are written to a centralized store that is separate from the target system. The store is designed for read‑only access by auditors, ensuring that the evidence cannot be altered after the fact. Because hoop.dev controls the write path, the organization can guarantee the integrity of the audit trail.
Open‑source and extensible
hoop.dev is MIT licensed and available on GitHub. Teams can self‑host the gateway, integrate it with their existing OIDC or SAML identity provider, and extend the masking or approval logic to match their specific HIPAA policies. The getting‑started guide walks through deployment, while the learn section provides deeper explanations of each feature.
FAQ
Does hoop.dev make my MCP gateway HIPAA‑certified?
No. hoop.dev does not hold any certification. It generates the audit evidence that a HIPAA compliance program can use to demonstrate that the required safeguards are in place.
Can I use hoop.dev with an existing identity provider?
Yes. hoop.dev acts as a relying party for any OIDC or SAML provider, such as Okta, Azure AD, or Google Workspace. It validates the token and extracts group membership to drive its access policies.
What happens to data that is masked?
The original PHI never leaves the target system. hoop.dev replaces the sensitive fields with a placeholder before the response is sent to the caller, ensuring that only the allowed data is exposed.
Take the next step
To see the code, contribute improvements, or start a pilot deployment, explore the open‑source repository on GitHub. The project includes Docker Compose and Kubernetes manifests that let you stand up a fully‑featured gateway in minutes.
