Model Context Protocol Security in Healthcare AI Deployments
MCP introduces attack surfaces that traditional API security models do not fully address: dynamic runtime tool discovery, natural-language tool descriptions interpreted by the AI model, and credential relay across proxy MCP servers. Securing MCP-based clinical deployments requires audience-restricted tokens, allowlisted registries, per-invocation re-validation, and tool-call-level audit logging, in addition to standard HIPAA-aligned access controls.
What Model Context Protocol Is
Model Context Protocol (MCP) is an open standard, introduced by Anthropic, that defines how AI applications connect to external tools, data sources, and prompt templates through a host-client-server architecture. In this model, a host application uses a protocol client to communicate with one or more MCP servers. Each server exposes tools as executable functions, resources as data sources, and prompts as templated interactions that an AI agent can invoke during a session.
In healthcare deployments, MCP servers commonly sit in front of EHR query functions, clinical documentation tools, lab result interfaces, and scheduling systems. Because MCP standardizes how these connections are described and invoked, it has become a common integration layer for clinical AI systems that go beyond a single chat interface and instead let an AI agent act on external systems.
Why MCP Security Differs From Traditional API Security
Conventional API security assumes a fixed, known set of endpoints that can be secured through authentication, authorization, rate limiting, and schema validation at a defined perimeter. MCP breaks this assumption in two structural ways.
First, MCP supports dynamic runtime discovery of tools and servers, meaning the set of tools available to an AI agent is not fixed at deployment time and can change during operation. Second, tool descriptions are natural-language text that the AI model interprets to decide which tool to invoke and how. Conventional schema validation checks the shape of a request; it does not address manipulation of the semantic content the model relies on when selecting and calling a tool.
These two properties mean MCP security must be evaluated at each boundary in the host-client-server chain, not only at the outer API perimeter. A tool description, a resource definition, or a proxy server relaying credentials can each become an attack surface that a standard API gateway was never designed to inspect.
MCP-Specific Attack Surfaces in Clinical Deployments
The table below summarizes the four primary MCP attack surfaces that platform teams need to account for in clinical environments.
| Risk Area | Description | Clinical Relevance |
|---|---|---|
| Confused Deputy | Proxy MCP servers relaying credentials across multiple downstream clinical systems on behalf of the requesting agent. | Credentials scoped to one system can inadvertently authorize actions against a different clinical data store. |
| Token Passthrough | Servers accepting access tokens not issued specifically for them, allowing a token to be used beyond its intended scope. | A token intended for read access to lab results could be relayed to a system with write access to clinical orders. |
| Tool Poisoning | Malicious instructions embedded in tool metadata (descriptions, schemas) that the AI model reads but the end user never sees. | An agent may be directed by hidden tool instructions to exfiltrate PHI or perform unauthorized clinical actions. |
| Session Hijacking | Predictable or improperly secured MCP session identifiers that allow an attacker to take over an established agent session. | A hijacked session gives an attacker the full tool-call permissions of the legitimate clinical user. |
Note on disclosure history
No healthcare-sector-specific MCP vulnerability disclosures were identified for the past year. The risks described here reflect general MCP protocol guidance applied to clinical tool-call scenarios.
Healthcare-Specific Implications
When a tool call through an MCP server accesses or transmits protected health information, it falls under the same HIPAA obligations as any other system handling PHI, even though MCP is a newer integration layer. Audit logging and access-control review that already apply to EHR interfaces and API integrations need to extend specifically to MCP tool-call traffic, since this traffic can move PHI outside conventional API monitoring if it is not explicitly captured.
Vendor risk assessment and business associate agreement (BAA) processes also need to extend to MCP server operators. A dynamically discovered MCP server introduces a new party in the data flow that may not have been evaluated through existing vendor onboarding.
Later revisions of the MCP specification incorporated OAuth 2.1-based authorization flows, which provide a foundation for access control. However, the protocol does not enforce audience restriction by default. Organizations must implement that scoping themselves rather than assume it is handled at the protocol level.
Technical Controls for Tool-Call Governance
The following controls address the specific attack surfaces MCP introduces. They are intended to complement, not replace, existing HIPAA-aligned access controls.
- Issue per-server, audience-restricted access tokens instead of reusing one credential across multiple MCP servers.
- Re-validate tool descriptions and schemas at each invocation rather than trusting a one-time user approval, to catch rug-pull style changes to tool behavior.
- Allowlist approved MCP servers and tools for production clinical environments rather than permitting open dynamic discovery.
- Log full tool-call transactions, including server identity, request parameters, and response data, separately from standard API logs.
- Network-isolate or process-isolate MCP servers handling clinical data from general-purpose or third-party MCP servers to limit the blast radius of a compromised server.
Implementation priority
Audience-restricted tokens and tool-call audit logging are the highest-priority controls for teams beginning an MCP security program. Dynamic discovery should remain disabled in production until an allowlist registry is in place.
Risk Area Summary
The four primary risk areas and their recommended mitigations at a glance:
Confused Deputy
Mitigate with per-downstream-system credential scoping. Proxy MCP servers must not be permitted to forward credentials beyond the explicitly authorized target.
Token Passthrough
Enforce audience claims in all access tokens. MCP servers should reject tokens not issued specifically for them.
Tool Poisoning
Re-validate tool metadata on every invocation. Human-readable tool descriptions should be reviewed during onboarding and monitored for changes at runtime.
Session Hijacking
Use cryptographically random session identifiers and bind sessions to authenticated user context. Rotate session tokens on privilege changes.
Frequently Asked Questions
Does HIPAA apply to MCP tool-call traffic?
Yes. If a tool call accesses, transmits, or processes protected health information, HIPAA requirements apply regardless of the integration layer. MCP is not exempt from PHI handling obligations simply because it is a newer protocol.
Does the MCP specification enforce audience restriction on tokens?
Not by default. Later revisions of MCP incorporated OAuth 2.1-based authorization flows, but audience restriction must be configured and enforced by the implementing organization. It is not guaranteed at the protocol level.
Can existing API gateways monitor MCP traffic?
Standard API gateways can inspect request shapes but are not designed to evaluate the semantic content of natural-language tool descriptions, which is where tool-poisoning attacks occur. Dedicated MCP-aware controls are needed to address that attack surface.
Should dynamic MCP server discovery be used in production clinical environments?
No. Dynamic discovery should be disabled until an allowlist registry is established and approved servers have been evaluated through your vendor risk and BAA onboarding process.
Do MCP server operators need a business associate agreement?
If a third-party MCP server operator handles PHI in the course of providing services, a BAA is required under HIPAA. The dynamic discovery property of MCP means new server operators can enter the data flow without going through standard onboarding, making registry controls essential.
Govern MCP Tool Calls Before They Reach Clinical Systems
Trussed AI provides runtime governance for AI agents, including agent identity, least-privilege permissions, tool approval workflows, and audit logging for tool-call activity across MCP-connected systems.
Explore MCP Security