Healthcare platform teams deploying AI agents face a particular constraint that other verticals can sometimes defer: the acceptable destinations for any outbound connection involving patient-adjacent data are a known, bounded set. This is not a performance optimization or a cost control. It is a requirement that flows from how healthcare data governance works in practice, where data flow maps are a standard artifact of security reviews and where "the agent can reach any URL" is a show-stopper in an assessment.
The practical challenge is that building a healthcare-compliant egress policy that does not break legitimate agent workflows requires more design work than simply applying a default-deny rule. Healthcare agents have real dependencies: they query FHIR-compliant APIs, they consult clinical terminology services (SNOMED, RxNorm), they retrieve drug interaction databases, they verify formulary information. Some of these are internal services; some are external. The egress policy needs to cover the full set while maintaining the default-deny posture that satisfies a security review.
The Policy Design Problem in Healthcare
Healthcare platform teams often run into a specific tension when first implementing egress controls for agents. The security team wants the policy to be restrictive; the engineering team knows that agents legitimately need to contact a variety of external services, and a policy that breaks those integrations creates pressure to loosen the restrictions.
The resolution is that a well-designed policy does not have to choose between security and functionality. The policy can be both default-deny and permissive enough to allow all legitimate workflows, because legitimate workflows in healthcare have a computable enumeration. The set of external services a properly scoped healthcare agent needs to contact is finite and documentable. The set of destinations a malicious exfiltration attempt needs to reach is not on that list.
The design methodology is: inventory first, policy second, then verify that the policy covers the inventory and blocks everything else. In that order, not reversed.
Building the Destination Inventory
The inventory phase is not optional and cannot be replaced by reading the documentation for the services your agents use. Documentation describes the intended behavior. Agents behave in ways that involve dependency libraries, telemetry SDKs, and framework components that the documentation does not mention.
Running in audit mode, with all outbound connections logged but none blocked, for at least two weeks under production workload conditions produces a ground-truth destination inventory. For a healthcare agent handling appointment scheduling, clinical documentation assistance, and medication queries, a realistic inventory includes the following categories:
Internal EHR APIs: typically on private network segments, accessed over HTTPS on standard ports. These are the core data sources and the ones most likely to carry PHI. The egress policy for these should specify both the hostname and the internal IP range, and should require HTTPS.
FHIR endpoint services: the R4 FHIR API endpoints used by the platform, whether self-hosted or managed. If using a managed FHIR service from a cloud provider, the specific endpoint hostname is known. If self-hosted, the internal address is known.
Clinical terminology APIs: NLM's UMLS REST API, SNOMED CT browser API, RxNorm API for drug normalization. These are publicly known endpoints with stable hostnames. Including them explicitly in the policy is straightforward.
LLM inference endpoints: the API endpoint for the language model the agent uses. For cloud-hosted models, this is the provider's API hostname. For self-hosted models on internal infrastructure, it is the internal address of the inference server.
Dependency and framework endpoints: this is the category that surprises teams most often. Python packages that check for updates, telemetry SDKs that report usage statistics, certificate revocation endpoints, time synchronization services. These are not related to the agent's application logic, but they appear in the outbound connection logs because the agent's runtime environment contacts them.
Structuring the Policy Layers
A flat list of allowed domains works for simple deployments but becomes difficult to maintain as the destination set grows. A layered policy structure is more maintainable and makes it easier to document the reasoning behind each entry.
egress:
default: deny
layers:
- name: ehr_core
description: "Internal EHR API tier - PHI in transit"
entries:
- host: "ehr-api.internal.healthsystem.local"
ports: [443]
protocol: https
ip_range: "10.2.0.0/16"
- name: clinical_terminology
description: "Public terminology services - no PHI"
entries:
- host: "rxnav.nlm.nih.gov"
ports: [443]
protocol: https
- host: "uts-ws.nlm.nih.gov"
ports: [443]
protocol: https
- name: llm_inference
description: "LLM API endpoint"
entries:
- host: "api.anthropic.com"
ports: [443]
protocol: https
deny_on_eval_error: trueThe layer structure serves an operational purpose: when a new integration is requested, the engineer adding the entry has to decide which layer it belongs to. The ehr_core layer requires security review before adding new entries because PHI may transit those connections. The clinical_terminology layer has a lower review bar because the services are public and the agent sends queries, not PHI. Making this classification explicit in the policy structure creates a natural audit trail of each addition decision.
The LLM Endpoint Question
One policy decision that comes up in every healthcare deployment is how to handle the LLM API endpoint. The agent sends patient context (possibly de-identified, possibly not) to the LLM for reasoning. From an egress policy perspective, the LLM endpoint is an external destination that receives data from the agent.
There are three approaches teams use. The first is to allow the cloud LLM endpoint and rely on the LLM provider's BAA (Business Associate Agreement) and data processing terms to cover the data handling obligations. This is the operationally simplest path but requires that the LLM provider is willing to sign a BAA for the specific use case, which varies by provider and use case type.
The second is to run an internal LLM inference service on healthcare-controlled infrastructure, so the LLM endpoint is an internal address and the data never leaves the controlled environment. This provides the strongest data governance posture but requires the infrastructure investment of running a self-hosted model.
The third, common in clinical decision support contexts where de-identification is already part of the workflow, is to de-identify the patient context before it reaches the LLM processing step, so what the agent sends to the LLM endpoint contains no PHI regardless of where that endpoint is. The egress control then applies to the de-identified data stream.
The egress policy needs to reflect whichever approach the platform team has chosen, and the policy entry for the LLM endpoint should be annotated with which approach applies and what the data handling basis is. This annotation is the answer to the security review question "what controls apply to data sent to this destination?"
Change Management for Policy Updates
An initial egress policy that passes a security review needs to remain in a reviewable state as the platform evolves. New agent capabilities, new integrations, and updated dependency packages all create pressure to add entries to the allowlist.
The operational hygiene that matters most is: every policy change goes through the same review process as the initial policy, with the same documentation of what destination is being added, which data flows to it, and what the data handling basis is. An egress policy that starts well-documented but accumulates undocumented entries over time is progressively harder to defend in subsequent reviews.
Automated drift detection, where the current running policy is compared against the version-controlled policy file on a schedule, catches manual edits that bypassed the review process. If the deployed policy diverges from the version-controlled policy, that is a signal that the review process was bypassed, not that the policy update was legitimate.
The version-controlled policy file is the single source of truth. Reviewing the deployed configuration without comparing it to the version-controlled file gives you an accurate picture of what is deployed but not whether what is deployed was intentional.