How should healthcare teams secure AI agents and MCP servers without exposing PHI to the network?

Healthcare teams should treat AI agents and MCP servers like any other PHI-touching system: assume the network is hostile, then remove unnecessary reachability. A Zero Trust design makes the workload unreachable from the internet, authenticates each session, and authorizes access before data moves. That reduces exposure from open ports, weak perimeter controls, and over-permissioned access paths.

How Zero Trust Changes the Exposure Model for AI Agents and MCP Servers

The practical shift is to treat the agent and its MCP server as a constrained workload boundary, not as a service that can safely sit on a reachable network segment. The goal is to make the server reachable only through authenticated, policy-checked paths, with no direct exposure to patient data flows or broad lateral access.

That means the design should assume every request is untrusted until the caller, the session and the requested action are verified. For MCP, the authorization model should be explicit and token scope should be narrow enough that the server cannot become a generic data relay.

In practice, this is where Zero Trust becomes operational rather than aspirational. Zero Trust for AI Agents is useful because it frames the problem as continuous verification and removal of standing privilege, which is the right lens when the workload itself can initiate tool calls or data access.

What Healthcare Teams Must Control Before PHI Can Move

The first control point is reachability. If the MCP server is internet-facing or broadly routable inside the environment, PHI exposure is no longer just a data-handling issue, it becomes a network exposure issue. The safer pattern is private connectivity, tight segmentation and a small set of approved ingress paths that can be monitored and revoked quickly.

The second control point is authorization at the action level. An agent should not inherit blanket access because it is “trusted” once connected. It should receive only the permissions needed for the current task, and those permissions should expire as soon as the task is complete. The AI Agent Authorisation Guide is directly relevant here because it focuses on task-scoped access, delegated authority and per-action policy decisions.

The third control point is how the MCP server handles identity material and downstream requests. MCP Security Guide is useful because it addresses OAuth-based authorization, token passthrough, tool poisoning and local server credentials, all of which can turn a well-meaning integration into a PHI leakage path if they are left implicit.

For healthcare, the operational question is not whether the agent can technically reach a database or API. It is whether the system can prove that the caller, the purpose and the data path were all authorized before any PHI was revealed. If that cannot be proven, the architecture is still too permissive.

Why MCP and Agent Identity Need Separate Guardrails

MCP servers and AI agents often fail in different ways, so they need separate guardrails even when they are deployed together. The server needs a hardened authorization surface, while the agent needs strict limits on what it can request, chain or repeat. If those are merged into one coarse trust zone, the result is usually overreach, not convenience.

That separation matters because a compromised agent does not need direct database access to create harm. It can abuse tool calls, token scope or an over-broad connector and still move PHI out of approved boundaries. The safest pattern is to make the agent identity, the server identity and the data access policy independently enforceable.

Agentic AI Security Guide helps here because it treats agent tooling, orchestration and identity as separate attack surfaces. In parallel, NHI Authentication Guide is a strong reference when the question is how machine-to-machine authentication should be implemented without exposing long-lived secrets or weak bearer paths.

Risk and Threat Considerations

When AI agents and MCP servers can reach PHI-bearing systems through broad network paths, the main risk is not just unauthorized access, it is uncontrolled data movement. A single exposed port, overly permissive token or confused-deputy path can let an attacker or misconfigured agent pivot from a low-risk request into PHI retrieval, exfiltration or silent overcollection.

Failure mechanism: Excessive reachability plus weak session or token scoping allows a caller to invoke tools or APIs outside the intended task boundary, so PHI can be disclosed without any obvious perimeter alert.

Impact: PHI exposure can become systemic, because the same connector, token pattern or server configuration may be reused across multiple workflows, creating repeated loss events and difficult containment.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-4 — Information Flow Enforcement	Controls PHI movement between agent, server and data systems.
	IA-9 — Service Identification and Authentication	Covers machine-to-machine authentication for AI agents and MCP servers.
	AC-6 — Least Privilege	Limits tool and data access to the minimum needed for each agent action.
Recommendation — Enforce information-flow rules so PHI only moves through approved paths. Authenticate agent and server workloads before any PHI request is processed. Restrict each agent and MCP connector to the smallest necessary permissions.
NIST Zero Trust (SP 800-207)	PR.AA-03 — Continuous Verification	Matches the need to verify each session and request before data exposure.
	PR.AA-05 — Least Privilege Access	Supports removing standing privilege from AI agents and MCP paths.
Recommendation — Continuously verify the caller and request before releasing PHI. Remove standing privilege from agent and server access paths.
OWASP Agentic AI Top 10	ASI03 — Identity & Privilege Abuse	Agent privilege misuse is a direct risk when AI agents can reach PHI systems.
Recommendation — Constrain agent privileges so tool calls cannot exceed the approved task.
OWASP Non-Human Identity Top 10	NHI-04 — Insecure Authentication	Covers weak machine authentication patterns that expose MCP servers and PHI.
	NHI-07 — Long-Lived Secrets	PHI-touching agent paths are often exposed by durable tokens or credentials.
	NHI-05 — Overprivileged NHI	Agent and server identities should not carry broad access to PHI systems.
Recommendation — Use strong workload authentication instead of weak or reusable bearer access. Eliminate long-lived secrets from agent and MCP server access paths. Trim agent and MCP permissions to the minimum viable scope.
OWASP API Security Top 10	API2 — Broken Authentication	Applies when MCP or API access is weakly authenticated and can expose PHI.
Recommendation — Harden API authentication before allowing PHI-bearing requests.

Practitioner Guidance

What to prioritise: Put network segmentation and private-only reachability ahead of convenience features, because an agent that cannot be reached directly is far less likely to leak PHI through accidental routing or unreviewed integrations.

What to verify: Confirm that every agent-to-server call is authenticated, scoped to a single task or workflow, and logged with enough detail to reconstruct who requested what and why. If you cannot trace that path, the control is not yet trustworthy.

Decision rule: If an MCP server can return PHI, treat it like a production data service and require the same discipline you would apply to any sensitive application interface: least privilege, tight session scope and immediate revocation when access is no longer needed.

Practitioner takeaway: The safest healthcare pattern is to assume the agent and MCP server are already inside the trust boundary only after policy proves it, not before; if PHI can move without a fresh authorization decision, the design is still too open.