The pitch for AI in healthcare operations is strong: let a clinician ask the scheduling system a question in plain English, let a billing team summarise a claims backlog. MCP is how those systems get connected. The moment a tool returns a patient name next to a diagnosis code, the result is protected health information, and HIPAA applies to every hop it takes from there.

This post maps HIPAA’s Security Rule and the business associate framework onto an MCP deployment. It is written for the people who have to make the architecture decision, not as legal advice.

Every hop needs a business associate

A covered entity may share PHI with a vendor only under a business associate agreement. An MCP tool call creates a chain of vendors that each receive PHI:

  1. The MCP server operator. If it is the EHR or practice-management vendor’s own server, your existing BAA probably covers it. If it is a third-party connector or an open-source wrapper someone deployed, it does not.
  2. The AI client, which carries the result to the model.
  3. The model provider. Some offer a BAA for their API or enterprise tiers under conditions such as zero data retention. Consumer plans typically do not, and that is the plan an individual employee signs up for on their own.
  4. Any system a write tool copies the data into: a messaging app, a ticketing tool, a document store.

The first question for each connected server is therefore not “is it secure?” but “is there a BAA?” A no on any link in the chain is a disclosure without authorisation, regardless of how good the encryption is.

Minimum necessary, expressed as tool rules

The minimum necessary standard requires limiting PHI use and disclosure to what the task requires. MCP servers expose broad capability by default; a scheduling server’s list_patients tool returns everything the API returns. The standard is met by narrowing the tools the AI can call, not by trusting the model to be restrained.

  • Front-desk roles get appointment tools, not clinical-note tools.
  • Record-level reads are allowed only where the workflow needs them, and bulk-export tools are blocked for every AI client.
  • Write tools that could move PHI into non-covered systems are gated behind human approval or removed.

This is ordinary role-based access control, applied at the tool level rather than the application level. It is also what reduces the blast radius of a prompt injection: a model that can only read one appointment cannot be tricked into reading a thousand.

The Security Rule’s technical safeguards

The Security Rule asks for access controls, audit controls, integrity controls, person or entity authentication, and transmission security. Each has a direct MCP counterpart.

Access control and authentication. Each user’s AI client should authenticate as that user, with OAuth scopes limited to their role. A shared API key in a team config file fails both requirements: everyone is the same identity, and nobody can be individually removed.

Audit controls. You must be able to record and examine activity in systems that hold ePHI. When the activity is an AI agent calling tools, the record has to exist somewhere central. Per-employee client logs scattered across laptops are not an audit control. A gateway that logs every call with user, client, tool, arguments, outcome and timestamp is. The observability post covers what that log should contain.

Integrity. Write tools can alter records. Retries can duplicate actions, and an injected instruction can alter the wrong one. Keep write tools behind approval where the record matters, and log the full arguments so a change can be traced.

Transmission security. Remote MCP servers over HTTPS cover the wire. What they don’t cover is a local server run with npx on an employee’s machine, which has the user’s file system and environment and no transport boundary at all.

Breach notification, and the log you’ll need

If PHI is disclosed to a party without authorisation, the Breach Notification Rule kicks in, and the first question is scope: which records, how many individuals. If an injected instruction caused an AI client to send patient data to an external URL, you can answer that question only if the tool call that did it was logged with its arguments. If it wasn’t, the conservative answer is “everything the client had access to”, and that is the number you report.

That asymmetry is the strongest practical argument for routing every AI tool call through one logged endpoint before connecting anything that touches PHI.

What to do about filtering

Response-side PHI redaction is attractive and is a reasonable extra layer. It is not a way to avoid the BAA question, because a filter that misses one field has still disclosed PHI, and clinical free text is exactly where filters miss. Treat redaction as reducing exposure on reads you have already decided are necessary, not as making a non-covered vendor acceptable. More in the PII filtering post.

Where gate fits, and where it doesn’t: gate gives you the chokepoint: one gateway URL per workspace, servers scanned and approved centrally, per-tool allow, ask, or block rules per team and per client, and a complete attributable log of every call with an export for audits. That is the access control and audit control side of the Security Rule. gate does not currently offer a BAA, and it does not redact responses, so for PHI workloads it belongs behind your covered systems with a model provider that does offer one. We would rather state that boundary than imply otherwise.

A sequence that works

  1. Inventory every MCP server any employee has connected. Mark which touch PHI.
  2. For each PHI-touching link in the chain (server, client, model, write destinations), confirm a BAA. Disconnect what isn’t covered.
  3. Restrict tools per role to the minimum necessary. Block bulk reads and outbound sends for AI clients.
  4. Replace shared keys with per-user OAuth. Make revocation a single action.
  5. Route all AI tool calls through one logged endpoint before the first PHI tool goes live.
  6. Add redaction as a second layer once the first five are in place.

HIPAA does not prohibit connecting AI to clinical systems. It prohibits doing it without knowing who received what. MCP makes the first easy and the second hard, unless you build the chokepoint first.