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 cannot 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.

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 does not prove the agent is who it claims to be at the moment of 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.

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 an agent is decommissioned or a vendor relationship ends, the equivalent procedures are rarely cryptographic.

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.

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.

How AXIS delegation chains map to HIPAA safeguards

AXIS 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.
• 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. The agent cannot act beyond the scope without producing a verification failure.
• Revocation with real-time effect. Revoking a credential invalidates future actions immediately.
• Tamper-evident record of the action. The signed credential + action payload + verification result is a single artifact.

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, 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.
164.312(b) Audit controls	Each action produces a signed credential + action payload + verification result. 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.
164.312(a)(2)(iii) Automatic logoff	Delegation credentials carry expiry timestamps. Sessions do not drift past expiry.
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.
164.308(a)(3)(ii)(C) Termination procedures	Revoking an agent flips the revocation record. Every subsequent verification fails.
164.502(e) / 164.504(e) BAAs and subcontractor flow-down	BAA scope becomes a set of delegation credentials. Flow-down is a narrower sub-credential. The chain is cryptographic, verifiable offline, and revocable.
164.404 / 164.408 Breach notification	Revocation events are timestamped and cryptographically signed. Establishing when the unauthorized access window closed 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.

BAA chain handling

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.
• 164.312(c) Integrity controls. AXIS proves integrity of the authority artifact, not the integrity of the ePHI record being acted upon.
• 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.
• Actual BAA contract language. AXIS represents the scope cryptographically; the legal document remains 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. 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 by an AI agent, directly or via a tool.
2. Inventory the agents. Enumerate the agents acting against ePHI systems. Include vendor agents and internally operated agents.
3. Map to operator identities. Each distinct organization operating an agent needs an AXIS operator identity.
4. Translate BAA scopes into delegation credentials. For each BAA, express the permitted PHI operations as an AXIS delegation credential scope.
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.
6. Retain signed records. Standard HIPAA retention (six years under 164.316(b)(2)(i)) applies.
7. Revocation procedures. Document the organizational procedure for revoking agent credentials on termination events.
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?

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?
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?
3. When a business associate relationship terminates, can we prove that access was cryptographically revoked at a specific timestamp?
4. When an agent acts outside its authorized scope, do we have a tamper-evident record that the action was attempted and rejected?
5. For each business associate with AI agents accessing our PHI, does the technical enforcement match the legal BAA terms?

State-level considerations

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

• California CMIA 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 imposes per-record penalties.
• Washington My Health My Data Act covers health-adjacent data outside HIPAA's scope.

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.