HIPAA for MCP servers: securing tool access without losing the audit trail

Hand a HIPAA auditor your architecture diagram and watch where the pen lands. It lands on the MCP server, the box that exposes a query tool and a command tool to a model, with an arrow pointing straight at the database holding protected health information. The auditor asks the questions the Security Rule trains them to ask, and the diagram does not answer any of them on its own. HIPAA for MCP servers is the work of making that box produce answers instead of raising questions.

An MCP server is a tool host. When one of its tools reaches a system with electronic PHI, the access behind that tool call falls under the HIPAA Security Rule's access controls, audit controls, and the minimum-necessary standard. The server is convenient infrastructure; it is also a new path to PHI that an auditor will trace end to end.

The questions a HIPAA auditor brings to an MCP server

• Who is behind the tool call? Unique user identification expects each actor accessing ePHI to be distinct. If every tool call reaches the database as one server identity, the auditor cannot tell one caller from another.
• Is access limited to the minimum necessary? A tool that can read the whole patient table to answer a billing question is over-scoped by definition.
• Where is the audit control? The rule expects a record of activity in systems with ePHI. The auditor wants it complete, attributable, and not stored inside the component that could distort it.
• What happens on emergency or break-glass access? Was it approved, was it bounded, and is there a record.

The trap is answering these from the MCP server's own logs. Those logs show tool invocations on the application's terms, not the identity, scope, and PHI access behind them, and they sit inside the very component whose behavior is in question.

Keeping the audit trail outside the server

The architectural requirement HIPAA pushes you toward is plain: the audit trail for tool-driven PHI access must be created and held outside the MCP server, at the boundary the tool calls cross to reach infrastructure. A trail the server keeps about itself does not satisfy an audit control, because the audited component is also the witness.

hoop.dev is built to be that external boundary. The databases and internal services an MCP server's tools reach sit behind hoop.dev, a Layer 7 access gateway with a network-resident agent. Tool calls connect through it under a real identity, the gateway enforces scope, and it records the session on its own side. Inline masking lets a tool return only the PHI fields its task needs, which is how the minimum-necessary standard becomes a control on the connection rather than a promise. hoop.dev generates the evidence for HIPAA, per-identity access logs, approvals, and masking records, that your program presents to the auditor. The getting-started docs show fronting a database and the learn pages explain how access and recording fit together.

The diagram, redrawn

Redraw the diagram with the boundary in it. The MCP server still hosts tools, but its arrow to the database now passes through hoop.dev. Each tool call arrives under an identity, scoped, masked, and recorded. When the auditor's pen lands on the box this time, the answers are sitting next to it: who called, what they were permitted, what they saw, and a recording that the server itself could not have edited. The MCP server keeps securing tool access; the audit trail lives where an auditor will accept it.

FAQ

Does putting hoop.dev in front make our MCP server HIPAA compliant?

No. HIPAA compliance belongs to your organization, not to any single component, and hoop.dev does not hold a HIPAA certification. hoop.dev generates the evidence for HIPAA, attributable access logs, scoped access, masking, and recordings, that your program uses to show the Security Rule safeguards are in place.

Why not just retain the MCP server's logs longer?

Longer retention does not fix attribution or independence. The server's logs still show tool calls, not the identity and PHI access behind them, and they still live inside the audited component. Capture the trail at the boundary instead.

hoop.dev is open source. To route your MCP server's PHI-bound tool calls through a recorded, scoped access boundary, start from the repository on GitHub.