Why HIPAA matters for MCP servers
An offboarded contractor still has a CI token that can invoke an internal MCP server, and a developer pushes a new version of a code‑assistant that talks directly to the same service. The MCP server processes patient data, runs transformations, and returns results that may contain protected health information (PHI). In a typical deployment the service is reachable through a plain network endpoint, protected only by the token that granted the initial access. If that token is over‑scoped, or if the service is called from an automated job, the request bypasses any review and leaves no immutable record of who asked what and when. HIPAA requires that every access to PHI be logged, that the logs be tamper‑evident, and that any accidental exposure be mitigated through masking or approval workflows. The reality on many Kubernetes clusters falls short of those requirements.
What a minimal fix looks like
Most teams start by federating identities with an OIDC provider such as Okta or Azure AD. The provider issues a short‑lived token that a CI job or a user presents to the MCP server. This step satisfies the “who is calling” part of HIPAA, because the token proves the caller’s identity. However, the request still travels directly to the MCP server, which means the server itself decides whether to honor the call, and no central component records the payload or the response. The setup therefore lacks three critical controls:
- Continuous, tamper‑resistant audit of every request and response.
- Inline masking of PHI in responses before it reaches the caller.
- Just‑in‑time (JIT) approval for risky operations, such as bulk data exports.
Without a gateway that sits on the data path, those controls cannot be enforced. The identity provider alone does not block a command, does not redact fields, and does not keep a replayable session record. In other words, the necessary HIPAA evidence never accrues.
How hoop.dev provides continuous evidence
hoop.dev acts as a Layer 7 gateway that proxies every MCP‑server connection on Kubernetes. The gateway runs alongside the MCP service inside the cluster, and all clients, human engineers, CI pipelines, or AI agents, must route their traffic through it. Because hoop.dev sits in the data path, it is the only place where enforcement can happen. The gateway records each session, masks PHI in responses, and can require a human approver before executing a command that matches a policy rule. The result is a stream of audit‑ready evidence that satisfies HIPAA’s logging and access‑control requirements.
Specifically, hoop.dev delivers these outcomes:
- Session recording. The gateway captures every request and response and stores them in an immutable log, supporting forensic replay.
- Inline data masking. The gateway redacts sensitive fields such as patient identifiers before the data leaves it, reducing the risk of accidental PHI exposure.
- Just‑in‑time approval. Policies can require that a privileged operation, like exporting a full dataset, be approved by a designated reviewer before the gateway forwards the command.
- Command blocking. Dangerous commands, for example those that delete records, are halted by the gateway without ever reaching the MCP server.
hoop.dev enforces all of these controls; the underlying MCP service and the identity provider do not. If the gateway were removed, the audit evidence would disappear, the masking would stop, and approvals would no longer be required. This makes hoop.dev the essential component for HIPAA compliance in this scenario.
Deploying the gateway on Kubernetes
Deploying hoop.dev on a Kubernetes cluster follows the standard quick‑start flow. A Docker‑Compose file is provided for local testing, and Helm charts are available for production deployments. The deployment includes an agent that runs in the same network namespace as the MCP server, ensuring that credentials never leave the cluster. Identity is verified against an OIDC provider; the gateway reads group membership to decide whether a request is eligible for JIT access or requires approval. For detailed steps, see the getting‑started guide and the broader learn section.
Evidence that accrues continuously
HIPAA audits look for evidence that is generated at the moment of access, not retroactively. Because hoop.dev records each session as it happens, the audit trail grows continuously. Auditors can query the log for a specific user, time window, or data field, and they will see a complete, tamper‑evident record. The gateway’s masking logs also show which fields were redacted, providing proof that PHI never left the controlled environment in clear text. Approval workflows are logged with timestamps and reviewer identities, satisfying the “authorized access” requirement.
FAQ
Does hoop.dev replace the need for an OIDC provider?
No. hoop.dev relies on an OIDC or SAML provider to authenticate callers. The provider establishes identity, while hoop.dev enforces policies on the data path and generates the audit evidence required by HIPAA.
Can I use hoop.dev with existing MCP deployments?
Yes. hoop.dev is designed to sit in front of any MCP server that runs inside Kubernetes. You register the server as a connection, and the gateway proxies traffic without requiring changes to the MCP service code.
How does hoop.dev store the audit log securely?
The gateway stores immutable logs that operators can export for compliance reporting. Storage options and configuration details are covered in the documentation.
Ready to add HIPAA‑grade audit capability to your MCP servers? Explore the open‑source repository and start the deployment today: github.com/hoophq/hoop.
