Guide · Audit trails

Audit trails for healthcare AI agents: what the record has to show

By Harsh Mehta · Last reviewed: 2026-11-09

An audit trail for a healthcare AI agent is a record of every action the agent took on patient data. Each entry names the agent and its version, the organization and clinician it acted for, the purpose, the patient, the action, who approved it, the result and the time. HIPAA requires audit controls and a unique identity for whoever is acting. An agent that signs in with a clinician's login or a shared account meets neither, because the log names the wrong actor.

What HIPAA requires

The HIPAA Security Rule doesn't mention AI agents. Four of its safeguards still apply to any software that reads or writes electronic patient data for a covered entity or a business associate.

Rule	What it says	What it means for an agent
§ 164.312(a)(2)(i) Unique user identification	Assign a unique name or number to identify and track user identity.	The agent needs an identity of its own, not a person's.
§ 164.312(b) Audit controls	Record and examine activity in systems that contain or use patient data.	Every action the agent takes has to be recorded.
§ 164.312(d) Person or entity authentication	Verify that whoever seeks access is the one claimed.	The system has to know it is talking to the agent, not the clinician.
§ 164.308(a)(1)(ii)(D) Information system activity review	Regularly review audit logs, access reports and security incident reports.	A person has to be able to read the agent's records and make sense of them.

The rule sets no format for audit logs and no retention period for the logs themselves. It does require six years of retention for documentation the rule requires, and many organizations keep audit logs that long to match.

What each record should contain

A hospital reviewer or a payer's security team should be able to read one entry and answer six questions without calling you.

Question	Field	Example
Who are you?	Agent, version and the company that runs it	prior-auth-agent v3.2, Acme Health AI
Who sent you?	Organization and clinician the agent acts for	Bayview Ortho, for Dr. A. Lee
What do you want?	The action and its scope	`Claim/$submit`, one prior auth, one patient
Why?	Purpose of use	Payment
Is this allowed?	The permission checked and who approved	Clinic grant in date, approved by j.ramos
What happened?	Result and time	202 Accepted at 09:41:09

Two more fields make the record usable. The patient is referenced by a tokenized ID, so the trail proves what happened without becoming a second copy of the chart. Each entry also carries a hash of the entry before it, so nobody can edit the record later without it showing.

Why a borrowed login breaks the trail

In a survey of 250 US healthcare leaders (Imprivata, run by Vanson Bourne, September 2026), 35% said their AI agents run on a clinician's delegated login. Another 16% said they use generic or shared accounts.

A clinician's login. The payer's log and the hospital's log both say the doctor did it. Nobody can separate what the doctor did from what the agent did.
A shared service account. The log says the vendor did it. It doesn't say which agent, which task or for whom.
The vendor's own API client, with nothing added. The log names the right company. It still says nothing about the agent, the clinician it acted for or the purpose.

The fix starts with how the agent signs in. See how a healthcare AI agent should sign in to payer and EHR APIs.

FHIR AuditEvent: the format reviewers already know

FHIR has a resource for audit records, AuditEvent. It is based on the IHE ATNA audit record that hospital systems have produced for years, so a hospital's security tools can usually read it. Exporting your trail as AuditEvent saves the reviewer from learning your format.

AuditEvent element	What goes there for an agent
`agent` (one per actor)	One entry for the AI agent and one for the person who approved. `agent.requestor` marks which one started the action.
`agent.purposeOfUse`	Why the agent acted, from the HL7 purpose-of-use codes: treatment, payment or operations.
`entity`	The patient and the record that was touched.
`action`, `outcome`, `recorded`	What was done, whether it worked and when.
`source`	The system that wrote the entry.

AuditEvent has no field that says "this is an AI agent acting under a clinician's delegation." You express it with separate agent entries and roles. The IHE Basic Audit Log Patterns profile shows the common patterns.

Make it tamper-evident

A log that an administrator can edit proves little. Three things make a trail hold up when someone outside your company reads it.

Append only. Entries are added and never changed or deleted.
Hash-chained. Each entry includes a hash of the one before it, so changing one entry breaks every entry after it.
Checkable by the reader. The hospital or payer can verify the chain themselves, without taking your word for it.

What to do, by role

If you build the agent. Start recording now, in your own system, even where the payer doesn't read it yet. Give each agent and version its own identity. Keep signing keys out of the agent. Put a person's approval in front of anything that submits or changes data, and record who approved.

If you review vendors at a hospital. Ask the vendor to show one task from start to finish: the request, the permission check, the approval, the call and the result. Ask what identity will show up in your EHR's own log. Ask who at the vendor can edit or delete audit entries. There is a longer list in getting an AI agent through a hospital security review.

If you run a payer API. Your log sees a client ID. Ask agent vendors to send the organization, the person and the purpose with each token request, which the UDAP B2B extension supports, and keep those fields in your own audit log.

How Delegent handles it

Delegent is being built so that every call an agent makes to a payer or EHR API passes through one gate, and the gate writes the record. The agent has its own identity and key. The clinic's grant is checked for this agent, this purpose and this patient. A risky action waits for a staff member's passkey. The call goes out on a single-use token the agent never holds. The entry is hash-chained, and a task can be shared with a hospital reviewer as a link. Delegent keeps tokenized patient IDs and stores no clinical payloads.

Delegent is pre-launch and looking for its first design partners. If your agent needs an audit trail a hospital will accept, apply to be a design partner.

Questions

Does HIPAA require an audit trail for AI agents?

HIPAA doesn't name AI agents. Its Security Rule requires audit controls and unique user identification for any system that handles electronic patient data, and that covers software acting for a covered entity or a business associate. An AI agent that reads or writes patient data falls under both.

Is the EHR's or the payer's own log enough?

No. Their log records what their system saw, which is a user login or a client ID. It can't show which agent ran the task, which clinician the agent acted for, or who approved it. The agent company needs its own record that connects those facts to each call.

How long should AI agent audit logs be kept?

HIPAA sets no retention period for audit logs. It requires six years for documentation the Security Rule requires, and many organizations keep audit logs for six years to match. Contracts and state law can require longer.

Should the audit trail contain patient data?

As little as possible. A tokenized patient ID and the type of record touched are enough to prove what happened. Storing clinical payloads in the trail creates a second copy of the chart to protect.

How is an audit trail different from LLM tracing or observability?

Tracing records prompts, model outputs and tool calls so engineers can debug the agent. An audit trail records authority: which agent acted, for whom, under what permission, with whose approval and with what result. It is kept tamper-evident because people outside the company read it.