HIPAA Person or Entity Authentication for AI Agents Acting on Behalf of Clinicians

What 164.312(d) requires, and what it leaves open

The standard reads: implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed. It has no implementation specification. HHS states that for standards without one, compliance with the standard itself is required, so an auditor can assess the reasonableness of your procedure directly.

The neighbouring standards matter for agents. The access control standard, 164.312(a)(1), allows access only to "those persons or software programs" that have been granted access rights under 164.308(a)(4). Its required unique user identification specification calls for a unique name or number to identify and track user identity. Together, the text of both standards is not limited to human users.

The open point is definitional. The Security Rule currently defines authentication as the corroboration that a person is the one claimed. In its January 2025 proposed rule, HHS said this person-only definition neglects the importance of authenticating technology assets that create, receive, maintain or transmit ePHI, and proposed extending the definition to a person or technology asset. The proposed discussion also says the application itself must be authenticated, not only the user. Whatever its final form, the direction is clear enough to design for now. As of November 2026, the codified definition remains the person-only one, so document how your organization interprets "person or entity" and "software programs" for AI agents.

Separate the clinician, the agent and the invoking system

Most ambiguity comes from collapsing three actors into one. The clinician has authority over the patient relationship. The agent is the software that executes retrieval, drafting or tool calls. The invoking system is whatever launched the agent. If all three present the same credential to the EHR, the phrase "the one claimed" has no useful answer, because the claim does not say which actor is acting.

A workable design gives the agent its own identifiable credential, so the agent can be verified independently of the clinician. It then carries the clinician's delegated authority as a separate, bounded attribute rather than borrowing the clinician's session. The invoking system is recorded as the origin of the request.

Access rights for the agent should trace back to the access management process in 164.308(a)(4). NIST SP 800-66r2 says authentication activity should be conducted as part of access granting and access establishment, and it cross-references access control, audit controls and SP 800-63B. In practice, delegated scope should be definable, reviewable and limited to the PHI the task needs, in the same process that governs human access.

Evaluating agent credential patterns

Three patterns appear in practice. The question for each is whether it lets you verify the actor, show whose authority applied, and limit access to the minimum necessary PHI. Where agents call certified EHR FHIR APIs, SMART App Launch with OpenID Connect Core is the established standard for application authentication and authorization, and SMART v2 adds an optional asymmetric client authentication profile for confidential clients. Mechanisms such as OAuth 2.0 token exchange, on-behalf-of flows, backend service credentials and workload identity are implementation options. Judge each against the criteria below rather than assuming any one of them satisfies the standard.

• Shared service credential: The EHR sees one identity for many agents and clinicians. Verification proves only that the service is the service. It cannot attribute an action to a clinician or a specific agent, and access scope tends to be broad.
• Inherited clinician session: The agent acts as the clinician. Authority is clear, but the agent is indistinguishable from the person in logs, and the agent inherits every right the clinician holds, which works against minimum necessary scoping.
• Distinct agent identity with delegated authority: The agent authenticates as itself and presents a bounded delegation from a named clinician. This supports verification of each actor and narrower scope, at the cost of more identity lifecycle work: issuance, rotation, revocation and review.

Where runtime policy enforcement fits alongside identity

The identity provider remains the system of record for authentication. It issues and verifies credentials, and it should be where agent identities and delegations are managed. What identity infrastructure does not decide is whether a specific interaction or tool call, made by an authenticated agent, should proceed with the data in front of it.

That is the layer where runtime policy enforcement applies. Trussed enforces policy in the execution path on individual interactions and tool calls: allow, redact, block, or escalate for human approval. For a clinician-facing agent, that can mean allowing a chart retrieval within the delegated scope, redacting fields the task does not need, blocking a call outside scope, or sending a high-risk action to a human. These decisions are enforced at runtime, not reviewed after the fact.

The enforcement layer also produces audit-ready evidence, mapped to HIPAA, including the 164.312(b) audit controls standard. Trussed runs in production with healthcare and pharma organizations. Its scope is the interaction and tool call. It does not replace authentication, and it does not claim transaction-level governance or end-to-end tracing of agentic workflows.