HIPAA-Compliant AI Agents: 7 Requirements You Can't Skip

Short answer: a healthcare AI agent that reads, writes, or transmits Protected Health Information (PHI) must satisfy seven HIPAA Security Rule requirements at the tool-call layer — access control, audit controls, integrity, transmission security, minimum necessary, person-or-entity authentication, and breach notification readiness. The compliance question isn’t can you, it’s how do you produce evidence the auditor will accept. This article maps each requirement to a concrete control AEGIS enforces.

What’s the scope question — is my agent a Covered Entity or Business Associate?

You’re a Covered Entity if you provide healthcare directly (hospital, clinic, provider). You’re a Business Associate if you process PHI on behalf of a Covered Entity (AI scribe vendor, telehealth platform, RCM SaaS).

Either way, if the agent touches PHI you’re subject to the HIPAA Security Rule. The difference matters for breach notification timing (CE 60 days, BA depends on BAA) but the controls are the same.

PHI definition is broader than people expect: “any individually identifiable health information transmitted or maintained in electronic form.” That includes:

• Patient name + condition in an email
• Patient ID + visit date in a database query
• Anything the agent retrieves from an EHR
• Anything the agent posts back to an EHR
• Anything the agent sends to a third-party LLM API (yes, your tool call body is PHI transmission)

The last bullet trips up everyone. An agent calling OpenAI with PHI in the prompt is HIPAA-regulated transmission, and OpenAI needs a BAA (which they offer on Enterprise plans). Most consumer-tier LLM API usage with PHI is non-compliant.

What are the 7 requirements that hit AI agents?

1. Access Control (§164.312(a)(1)) — Required

The agent must implement technical policies that allow only authorised users (or processes) access to PHI.

Agent-layer mapping: every agent has a unique identity. Each agent’s scope explicitly lists which PHI-touching tools it can call. The gateway enforces — if the agent’s LLM gets convinced to call ehr.read_patient(unauthorized_id), the gateway rejects with scope-violation before the call hits the EHR.

agent: clinical-scribe-agent
permitted_tools:
  - ehr.read_patient_notes      # scoped to current encounter
  - ehr.write_clinical_note
denied_tools_explicit:
  - ehr.read_patient_billing
  - ehr.read_family_history
  - ehr.export_full_record

The deny list is as important as the allow list — it documents what the agent can’t do, which is what HIPAA auditors look for.

2. Audit Controls (§164.312(b)) — Required

Implement hardware, software, and procedural mechanisms that record and examine activity in systems that contain or use PHI.

Agent-layer mapping: AEGIS’s cryptographic audit log ties every PHI access to a specific agent, a specific policy decision, and a specific timestamp. The Merkle anchoring means a future breach investigation can prove what was accessed without trusting the breached system.

HIPAA doesn’t specify how tamper-evidence is achieved — just that it’s there. The OCR (HHS Office for Civil Rights) has cited “logs that could have been edited after the fact” as a deficiency in breach settlements. Cryptographic audit is the strongest available answer.

3. Integrity (§164.312(c)(1)) — Required

Implement policies and procedures to protect PHI from improper alteration or destruction.

Agent-layer mapping: every PHI write (e.g. an agent updating a patient note) is gated by policy and logged. AEGIS’s policy consent-must-be-structured (from our indirect prompt injection article) is a concrete example — patient consent flags can only originate from structured consent forms, never from free-text the agent might be tricked into. This protects integrity of the PHI itself, not just the access log.

4. Person-or-Entity Authentication (§164.312(d)) — Required

Verify a person or entity seeking access is the one claimed.

Agent-layer mapping: every agent registers with a signed credential, rotated automatically. Service-to-service authentication, not “shared secret in a config file.” The credential is verified on every tool call; revocation propagates instantly.

For human-in-the-loop steps (the 2-of-N approval pattern for high-stakes actions), the human authenticates via your IdP (Okta / Google Workspace / Azure AD) and the approval lands in the audit log.

5. Transmission Security (§164.312(e)(1)) — Required

Implement technical security measures to guard against unauthorised access to PHI being transmitted over a network.

Agent-layer mapping:

• All gateway ↔ tool ↔ EHR communications use TLS 1.3 minimum.
• Outbound calls to non-allowlisted hosts trigger transmission-allowlist policy → block.
• Outbound calls to third-party LLM APIs are scoped: only LLM endpoints that hold a current BAA are in the allowlist. New LLM providers go through BAA review before they hit the allowlist.

config:
  llm_egress_allowlist:
    - host: "api.anthropic.com"
      baa_signed: true
      baa_expires: "2027-03-15"
    - host: "api.openai.com"
      baa_signed: true
      baa_expires: "2027-01-22"
      requires_data_residency: "us-east"

The BAA expiration date itself becomes a policy concern — 30 days before expiration, AEGIS emits a baa-expiring alert.

6. Minimum Necessary (§164.502(b)) — Required (Privacy Rule)

Use, disclose, and request only the minimum amount of PHI necessary to accomplish the intended purpose.

Agent-layer mapping: this is the hardest one because it’s purpose-bound. AEGIS approximates it with field-level scoping:

rule: "minimum-necessary-clinical-scribe"
when:
  - tool.name == "ehr.read_patient_notes"
require:
  args.fields IS_SUBSET_OF [
    "visit_date", "chief_complaint", "vitals",
    "current_medications", "allergies", "current_assessment"
  ]
on_violation: ESCALATE

The clinical-scribe agent gets the fields needed for note generation; it doesn’t get billing codes, family history, or insurance information unless a separate tool call escalates with justification. The audit log captures both what was requested and what was approved.

7. Breach Notification Readiness (§164.404)

A breach involving PHI requires notification within 60 days of discovery. The clock starts at discovery, which means knowing what was accessed.

Agent-layer mapping: the cryptographic audit log makes “what was accessed” recoverable instantly. After a breach (e.g. compromised agent credentials), you query the audit log for all entries from that agent in the affected window, get a clean structured list, and produce the notification with confidence. Without a verified audit log, breach scope is hand-wavy and OCR penalties are higher.

What are the addressable specs that effectively become required?

HIPAA distinguishes “required” (must implement) from “addressable” (must implement or document why an alternative is equivalent). Three addressable specs become effectively required when AI agents are involved:

Addressable spec	Why it becomes required for agents
§164.308(a)(1)(ii)(A) Risk Analysis	Agents introduce new attack surfaces (prompt injection, jailbreak). Risk analysis must include them.
§164.312(a)(2)(iii) Automatic Logoff	Agents don’t “log off” — but their credentials must auto-rotate (90 days max).
§164.312(b) Audit Controls / Real-time	Manual log review is insufficient when agents make 1000s of calls/day. Need automated anomaly detection.

These are practical decisions, not letter-of-the-law — but OCR has expectations for “industry standard” and AI-mediated PHI access is unforgiving.

What does the BAA situation look like for LLM providers?

As of mid-2026, the BAA landscape for major LLM providers:

Provider	BAA available?	On which tier
Anthropic	Yes	Claude for Work + API (Enterprise)
OpenAI	Yes	ChatGPT Enterprise + API (Enterprise)
Google Vertex AI	Yes	All paid tiers
AWS Bedrock	Yes	Default (under AWS BAA)
Azure OpenAI	Yes	Default (under Microsoft BAA)
Mistral La Plateforme	Yes	Enterprise plan
Cohere	Yes	Enterprise plan

A few quiet ones that don’t have BAAs as of writing — open-router style aggregators, indie API resellers, some hobbyist endpoints. Send PHI through these and you’ve breached the moment the data leaves your network.

AEGIS’s policy enforcement: the LLM API egress allowlist is the only allowed destination. New endpoints require BAA-tagged config entries; the gateway refuses traffic to non-BAA hosts.

What evidence do I need in the HIPAA audit pack?

When OCR (or your client’s HIPAA officer) walks in:

aegis export-evidence-pack --framework hipaa --period 2026-Q2

The pack includes:

• Agent registry snapshot as of audit period (agent identities + scopes)
• Policy bundle with version hashes for each policy that touched PHI
• Audit log stratified sample with Merkle inclusion proofs
• BAA tracker with current status for every LLM API in the allowlist
• Risk analysis auto-generated from the agents/tools/policies inventory
• Breach notification readiness — the SQL queries to reconstruct any breach window

The auditor verifies the Merkle proofs against the witness service; the rest is structured documentation.

What are the most common HIPAA failure modes for AI agents?

Six patterns we’ve seen fail compliance review:

1. Using ChatGPT consumer API to summarise patient notes. No BAA — automatic breach.
2. Storing PHI in the LLM provider’s “memory” feature (e.g. ChatGPT memories, Anthropic Projects). Often unclear whether BAA covers these.
3. Sending entire patient records when only one field is needed (§164.502(b) minimum necessary violation).
4. Logging full prompts (with PHI) to Datadog / Splunk without considering whether the logging vendor has a BAA.
5. No procedure for credential rotation when an employee leaves. Discovered during breach investigation.
6. Patient consent extracted from free-text (“the patient said it was OK on the phone”). HIPAA wants structured, auditable consent.

AEGIS’s policy bundle addresses 1-6 explicitly. The policies are not magic — they’re enforcement of practices that should already exist; they just make the enforcement deterministic and auditable.

FAQ

Does using AEGIS make my company HIPAA-compliant? No — compliance is your organisation’s responsibility. AEGIS provides the technical controls and audit evidence that map to the Security Rule, but you still need administrative safeguards (workforce training, written policies, risk analysis) and physical safeguards (data center, device controls).

What about HITRUST CSF? HITRUST is a superset — implements HIPAA + ISO 27001 + NIST CSF + PCI-DSS controls. AEGIS evidence packs include a HITRUST CSF mapping document; the controls overlap is ~70%.

Can my agent run on-prem in a hospital network? Yes — that’s actually the cleanest deployment. AEGIS Community + Pro both self-host. No PHI leaves the hospital’s network; the LLM API calls go to the BAA-covered provider; the audit log lives on the hospital’s storage.

What if the LLM provider has a BAA but stores logs that include PHI? That’s covered by the BAA — the provider is your business associate for those logs. You need to verify their retention and deletion policies are HIPAA-compliant (most enterprise tiers are).

Is there a HIPAA-specific policy pack in AEGIS? Yes — aegis policy install healthcare-hipaa-base. It includes the 7 requirements above plus 12 derived controls. Customise from there.

---

Install → curl -fsSL aegistraces.com/install | sh

HIPAA evidence pack → aegis export-evidence-pack --framework hipaa

OCR HIPAA guidance → hhs.gov/hipaa