Agentic systems operating in healthcare environments handle Protected Health Information through a longer chain of touchpoints than traditional applications. PHI enters as part of a goal, gets embedded in planning prompts, gets passed between specialist agents, gets included in tool call arguments, gets stored in memory across workflow steps, and sometimes ends up in model provider logs. Every touchpoint is a potential breach. The patterns below describe how we close them.
These patterns assume HIPAA-covered entities deploying agentic systems for clinical, administrative, or member-facing workflows. They are equally applicable to PHI-equivalent data under DPDPA, UAE PDPL, and NHS DSPT scope, with minor adjustments for jurisdictional specifics.
Pattern 1: Pre-Execution Classification
Every input entering an agentic workflow must be classified for sensitivity before the planner runs. PHI is not a property of the data's appearance: a clinical note and a marketing email may both be strings, but they receive different downstream handling. Classification at the input boundary tags each field with a sensitivity label that propagates through the workflow.
The classification taxonomy must distinguish at minimum: PHI (subject to HIPAA), PII (subject to general privacy obligations), de-identified data (Safe Harbor or Expert Determination compliant), and reference data (not subject to privacy obligations). Workflows that combine data classes must propagate the union of the constituent classes. A document that started as de-identified but had an identifying field added becomes PHI for the rest of its lifetime.
Pattern 2: Tool-Adapter Boundary Enforcement
The agent cannot decide what to do with PHI. The tool adapter decides. Every tool call passes through an adapter that inspects the classification of the inputs, looks up the tool's allowed sensitivity scope, and either permits the call, redacts the inputs before forwarding, or blocks the call entirely. The adapter, not the agent, is the policy enforcement point.
A tool that calls an external model provider must have a current Business Associate Agreement with that provider. The adapter for that tool verifies the BAA status at call time; tools without BAA status reject PHI inputs. An agent attempting to summarize a clinical note via a non-BAA model provider gets a blocked tool call and an explanation, not a quiet success.
Pattern 3: Minimum-Necessary Memory
Agentic systems accumulate state across workflow steps. PHI in agent memory is governed by HIPAA's minimum necessary standard: the system retains only the PHI needed for the current step, not the full conversation history. Memory architectures for healthcare agents implement TTL-bounded stores with explicit per-field retention rules.
A patient's diagnosis may be retained for the duration of the workflow; a patient's social security number is retained only for the verification step in which it is required and is cleared afterward. The agent's memory interface enforces this without requiring agent-side discipline. The agent cannot accidentally retain PHI that the architecture has decided should expire.
Pattern 4: Output Validation
Tool outputs are validated against the classification of their inputs. A tool that received PHI cannot return data the system treats as non-PHI. A summarization tool that processes a clinical note returns output classified as PHI by default. The validator at the output boundary catches violations.
This pattern catches a subtle failure mode: a tool that legitimately should produce de-identified output (a statistics tool that returns counts and aggregates) must declare this and verify that its output passes a de-identification check. Tools that handle PHI inputs and produce purportedly non-PHI outputs are a leading cause of HIPAA breach notifications for AI-assisted workflows.
Pattern 5: Cross-Border Routing
PHI data residency requirements vary by jurisdiction. UAE PDPL requires data subject identifiers to remain in-country in many cases. China PIPL imposes cross-border transfer restrictions. EU GDPR Article 46 governs transfers outside the EEA. Healthcare agents serving multi-jurisdictional populations must route tool calls and storage based on the data subject's jurisdiction, not the agent's deployment location.
The routing decision is made at the adapter layer based on the input's jurisdictional tag. Tools serving EU subjects use EU-region model endpoints and EU-region storage. The agent does not choose; the policy does. Cross-jurisdiction workflows are explicitly approved with documented legal basis (Adequacy Decision, Standard Contractual Clauses, Binding Corporate Rules).
Pattern 6: Audit-Log Hygiene
PHI in audit logs is a common HIPAA breach vector. Audit logs are retained for years and accessed by personnel who may not have clinical justification. The reference architecture hashes PHI identifiers in audit logs and stores the hash-to-PHI mapping in a separately access-controlled compliance store. Reconstructing a specific patient's workflow requires authorized access to the mapping store; routine audit operations work on the hashed identifiers.
This pattern provides audit-trail completeness (we can reconstruct what happened) without expanding the PHI access surface (the routine audit operator does not see clinical content). It is the operational realization of HIPAA's separation between treatment, payment, and operations: the audit operator is performing operations, not treatment, so does not need the clinical detail to do their job.
Pattern 7: Re-Identification Risk Management
Workflows that process de-identified data still carry re-identification risk. Quasi-identifiers (age range, ZIP-3, diagnosis) in combination can re-identify individuals with high probability, especially in small populations. Agentic systems that aggregate across patients are particularly susceptible because the LLM may surface combinations a human analyst would recognize as identifying.
The architectural response is a re-identification risk monitor at the output boundary for any workflow processing de-identified inputs. The monitor evaluates outputs against population statistics and flags outputs that approach re-identification thresholds. Flagged outputs are routed through compliance review before release.
Pattern 8: Incident Response Integration
HIPAA's Breach Notification Rule imposes specific timelines for breach assessment and notification. Agentic system incidents (an unintended PHI disclosure through a hallucinated tool call, a misclassified output, a jurisdiction routing failure) must be detected and assessed within those timelines. The reference architecture instruments every PHI touchpoint with detection rules that fire on policy violations.
Detected violations are routed to the incident response team with the full workflow audit packet attached. The packet contains the evidence needed for breach assessment under 45 CFR 164.402: what data was involved, who accessed it, when, under what authority. Without this packet, the breach assessment can take days or weeks; with it, the assessment is a structured review of a complete record.
The Engineering Bar
HIPAA-grade agentic systems are not built by adding PHI handling rules to a general-purpose agent. They are built by treating PHI as a first-class architectural concern from the input boundary to the output boundary, with policy enforcement at the tool adapter and audit-trail completeness at every touchpoint. Systems built the other way are remediated in production after the first incident, at substantial cost.
The engineering behind this article is available as a service.
We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.