HIPAA for AI agents.

HIPAA was written in 1996. It has been reinterpreted, amended by HITECH, and extended by state-level privacy regimes, but its technical safeguards section — 45 CFR 164.312 — still assumes a world where every access to protected health information (PHI) is performed by a named human operating a named workstation under a named role.

AI agents break that assumption. They are not named humans. They are not tied to workstations. Their roles often cross the covered entity / business associate boundary in ways existing audit tooling can't describe. When an OCR investigator or a plaintiff's attorney asks "who accessed this record, under what authority, at what time," the answer for an AI-mediated access is typically "a service account" — which is not a sufficient answer under HIPAA.

This article is for Covered Entities and Business Associates who are deploying, considering, or already running AI agents against systems that contain electronic PHI (ePHI). It maps specific HIPAA Security Rule provisions to the AXIS delegation and identity model, names what AXIS does not solve, and outlines what a HIPAA-aligned implementation looks like.

The HIPAA gap for AI agents

The Security Rule is framed around five categories of controls: administrative, physical, technical, organizational, and policies/procedures. AI agents intersect the technical safeguards most directly, but the implications ripple into administrative safeguards (workforce security, audit procedures), organizational requirements (business associate contracts), and breach notification.

Five specific gaps routinely emerge when an organization assesses AI agent access to ePHI against HIPAA:

1. Unique user identification (45 CFR 164.312(a)(2)(i)). The Security Rule requires covered entities to "assign a unique name and/or number for identifying and tracking user identity." In most current AI deployments, that unique identifier is an OAuth client ID, a service account, or an API key tied to a tool — not to an identifiable human or agent. When multiple humans operate the same agent, or when the agent operates across multiple organizations, the "unique identity" requirement is structurally unmet.

2. Authentication of the acting entity (45 CFR 164.312(d)). Required implementation: "procedures to verify that a person or entity seeking access is the one claimed." The authentication factor for most agent actions is a static bearer token or long-lived API key. It proves something, but it doesn't prove the agent is who it claims to be at the moment of the action, and it certainly doesn't prove the delegated authority behind the action.

3. Audit controls (45 CFR 164.312(b)). Required: "hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information." Most agent actions produce log entries that show what happened but not who authorized what at the moment it happened. If the delegation pattern changed between events — because a credential was revoked, a scope was narrowed, or a new business associate agreement came into effect — the log cannot reconstruct the state that was valid at action time.

4. Access management and termination (45 CFR 164.308(a)(4) and (a)(3)(ii)(C)). Administrative safeguards require documented workforce access management and termination procedures. When a human employee leaves, IT revokes their access. When an agent is decommissioned or a vendor relationship ends, the equivalent procedures are rarely cryptographic — a configuration update, a reboot, a ticket. Proving at audit time that an agent had no valid access after a given date is harder than it sounds.

5. Business associate chain accountability (45 CFR 164.502(e), 164.504(e)). Business Associate Agreements delegate specific PHI-handling authority from a covered entity to a business associate, with flow-down requirements to subcontractors. When AI agents act under a BAA, the BAA is a legal document. The technical enforcement of "the agent is operating within the BAA scope" is almost never tied back to the signed contract. An OCR investigator asking "can you show me the chain of authority from the patient's consent through the BAA to this specific agent action" is asking for evidence most organizations can't produce.

Organizations running AI on ePHI face OCR-assessed civil monetary penalties up to $2.13 million per violation category per calendar year (adjusted annually), plus state AG enforcement under state-level analogues (CA CMIA, NY SHIELD, TX MRPA, WA My Health My Data). Some states now permit private right of action for health data breaches. The enforcement risk is meaningful and increasing.

How AXIS delegation chains map to HIPAA safeguards

AXIS (Agent Cross-system Identity Standard) is an open protocol for agent identity, delegation, and authorization. It does not make systems HIPAA-compliant by itself, but it supplies the specific technical primitives HIPAA requires around agent actions:

• Unique, cryptographically verifiable agent identity. Every agent has an Ed25519 keypair. Every action carries a verifiable signature. The agent's canonical name resolves to an identity record in a registry.
• Delegation chains rooted at a human. Every signed action traces back through a chain of delegation credentials to a human operator's signing key. The chain is cryptographic, not contractual.
• Scoped authority embedded in the credential. The delegation credential carries explicit permissions (action types, resources, duration). The agent cannot act beyond the scope without producing a verification failure.
• Revocation with real-time effect. Revoking a credential invalidates future actions immediately. Downstream systems verify revocation status at time of action.
• Tamper-evident record of the action. The signed credential + action payload + verification result is a single artifact that survives audit without reconstruction.

Control-level mapping

HIPAA requirement	What AXIS provides
164.312(a)(2)(i) — Unique user identification	Each agent has a canonical AXIS identifier (axis:{operator}:{agent-name}) bound to a unique public key. The identifier resolves to an identity record traceable back to a human principal.
164.312(d) — Person or entity authentication	Every action is signed with the agent's Ed25519 private key. Receiving systems verify the signature against the registry-resolved public key. Static API keys are replaced by fresh signatures per action.
164.312(b) — Audit controls	Each action produces a signed credential + action payload + verification result. Stored as a single artifact, the audit trail survives without reconstructing distributed system state.
164.312(a)(2)(ii) — Emergency access procedure	Break-glass credentials are issued as separately-signed delegation credentials with elevated scope and short expiry. Emergency access leaves the same tamper-evident audit trail as routine access.
164.312(a)(2)(iii) — Automatic logoff	Delegation credentials carry expiry timestamps. Sessions do not drift past expiry. Verification at each action re-checks the expiry boundary.
164.308(a)(4) — Information access management	Access is defined by delegation scope, not by role membership. Scope can be narrowed or revoked per agent without modifying role definitions. Changes take immediate effect on next verification.
164.308(a)(3)(ii)(C) — Termination procedures	Revoking an agent (DELETE /agents/{id}) flips the revocation record. Every subsequent verification fails. No cache-clearing required downstream.
164.502(e) / 164.504(e) — BAAs and subcontractor flow-down	BAA scope becomes a set of delegation credentials issued from the covered entity's operator identity to the business associate's operator identity. Flow-down to subcontractors is a narrower sub-credential. The chain is cryptographic, verifiable offline, and revocable.
164.404 / 164.408 — Breach notification	Revocation events (agent or credential) are timestamped and cryptographically signed. Establishing "when did the unauthorized access window close" becomes a registry lookup.
164.530(c) — Safeguards (Privacy Rule)	Minimum necessary access is enforced per-action via delegation scope, not per-role via policy. Scope violations produce verification failures, which are themselves audit records.

BAA chain handling — the healthcare differentiator

Healthcare's unique AI agent problem is the chain of authority that crosses legal entity boundaries. A hospital (covered entity) contracts with a vendor (business associate) whose AI agent accesses PHI. That vendor uses a cloud provider and a model provider (both subcontractors, each requiring flow-down BAAs). The chain of authority is contractually defined and technically opaque.

AXIS makes the chain cryptographically explicit:

1. Covered entity operator identity signs a delegation credential to the business associate's operator identity. Scope encodes BAA-permitted PHI operations.
2. Business associate operator identity signs a narrower credential to their specific agent. Scope can only narrow; sub-delegation cannot widen authority.
3. Agent presents the full chain at each action. The receiving PHI system verifies the entire chain, signature by signature.
4. If the BAA terminates, the covered entity revokes the root credential. Every downstream action fails verification within one registry lookup.

This is the pattern OCR investigators are implicitly asking for when they ask "show us your BAA enforcement." Most organizations produce a signed PDF and a Slack screenshot. AXIS produces a signed, timestamped, tamper-evident chain that a court expert can verify independently.

What AXIS does not solve

• 164.312(a)(2)(iv) — Encryption and decryption (at rest). AXIS does not encrypt PHI. Storage-layer encryption remains the covered entity's responsibility.
• 164.312(e) — Transmission security. AXIS signatures ride on TLS; TLS is not specified by AXIS. Transport encryption remains upstream.
• 164.312(c) — Integrity controls. AXIS proves integrity of the authority artifact, not the integrity of the ePHI record being acted upon. Application-layer integrity (hash chains, append-only audit stores) remains separate.
• 164.308(a)(1)(ii)(A) — Risk analysis. AXIS supplies evidence for a risk analysis; it does not perform one.
• 164.308(a)(5) — Security awareness and training. Workforce training programs are orthogonal to AXIS.
• 164.310 — Physical safeguards. Facility access, workstation security, device controls. Unrelated.
• 164.502(b) — Minimum necessary determination. AXIS can enforce the scope you define; the policy determination of what "minimum necessary" means for a given use remains with the covered entity.
• Actual BAA contract language. AXIS represents the scope cryptographically; the legal document and its terms remain a separate legal artifact.

"AXIS supports HIPAA audit and access controls for AI agents" is an accurate claim. "AXIS makes you HIPAA-compliant" is not. Compliance requires an integrated program with documentation, policies, training, risk analysis, physical safeguards, and transmission-layer controls. AXIS is the identity and authority layer specifically.

Implementation pattern

For covered entities and business associates evaluating AXIS as part of a HIPAA program:

1. Scope the systems. Identify every system that contains or uses ePHI and is accessed (read, write, modify, transmit) by an AI agent, directly or via a tool.
2. Inventory the agents. Enumerate the agents acting against ePHI systems. Include vendor agents (copilots, triage tools, coding assistants, documentation aids) and internally operated agents.
3. Map to operator identities. Each distinct organization operating an agent against your ePHI needs an AXIS operator identity. Your own organization needs one. Each business associate needs one.
4. Translate BAA scopes into delegation credentials. For each BAA, express the permitted PHI operations as an AXIS delegation credential scope. The covered entity issues the top-level credential; business associates narrow it to individual agents.
5. Integrate AXIS verification at the PHI access boundary. Every AI agent action against an ePHI system verifies the delegation chain before the action proceeds. Rejected actions are logged as access attempts, which is itself HIPAA-relevant evidence.
6. Retain signed records. The audit trail is a set of JSON artifacts with signatures. Standard HIPAA retention (six years under 164.316(b)(2)(i)) applies. Storage is not specified by the Security Rule; use what fits your retention architecture.
7. Revocation procedures. Document the organizational procedure for revoking agent credentials on termination events (employee leaving, vendor BAA termination, agent decommission, suspected compromise). The technical mechanism is one API call; the organizational procedure must ensure it happens promptly.
8. Tabletop the breach scenario. Before you need it: run a tabletop where an agent is suspected of unauthorized access. Can you produce the delegation chain for every action in a given time window? Can you prove revocation took effect at a specific moment? If not, the operational gap is material.

Self-assessment questions

For CE and BA security teams evaluating their current posture:

1. For every AI agent that accesses ePHI in our systems, can we produce a unique cryptographic identifier that traces back to a specific human principal — not a service account?
2. If an OCR investigator asks for the chain of authority for a specific PHI access event, can we produce it without reconstructing distributed system state or relying on vendor cooperation?
3. When a business associate relationship terminates, can we prove that access was cryptographically revoked at a specific timestamp, not merely that a ticket was filed?
4. When an agent acts outside its authorized scope, do we have a tamper-evident record that the action was attempted and rejected — or does it appear as noise in application logs?
5. For each business associate with AI agents accessing our PHI, does the technical enforcement match the legal BAA terms, or does it exceed them?

If the answer to any of these is uncertain, the gap is material at the next OCR audit or breach investigation.

State-level considerations

HIPAA is not the only layer. State regimes increasingly impose additional requirements:

• California CMIA (Confidentiality of Medical Information Act) and CCPA/CPRA extend beyond HIPAA's covered entity definition and include private right of action for breach.
• New York SHIELD Act requires "reasonable" administrative, technical, and physical safeguards with documentation.
• Texas MRPA (Medical Records Privacy Act) imposes per-record penalties.
• Washington My Health My Data Act covers health-adjacent data outside HIPAA's scope.

AXIS's audit trail supports discovery obligations under all of these. The specific record-keeping requirements vary; the underlying need for a cryptographically verifiable chain of agent authority is consistent.

This document describes how the AXIS protocol supports HIPAA audit and access controls. It is not legal advice. HIPAA compliance requires a comprehensive program assessed against all applicable safeguards and administrative requirements. Penalty amounts adjust annually; verify current figures before relying on them. Consult qualified counsel and a HIPAA security officer for a compliance determination specific to your systems and jurisdiction.