This post is for informational purposes only and does not constitute legal or compliance advice. Consult your compliance counsel for HIPAA obligations specific to your organisation.
Quick answer: HIPAA has no AI-agent-specific rules, but any agent accessing PHI is subject to the same Technical Safeguards as human users: unique user identification, audit controls, integrity controls, and transmission security. The gap most health-tech teams have is unidentified agent access, no audit trail, and credentials that can't be revoked without disrupting everything else.
Where AI agents fit in HIPAA
HIPAA's Privacy and Security Rules apply to covered entities (hospitals, clinics, health plans, clearinghouses) and their business associates. A business associate is any entity that creates, receives, maintains, or transmits PHI on behalf of a covered entity.
When an AI agent accesses a patient record, reads lab results from an EHR API, or processes clinical notes, it is performing one of those functions. The fact that it's software rather than a person doesn't change the analysis — what matters is whether PHI is being accessed or transmitted, not who or what is doing the accessing.
Business Associate Agreements and third-party AI services. If your agents use third-party AI APIs — OpenAI, Anthropic, Google — and those calls involve PHI (patient descriptions, clinical notes, health data), those providers need to be covered by a Business Associate Agreement. Most major AI providers offer HIPAA BAAs for enterprise customers, but they're not automatic. Running PHI through a model API without a BAA in place is a violation, regardless of whether the agent was human-directed or autonomous.
Which agents trigger covered-entity obligations. An agent that reads appointment schedules containing patient names: yes. An agent that processes billing codes tied to patient records: yes. An agent that runs entirely on de-identified data: no — provided the de-identification meets Safe Harbor or Expert Determination standards. The rule of thumb is conservative: if there's any plausible path from the agent's inputs to an identified individual, treat it as PHI access.
Access controls — §164.312(a)(1)
The Technical Safeguards require covered entities to implement technical policies and procedures for electronic information systems that maintain PHI, allowing access only to authorised persons or software programs.
The key standard here is unique user identification — assigning each user a unique name or number for tracking identity and activity. The regulation explicitly includes software programs. An AI agent accessing an EHR API needs a unique, named identity — not a shared service account that three workflows and a developer's local environment all use.
What this looks like in practice:
Per-agent named identity. Each AI agent that touches PHI should have its own access profile: a named identity that is provisioned specifically for that agent, scoped to the systems and operations that agent's task requires, and revocable independently of everything else that uses the underlying service credentials.
Automatic logoff equivalents. The regulation requires automatic logoff for workstations — the intent is that an inactive session doesn't remain open with persistent access. For agents, the equivalent is time-limited or task-scoped tokens: credentials that expire after the agent's session or task completes, rather than persistent API keys that remain valid indefinitely.
Shared API keys fail both requirements. They have no named identity at the agent level, and they don't expire when the agent finishes its task. They're the equivalent of giving every employee the same login — something no auditor would accept for human users.
For how to build per-agent access profiles that satisfy these controls, see AI agent permissions.
Audit controls — §164.312(b)
The audit controls standard requires implementing hardware, software, and procedural mechanisms to record and examine activity in information systems that contain or use PHI.
For human users, audit logs are standard infrastructure — most EHR systems and cloud platforms emit access logs tied to user identities. For AI agents, the audit trail breaks down in the most common setup: an API key stored in an environment variable, passed to an agent at runtime, used to call an EHR or health data API. The downstream API may log that the key was used — but it can't tell you which agent used it, for which task, or whether that access was within the agent's intended scope.
What a HIPAA-admissible agent audit record looks like:
- Agent identity (named, not shared)
- Service or system accessed
- Operation performed (read patient record, write appointment, query lab results)
- Timestamp
- Whether the request was within the agent's authorised scope
Why environment variable credentials produce no usable audit trail. If four workflows share the same EHR API key — a credential automation workflow, an appointment scheduling agent, a billing reconciliation agent, and a developer's test environment — the API's access log shows four accesses from the same identity. You cannot distinguish legitimate agent activity from anomalous activity, cannot reconstruct which agent accessed which record, and cannot demonstrate to an auditor that access was controlled at the agent level.
The audit controls standard doesn't prescribe a specific log format, but it does require that activity be examinable. An indistinguishable shared-key access log is not examinable in any meaningful sense.
See IAM for AI agents for how a credential broker layer generates per-agent audit records that satisfy this requirement.
Integrity and transmission security — §164.312(c) and (e)
Integrity controls require that PHI not be improperly altered or destroyed. For agents, the relevant risk is scope: an agent with full write access to patient records can alter records it was never meant to touch. Scoping agent credentials to the minimum operations required — read-only access to scheduling data for a scheduling agent, write access only to appointment status for a check-in agent — limits the blast radius of a misbehaving or compromised agent.
Transmission security requires guarding against unauthorised access to PHI transmitted over electronic communications networks. When an agent authenticates with a raw API key, that key is present in HTTP headers, in environment variables, potentially in log files, and in the agent's context window. A scoped, short-lived token reduces the interception and exposure risk: the token is useless outside its defined scope, and expiry limits the window of exposure if it is intercepted.
The approval gate as a technical safeguard
For high-risk PHI operations — bulk patient record exports, record deletion, modifying clinical data — a human-in-the-loop approval step is a defensible compensating control under the Technical Safeguards.
The framing: the agent proposes the operation, the operation is held pending review, a named authorised user approves or rejects, the outcome is logged with the approver's identity. This creates:
- A reviewable record of high-risk PHI operations
- Evidence that sensitive access is subject to human oversight
- An audit trail mapping PHI access to authorising individuals
HIPAA doesn't require approval gates specifically, but they're strong evidence of a mature access control environment — and for operations like bulk PHI export, they're a practical implementation of the "minimum necessary" principle under the Privacy Rule.
What to document
Documentation is where most health-tech teams fall short on agent compliance — not because their architecture is wrong, but because it's undocumented.
Agent access inventory. A list of every agent with PHI access: agent name, access profile, scope (which systems, which operations), provisioning date, task owner. This is the agent equivalent of your user access list. Update it when agents are added, changed, or decommissioned.
Access review cadence. A scheduled review of agent access profiles — quarterly is standard for access controls in healthcare environments. Document that you reviewed, that access remains appropriate, and that inactive agents have been deprovisioned.
BAA status for AI service providers. A record of which third-party AI APIs are used in PHI-touching workflows and whether a BAA is in place for each. This is particularly important as AI tooling evolves quickly — a BAA that was in place for one provider may not cover a new model or API endpoint.
Incident response for compromised agent credentials. A documented process: detect anomaly → revoke agent access profile → verify revocation → investigate PHI exposure → report if required. The revocation step needs to be fast — per-agent tokens allow immediate revocation without rotating shared credentials. The breach assessment step (did PHI get accessed or exfiltrated?) depends entirely on having audit logs that can answer the question.
Audit log retention. HIPAA's Security Rule requires documentation to be retained for six years. Agent access logs should be retained on the same schedule.
The practical starting point
Most health-tech teams aren't far from compliance — the gaps are usually in agent identity and audit logs rather than in architecture. The changes that close those gaps are the same changes that improve agent security generally: per-agent access profiles instead of shared keys, a credential layer that logs access at the agent level, and token-based authentication that can be revoked without disrupting other systems.
The HIPAA framing makes the business case clearer for stakeholders who've been deferring those changes: this isn't optional for PHI-touching agents, it's a Technical Safeguard requirement.
Gazebo's security model implements the four access controls HIPAA's Technical Safeguards require for software programs: unique named identities per agent, scoped access profiles enforced at runtime, audit logs at the credential request level, and immediate revocation without rotating underlying credentials. For the SOC 2 parallel, see SOC 2 for AI agents.