Skip to main content
If you run a clinical chatbot, a prior-authorization agent, or any LLM workflow that touches Protected Health Information, the question isn’t “is my model HIPAA-certified” — no model is. The question is whether the data plane between your app and the model can keep PHI from leaking into prompts, responses, logs, and outbound tool calls. That’s what the HIPAA pack gives you: a set of gateway controls mapped to the HIPAA Security and Privacy Rule, installed in one call, producing signed evidence — with one boundary stated plainly up front.
The Business Associate Agreement is your organization’s responsibility, not a control the gateway can enforce. OrcaRouter can redact PHI, audit access, and sign evidence — but a BAA is a contract between covered entities and their business associates, and the pack discloses it as an organizational control you attest to, never as automated coverage. See the boundary below.

​
1. What “hipaa ai” governance means on the gateway

The HIPAA pack (hipaa) maps clauses of the HIPAA Security & Privacy Rule to live gateway controls. Like every compliance pack, installing it materializes real, editable Guardrail and Firewall policies in your workspace — it does not add a new runtime engine. Four enforceable controls do the PHI work:
hipaa.phi_redaction (45 CFR §164.502(b), Minimum Necessary) blocks US healthcare identifiers — NPI numbers, ICD-10 codes, NDC drug codes, DEA registration numbers — before they reach the model. The patterns are context-anchored (the literal NPI, ICD, NDC, or DEA token must be present) to bound false positives.
hipaa.pii_safeguards (45 CFR §164.514(b), De-identification) hard-blocks the contact-and-identity entities that overlap the HIPAA identifier set — email, phone, SSN, credit-card, and IP — so a request carrying them never reaches the provider. It ships off by default, so you can switch it to mask instead of block once you’ve reviewed your traffic.
hipaa.audit_logging (45 CFR §164.312(b), Audit controls) records every guardrail decision so the report can show what fired, how often, and where.
hipaa.transmission_security (45 CFR §164.312(e)) is a firewall egress rule that denies tool calls bound for loopback, link-local / cloud-metadata, and private (RFC-1918 / ULA) ranges — IPv4 and IPv6 — so a tool can’t quietly ship PHI to an internal exfiltration endpoint.
The first three controls live on the content plane (Guardrails); the fourth lives on the tool-call plane (Firewall). Install merges them into one guardrail and one firewall policy you own and can tune.
Two more controls ship in the pack — workforce security training (45 CFR §164.308(a)(5)) and Business Associate Agreements (§164.308(b)(1)) — but they’re marked organizational: people-and-process clauses a proxy can never enforce. The report discloses them as attested or as gaps, not as automated coverage. The honesty is the point.

​
2. Install the HIPAA pack — one concrete example

Compliance configuration uses your console session, never a relay sk-orca-… key. Browsing the catalog and checking readiness are free for any workspace Member; installing is a workspace Admin action on a paid plan, server-gated both ways.
1

Open the HIPAA pack

In the workspace console, go to Compliance → Catalog and open HIPAA (it lives under the healthcare category). Each control lists its plane, its clause, and a deep link to the official eCFR section.
2

Install in observe mode

As workspace Admin on a paid plan, click Install. The pack materializes immediately in observe mode — the guardrail flags instead of blocking, the firewall runs in shadow — so you collect “would-have-blocked” evidence against real traffic first.
3

Watch, then go live

Let the shadow controls accumulate matches, review them, then take the pack live to switch the declared block / mask / deny actions on. See Observe vs enforce.
The console drives one endpoint under your Admin session token — shown here so you can audit or script it, not as something you call with a relay key: 
POST /api/compliance/packs/hipaa/install
Authorization: Bearer <your-console-session-token>
Content-Type: application/json

{ }
An empty body installs every control in the pack. The response is the install record — the pinned version, mode: observe, and the guardrail_id and firewall_policy_id of the two materialized policies so you can open them straight away.
Because install produces standard guardrail and firewall objects, you can attach the materialized firewall policy to an agent key by firewall_policy_id and tune the PHI guardrail rule-by-rule — exactly like a policy you authored by hand.

​
3. The honest boundary — BAA is yours

A HIPAA program is more than a redaction filter. The gateway covers the controls a data plane can actually enforce; everything else stays with your organization. Here’s the split, drawn the same way as the shared-responsibility map:
Control areaGateway enforcesYour organization owns
PHI in trafficBlock / mask identifiers in prompts, outputsClassifying which fields are PHI
Tool egressDeny exfiltration to private / metadata rangesSecuring tools that bypass the gateway
Audit trailSigned record of every guardrail and firewall decisionReviewing it; setting retention
BAA & workforce— (disclosed as attested / gap)The signed BAA; training; sanctions
The gateway is the audited path, not a kernel-level interceptor. A tool your agent runs entirely in-process — one that never crosses https://api.orcarouter.ai and never reports an egress destination — is outside the firewall’s view. Route PHI-touching tools and MCP calls through the gateway (via the Firewall MCP gateway) so the egress control can see them, or secure them yourself at the infrastructure layer.

​
4. Prove it — signed, region-stamped evidence

Once the pack is live, generate a HIPAA report. Reports are Ed25519-signed and SHA-256-stamped, exportable as CSV / JSON / PDF, and publicly verifiable — an auditor can confirm a report’s authenticity without a login. Each row traces a clause down to the exact guardrail or firewall policy enforcing it and the matches it produced over the period; the two organizational controls render as disclosed gaps or owner attestations. You also declare a data-residency region for the report artifact (us / eu / uk / ap / cn / global) — signed reports are stored and served only under your declared region, and a cross-region read is withheld. For a US covered entity, set us. This stamps the evidence artifact, not the geography of inference.
Report generation, going live, and setting residency are workspace Admin actions on a paid plan, enforced server-side. Browsing the catalog and checking readiness stay free. See Plan gating.

​
5. Where to go next

Install a pack

The full install flow — control selection, observe mode, and go-live.

Signed report

What the Ed25519-signed HIPAA evidence report contains.

Verify a report

How an auditor confirms a report is authentic without a login.

Data residency

Declaring the region your signed evidence is stored and served under.

Guardrails reference

The content plane the pack materializes — PII entities, masking, actions.

Data exfiltration

The threat the egress control defends against.
The HIPAA pack turns the Security and Privacy Rule into PHI redaction, egress denial, and signed evidence you can hand an auditor — while saying plainly that the BAA, training, and your own infrastructure stay yours. For the rest of the catalog, see Frameworks.