The 400 Is the Control: Reading Claude’s HIPAA Feature Eligibility as a Technical Safeguard You Can Prove

The Dispatch exists for one reader: the architect who has to stand an agentic system up in front of the people accountable for the trust it carries — the customer first, then the board, the auditor, the risk committee. Healthcare is where that burden is heaviest and most legible, because the boundary is written down. So this readout takes a narrow, concrete artifact — the list of features a HIPAA-enabled organization is allowed to use — and reads it the way an architect should: not as a menu of restrictions, but as a safeguard with a property most safeguards lack.

Two questions people conflate: ZDR and HIPAA

Start here, because almost everyone runs the two together, and the whole argument depends on keeping them apart.

Zero Data Retention is a setting. With it on, the vendor doesn’t persist the inputs you send or the outputs it returns; they’re discarded once the request completes. ZDR answers one question: is my data stored at all?

HIPAA readiness is a posture, not a setting. It requires a signed Business Associate Agreement — the BAA, the legal instrument that makes a vendor accountable for the PHI it handles — plus a dedicated, HIPAA-enabled organization that structurally enforces which features are allowed to touch that PHI [1]. It answers a different question: will the vendor contractually stand behind my PHI, and is the boundary actually enforced?

These used to travel together — handling PHI meant enabling ZDR. They are now decoupled, and on a first-party API organization they are mutually exclusive: HIPAA readiness and ZDR cannot coexist on a single organization, so an enterprise that needs both runs separate organization IDs [13]. The practical consequence is a sentence worth memorizing. “We have ZDR” does not mean “we’re HIPAA-ready,” and “we’re HIPAA-ready” does not mean “nothing is retained” — a HIPAA-enabled organization can still retain flagged material for a bounded period where law or policy enforcement requires it [1]. One is a storage property. The other is an accountability posture backed by a legal instrument and enforced at the feature layer. An architect who blurs them will mis-describe their own system to the auditor.

A safeguard you demonstrate, not one you document

Here is the property that makes the eligibility fence interesting.

The HIPAA Security Rule sorts safeguards into kinds. Administrative safeguards are policies and procedures — the risk analyses, the sanctions, the workforce training — the things an organization says it does [3]. Technical safeguards are controls implemented in the technology itself — access control, audit controls, integrity, transmission security — the things the system does whether or not anyone is watching [2]. An auditor treats these categories differently, because they fail differently. A policy fails silently: someone doesn’t follow it and no one notices until the breach. A technical control fails loudly, or not at all.

An enforced eligibility fence is a technical safeguard. In a HIPAA-enabled organization, a request that reaches for a non-eligible feature doesn’t get flagged for later review — it returns a 400, and the offending feature is named in the error [1]. That is the difference between should not and cannot. A policy says a non-eligible feature should not be invoked against PHI; the 400 demonstrates it cannot be. The first you attest to in a paragraph. The second you prove in a test — send the disallowed request, show the rejection, attach the transcript to the workpaper.

This is the whole argument in one mechanism. Assurance is not the absence of risk; it is the ability to show your work to someone entitled to doubt you. A control you can prove by construction is worth more, in front of a risk committee, than a stack of well-written policy you can only promise was followed.

The fence is a data-flow boundary

Read the eligible-versus-blocked split as a map of where PHI is allowed to go, and a pattern resolves immediately.

Inside the fence sits the inference path and a set of stateless or client-controlled tools: the core Messages API, token counting, web search, the memory tool that writes to storage you own, bash and text-editor tools that execute in your environment, PDFs passed inline, retrieval-augmented citations [1]. Outside the fence sits everything that necessarily persists state on the vendor’s side: the Files API, code execution, connectors to external tools, managed agents, agent skills, batch processing [1]. The dividing line is not arbitrary. Features are blocked precisely when they require server-side storage or an execution surface the BAA’s enforced boundary can’t cleanly contain.

What survives inside the fence is inference plus tools whose state you already control. That is not a limitation an architect works around. It is a design the architect adopts: keep orchestration and memory on your side of the line, and use the vendor for the one thing that has to cross it.

What the boundary buys you

Two concrete assurance gains follow, and both land where enforcement actually happens.

First, it shrinks the surface you have to attest to. The Security Rule’s required risk analysis is an accurate, thorough assessment of where ePHI lives and moves [3]. Every place PHI can flow is a place you must map, protect, and defend in an audit. A fence that structurally keeps PHI out of the stateful features removes those paths from the map before you draw it. Fewer flows, smaller attack surface, cleaner risk analysis — and risk analysis is the single most frequently cited deficiency in OCR investigations, so narrowing it is not cosmetic. It is the exact ground on which enforcement is decided.

Second, it expresses minimum-necessary as architecture. The Privacy Rule’s minimum-necessary standard requires that PHI exposure be held to what the task demands [5][6]. A boundary that routes PHI only to the inference path, and walls it off from the ancillary feature surface, enforces that principle at the platform layer rather than leaving it to a data-handling policy someone has to remember. The control and the principle become the same object.

De-identification is the upstream layer

This is where the architect’s own toolkit earns its place, and where an honest distinction has to be made rather than blurred.

The eligibility fence governs identified PHI processed under a BAA. Expert Determination is a different regulatory posture entirely: a qualified expert applies statistical and scientific principles and certifies that the risk of re-identifying an individual is very small — at which point the data is no longer PHI, and the Privacy Rule’s constraints, including the fence, no longer bind it [6][11]. These are not competing options. They are layers.

Stack them. De-identify upstream so the data crossing the boundary is already reduced-risk; let the vendor’s structural fence enforce the feature boundary on whatever does cross; let the BAA carry the residual accountability. Three independent controls, no single point of trust — if any one of them is later found wanting, the other two still stand. That is the posture an architect defends: not “the vendor promised,” but “the boundary is enforced, the data is de-identified before it reaches the boundary, and the contract covers what’s left.” Defense-in-depth stated as a design, not as a hope.

Know which entity holds the BAA

One detail decides your entire accountability chain, and it is easy to miss.

HIPAA readiness, as documented, applies to the Claude API at Anthropic’s own endpoint [1]. Deploy the same model through a hyperscaler’s managed service and the accountability chain moves: your BAA is with the cloud provider, and the model provider sits downstream in that provider’s chain of business-associate obligations [7]. The Security Rule and the BAA content requirements make this chain load-bearing — business associate contracts must flow obligations downstream, and breach-notification duties run along the same links [7][8]. So “which entity holds our BAA?” is not a procurement footnote. It determines who notifies whom on breach, where liability lands, and which compliance attestations you can actually rely on. Answer it before you architect on top of it, not after.

What the fence does not do

Assurance is also the discipline of naming your residuals out loud, so here are this design’s.

A HIPAA-enabled organization can still retain flagged inputs and outputs for a bounded period where required by law or to enforce usage policy — even under a BAA [1]. That retention has to be reconciled against the BAA’s permitted-uses clause, which enumerates exactly what the business associate may do with PHI [7]. This is not a gotcha; it is a clause to confirm sits inside permitted uses. Beta features are generally outside the eligible set unless explicitly named [1] — so an architecture that leans on a preview capability has to check its eligibility, not assume it.

Two configurations deserve naming, because architects reach for them by reflex. Claude Code is an Eligible Service under the BAA only with ZDR enabled — and ZDR blocks Covered Models, so Claude Code, a Covered Model, and PHI is not a reachable combination [13]. Cowork is not an Eligible Service under the BAA in any configuration, regardless of retention setting or model in use [13]. Neither is a defect. Both are boundaries you design around rather than discover, and the discovering is the expensive way.

And the documentation itself carries no legal standing: it describes a contractual and technical control, but the boundary is only enforceable because the BAA makes it so. The 400 is the mechanism; the BAA is what makes the mechanism mean something. Say that plainly, and the argument gets stronger, not weaker.

Covered Models and the retention price

The documentation answers a question a reader might expect this readout to leave open, and the answer is worth reading closely — because it is a trade-off, not a permission.

Covered Models are Anthropic’s designation for models whose capabilities warrant additional safeguards; Claude Fable 5 and Claude Mythos 5 currently carry it [14]. They require a 30-day minimum retention on every platform where they are offered, and they cannot be reached from an organization or workspace with Zero Data Retention enabled — a request to a Covered Model from a ZDR-enabled organization returns an error [13][14]. So the route to using them with PHI is the HIPAA-ready path, not the ZDR path. A HIPAA-ready API organization runs with standard retention, which is precisely why it can reach Covered Models, including Fable 5; Chat on a HIPAA-ready Enterprise plan does the same with no configuration change [13].

Read that as an architecture decision, not a footnote. The strictest storage posture and frontier capability against PHI are not available on the same organization. That is a coherent design rather than an oversight: the retention window is the substrate the safety case for these models is built on [14], and a model that cannot be reviewed across sessions cannot be defended across them either. But it is a decision the architect makes, not one the platform makes for them — and it should be made deliberately, with the risk analysis in hand.

Note also the shape of the enforcement. A ZDR organization does not merely discourage Covered Model use. The request errors [13]. That is the same mechanism as the 400, appearing a second time in a different corner of the platform: a boundary that announces itself at call time rather than in a policy binder. The pattern is not incidental to this Dispatch’s argument. It is the argument.

The direction of travel

Now the forward read, because an architecture is a bet on where the ground is moving.

The HIPAA Security Rule is under its first major revision since 2013. The Notice of Proposed Rulemaking published at 90 FR 898 on January 6, 2025 would eliminate the long-standing “addressable” designation — making every implementation specification required — and would write controls like encryption, multi-factor authentication, and network segmentation directly into the technical safeguards [12]. It remains proposed, not law — and the timeline has moved away, not closer. OCR’s projected Final Action date now stands at July 2027, roughly a year later than the May 2026 target it previously carried, and the rulemaking has been reclassified from the final-rule stage to long-term actions [15]. Cite it as direction, not as duty.

But the direction is the point, and the delay sharpens rather than softens it. The proposed rule collapses the era in which a well-argued paragraph could stand in for an implemented control — the era of documentation-as-defense [4][12]. What it moves toward is a world where controls are required, testable, and enforced. An enforced eligibility fence is already that kind of control. The slip changes the timeline, not the destination; architecture that treats structural enforcement as the default, rather than the exception, is positioned for where the rule is heading regardless of when it lands.

And because the rule is further off, the incentive that operates today carries more weight, not less. Under the recognized-security-practices amendment to the HITECH Act, OCR must take into account whether a regulated entity had recognized security practices in place for the prior twelve months when it determines penalties and audit outcomes [9]. NIST Special Publication 800-66 Revision 2 is the recognized guide for implementing the Security Rule [10]. Architecture aligned to it carries genuine penalty-mitigation weight — the closest thing HIPAA offers to a safe harbor, and one that is in force now rather than in 2027. Assurance, in other words, is not only defensible in front of the auditor. It is statutorily rewarded.

The boundary draws a box, and the architecture this readout implies lives inside it: running the agentic orchestration — memory, tools, retrieval — on your side of the line, so the conveniences given up inside the fence return under controls you own. The fence decides what crosses; the design decides what you keep.