MCP Server Security for Healthcare: HIPAA, PHI Protection, and Agentic AI Tool Access

Why MCP servers are a HIPAA problem

HIPAA's Security Rule applies to Electronic Protected Health Information (ePHI) — any individually identifiable health information stored or transmitted electronically. The rule was written in an era of database servers and web applications. It predates large language models, tool-calling agents, and the Model Context Protocol entirely.

But the law does not care about the vintage of the technology. If a system stores, transmits, or handles ePHI on behalf of a Covered Entity, it is a Business Associate under 45 CFR 160.103, and HIPAA's Technical Safeguards at 45 CFR 164.312 apply to it in full.

An MCP server that exposes a tool like get_patient_record(mrn: string), query_ehr(patient_id: string, date_range: object), or search_clinical_notes(patient: string, keywords: string[]) is — by definition — handling ePHI. The tool arguments contain PHI. The tool responses contain PHI. The server's logs, if they capture arguments, contain PHI. Its in-memory state during a call contains PHI.

The PHI-in-tool-arguments problem

Standard MCP server implementations inherit from whatever logging framework is standard for their language ecosystem. In Node.js, that typically means console.log or a structured logger like Winston or Pino, both of which by default will serialize and log the entire request context — including tool call arguments.

The result is that a tool call like:

...will write patient identifiers (MRNs, names, DOBs, procedure codes) to whatever the default log sink is — often a container stdout that flows to a central logging service with no PHI handling controls, no encryption at rest, and no 6-year retention management.

This is not a theoretical risk. In our scan of the SkillAudit corpus, 63% of MCP servers with database or API integration tools include request argument logging at info level or above. For servers in the healthcare domain specifically, that is a per-call PHI disclosure event.

HIPAA Technical Safeguards: what applies to MCP servers

45 CFR 164.312 specifies five categories of Technical Safeguards. Here is how each maps to MCP server architecture:

The minimum necessary standard and MCP tool design

45 CFR 164.514(d) — the "minimum necessary" standard — requires that covered entities limit uses and disclosures of PHI to the minimum amount necessary to accomplish the intended purpose. This creates a direct design constraint on MCP tool interfaces.

A tool like get_patient_record(patient_id) that returns the entire patient record — demographics, visit history, medications, billing data, social history — when the calling agent only needs the most recent HbA1c result is not minimum-necessary compliant, even if the agent discards the rest of the response before sending it to the LLM context.

The reason: PHI was accessed beyond the minimum necessary scope. The EHR system logged a full-record access. The MCP server received a full-record response. The agentic system had an ephemeral window where PHI was in memory. Each of those events is a disclosure.

Minimum-necessary-compliant MCP tool design looks like this:

• → Tools expose specific clinical data elements, not whole-record retrieval (e.g., get_latest_lab_result(patient_id, loinc_code) not get_patient_record(patient_id))
• → Tool arguments do not accept patient identifiers directly — they accept access tokens or session references that the EHR resolves to a patient in a server-side context, preventing PHI in argument logs
• → Tool responses include only the fields specified in the request, not the upstream API's full response payload
• → Bulk or population-level queries require separate authorization (not auto-granted from single-patient access permissions)
• → The tool's schema documentation declares exactly what PHI it accesses and returns, enabling a covered entity's HIPAA officer to review and approve each tool before deployment

Audit logging requirements in practice

164.312(b) is the requirement teams most often underbuild. The OCR (Office for Civil Rights) in its audit guidance specifies that compliant audit logs must support answering: who accessed what PHI, when, from where, and with what result?

For MCP servers, this means every tool call must emit a structured audit event — separate from the application log — containing:

Critical: the resource_id field must not contain the raw patient MRN or SSN. Audit logs are long-retained (minimum 6 years) and the PHI inside them creates their own compliance surface. Use a tokenized patient reference that can be resolved back to the MRN only by an authorized administrator with access to the token map.

Application logs — where the MCP framework logs tool call arguments for debugging — must be either scrubbed of PHI before writing or restricted to a separate, PHI-classified log pipeline with its own access controls, encryption, and retention management. Running the same logging pipeline for debug logs and HIPAA audit logs is a compliance gap.

Access control: per-user authorization at the MCP layer

HIPAA's access control standard requires that each user have only the access they need for their role. In healthcare AI deployments, this is complicated by the agentic model: the LLM makes the tool call, not the human user — yet the access must still be scoped to the human user's authorization.

The correct implementation pattern is:

1. The human user authenticates to the agent application using their SSO/IdP credentials (SAML, OIDC).
2. The agent application exchanges that assertion for a short-lived, scoped access token bound to the specific user and their clinical role.
3. Every MCP tool call from that agent session includes the user-bound token in the Authorization header.
4. The MCP server validates the token on every call (not just at session start — see checklist item #1), extracts the user and role claims, and checks those claims against the tool being called.
5. The EHR API call is made with the user-specific token, not a service account credential.

This ensures the EHR's own access controls (RBAC, break-the-glass policies, care team restrictions) remain in effect even when access comes via an AI agent. A hospitalist agent should not be able to access psychiatry notes any more than the hospitalist human user can.

Many community MCP servers for EHR integration use a static API key for all calls — a single credential stored in environment variables that grants broad access regardless of who the calling user is. This is not HIPAA-compliant for multi-user deployments. It is also exactly what our secrets management audit flags as a credential hygiene failure.

Encryption requirements

HIPAA requires encryption of ePHI at rest and in transit. For MCP servers:

Breach notification and MCP tool calls

HIPAA's Breach Notification Rule (45 CFR 164.400–414) requires Covered Entities and Business Associates to notify affected individuals, HHS, and sometimes the media within 60 days of discovering a breach of unsecured PHI.

For MCP servers, the most likely breach scenarios are:

Prompt injection leading to PHI disclosure. An attacker-controlled document in the agent's context contains an injection payload that causes the LLM to call an MCP tool with a different patient's identifier than intended, or to exfiltrate a PHI-containing tool response to an external URL. This is a HIPAA breach. It is also the scenario our prompt injection post covers in depth.

Log exfiltration. Application logs containing PHI in tool call arguments are exfiltrated (through misconfigured S3 bucket ACLs, exposed Elasticsearch clusters, or compromised log aggregation credentials). If the logs contain PHI and they reach an unauthorized party, it is a breach — regardless of whether the MCP server itself was compromised.

Credential compromise leading to bulk PHI access. If the static API key used by an MCP server for EHR access is leaked (through a public git commit, an exposed environment variable, a misconfigured secret manager), an attacker can call the EHR API directly without going through the MCP server. The MCP server's access controls are irrelevant if the underlying credentials are exposed.

Unauthorized agent access. Multi-tenant agent deployments where user A's agent can call tools on user B's behalf — a scope validation failure — constitute a breach of user B's PHI even if both users are patients at the same institution.

What a HIPAA-compliant MCP server looks like

Combining the above requirements, a HIPAA-compliant MCP server for healthcare must implement:

• ✓ Per-call authentication. Every tool invocation validates a user-bound, short-lived token. No shared service accounts for multi-user deployments.
• ✓ Role-based tool authorization. Each tool declares the minimum clinical role required (e.g., "licensed_clinician", "care_team_member", "billing_admin"). Token claims are checked against role requirements before the tool executes.
• ✓ PHI-free argument logging. Structured logging does not capture patient identifiers, dates of birth, clinical data elements. Debug-level logging of raw arguments is disabled in production.
• ✓ Separate HIPAA audit event stream. A dedicated, append-only audit pipeline logs each PHI access with tokenized patient reference, user ID, tool name, timestamp, and outcome. Log access is role-restricted.
• ✓ Minimum-necessary tool interfaces. Tools return only the data elements the tool schema declares, not the full upstream API response.
• ✓ TLS everywhere. All transport layers enforce TLS 1.2+. Certificate validation is not bypassed for any host, including internal EHR endpoints.
• ✓ Encryption at rest for all PHI stores. Caches, temp files, audit logs, and backups use encryption with key management outside the application.
• ✓ Prompt injection defenses. Tool argument validation rejects anomalous patterns before passing to the EHR API. Response filtering prevents PHI from being included in error messages that propagate back to the LLM context unnecessarily.
• ✓ BAA and contractual HIPAA compliance statement. The server vendor can provide a signed BAA and has internal policies (workforce training, designated security officer) that satisfy HIPAA's Administrative Safeguards.

What SkillAudit flags in healthcare MCP server audits

SkillAudit's automated scan cannot verify organizational safeguards (workforce training, BAA existence, incident response procedures) — those require a manual assessment. But the automated scan detects the technical signals that indicate HIPAA-relevant risk:

• Credential exposure axis: API keys or tokens in source code, environment variable names suggesting PHI-related credentials (EHR_API_KEY, FHIR_TOKEN, EPIC_CLIENT_SECRET)
• Security axis: Disabled TLS verification (rejectUnauthorized: false, verify=False), HTTP URLs in upstream EHR API configuration
• Permissions hygiene axis: No per-call authentication logic, shared credential patterns, missing scope validation
• Observability axis: Argument logging at info/debug level without obvious PHI redaction, missing structured logging setup
• Maintenance axis: Outdated dependencies with known CVEs in healthcare-relevant packages (HL7.js, node-fhir-client)

An MCP server with F or D grades in any of these axes is not ready for healthcare deployment. C-grade servers require manual review to determine whether the flagged patterns actually handle PHI or are confined to non-PHI data paths. A-grade servers are the starting point for a healthcare HIPAA review — they still require the organizational safeguards layer, but they clear the basic technical hurdles.

Healthcare organizations evaluating AI vendor MCP servers should request a SkillAudit report as part of the BAA due-diligence process. The automated report does not replace a full HIPAA risk analysis, but it surfaces the issues that would turn a clean vendor assessment into a compliance finding before the server reaches production.