HIPAA for AI agents: controlling access for audit-ready operations

A record in a database holding protected health information was read at 02:14. Three AI agents were running that night, all authenticating as the same shared service account. Which one read it. Under HIPAA, "we cannot tell" is not a defensible answer, because the rule is built on attribution: knowing who accessed PHI, what they were permitted to see, and being able to account for it later. HIPAA for AI agents starts and ends with making every access trace back to a single, named agent.

The HIPAA Security Rule expects unique user identification, access limited to the minimum necessary, and audit controls that record activity in systems with electronic PHI. None of those bend because the user is software. An AI agent that queries a clinical database is a user of ePHI, and it has to be identified, scoped, and recorded like one.

Why shared identity breaks HIPAA for agents

The fastest way to fail is the shared service account. It is convenient: one credential, every agent uses it, the database sees a single principal. It is also the end of attribution. The minimum-necessary standard wants each agent scoped to only the PHI its task requires, and a shared account gives every agent the union of everyone's access. The audit-control standard wants activity traced to a user, and a shared account collapses every agent into one indistinguishable actor. The moment you need to account for a specific disclosure, the record points at a credential, not an agent.

Per-identity attribution reverses this. Each agent carries its own identity. Each access is scoped to that agent's task. Each read and write is recorded against that agent. Now the 02:14 read has a name attached, the scope it was permitted, and a recording of what it did. That is audit-ready: the evidence for the access exists at the moment of access, not assembled afterward.

The requirement: attribution where the agent cannot edit it

Attribution only counts if the agent cannot rewrite it. An agent that authenticates itself, scopes itself, and logs itself is keeping a diary, and HIPAA audit controls are not satisfied by a diary. The identity check, the scope enforcement, and the activity record have to be produced by something between the agent and the ePHI, at the access boundary, outside the agent's control.

hoop.dev is built to that requirement. AI agents reach the databases and internal services holding PHI through hoop.dev, a Layer 7 access gateway with a network-resident agent. Each agent connects under its own identity, the gateway enforces the scope for that identity, and it records the session on its own side. Inline data masking on those connections means an agent can complete a task while seeing only the fields it is permitted, which is the minimum-necessary standard expressed as a control rather than a policy memo. hoop.dev produces the per-identity access logs, approvals, and masking records that a HIPAA program presents as evidence. The learn pages cover the access model and the getting-started docs cover fronting a database.

What audit-ready attribution looks like in practice

Trace one agent. It connects as agent-billing-07, requests the claims table, and the gateway applies a mask that hides the diagnosis fields it has no reason to see. The session records the rows returned, masked. When a HIPAA audit or a patient's accounting-of-disclosures request lands, the answer to "who accessed this record and what did they see" is a query against records that were correct when they were written. No reconstruction, no shared-account guesswork.

FAQ

Is hoop.dev HIPAA compliant?

hoop.dev does not hold a HIPAA certification, and no tool can make your agents HIPAA compliant on its own. HIPAA compliance is a property of your organization and its safeguards. hoop.dev generates the evidence for HIPAA, per-identity access logs, scoped access, masking, and session recordings, that your program uses to demonstrate those safeguards.

How does masking help with minimum necessary?

Minimum necessary means an agent should see only the PHI its task requires. Inline masking at the access boundary removes fields the agent is not permitted before they reach it, so the control is enforced on the connection rather than trusted to the agent's restraint.

hoop.dev is open source. To give every AI agent its own identity and a recorded path to PHI, start from the repository on GitHub.