The short answer
Picture an auditor asking what your AI agent did with patient records last Tuesday. HIPAA requires audit controls, but it never says which details to record, and it doesn’t mention AI at all. For an agent, record who asked, what it tried to do, what was allowed and what actually changed.
HIPAA’s Security Rule requires audit controls: “mechanisms that record and examine activity in information systems that contain or use electronic protected health information” (45 CFR 164.312(b)).1 A separate rule requires procedures to regularly review records of information system activity, such as audit logs.3 Neither names the fields a record must hold, and neither mentions AI.
So for an AI agent that reads or writes ePHI, the design is yours. A useful record answers five questions for each action: which agent, acting for whom; what it asked to do; what decided whether it could; what actually changed; and when. This post sets out the rule text, then a record design that makes review practical. It isn’t legal advice.
Deedglass
A sealed record you can check offline
Record 1043
- What ran
- Medication order, Bed 12
- Approved by
- Dr. N. Shah
- Check
- Matches
- Time
- 09:12
- The request
- Not keptA fingerprint only: 77d2…c41a
Each record is linked to the one before
- Record 1041
- Record 1042
- Record 1043
What the rule text says
Four provisions matter most for agent activity. The quotations are from the regulation itself.
| Provision | What it says | Required or addressable |
|---|---|---|
| 164.312(b) Audit controls | Mechanisms that record and examine activity in systems that contain or use ePHI1 | Standard |
| 164.312(c)(1) Integrity | Protect ePHI from improper alteration or destruction1 | Standard |
| 164.308(a)(1)(ii)(D) Activity review | Regularly review records of system activity, such as audit logs, access reports and incident tracking reports3 | Required |
| 164.316(b)(2)(i) Retention | Keep required documentation for 6 years from creation or when it was last in effect, whichever is later2 | Standard |
Two neighbouring provisions are addressable: access authorization (164.308(a)(4)(ii)(B)) and log-in monitoring (164.308(a)(5)(ii)(C)).3 An addressable specification still has to be assessed; it isn’t optional, but you decide how to meet it.
What it leaves to you
The rule says record and examine. It doesn’t say which events, which fields, or how often to look. That flexibility is deliberate, and it leaves real decisions:
- What counts as activity. Reads, writes, searches, exports?
- Whose activity. The person, the service account, or the agent?
- How detailed. Enough to reconstruct what happened, or only that something did?
- How protected. A log the agent’s own credentials can edit doesn’t help much under the integrity provision.1
NIST SP 800-66 Rev. 2, published in February 2024, is the government’s practical guide to implementing the Security Rule for entities of any size.4 It is the place to start for the wider program. Health-informatics standards fill in the record itself. ISO 27789 says each audit record should at minimum identify the user, the subject of care, the function performed and the date and time.5 IHE’s Basic Audit Log Patterns profile FHIR AuditEvent for create, read, update, delete and query, each with a patient-specific variant.6
Why agents need a different record
Most EHR audit logs were designed around a person logged in at a workstation. An agent breaks three of their assumptions.
- The user is two parties. An agent acts for someone. A log line that says “service-account-7 updated Observation/123” has lost the clinician who asked. ISO 27789’s “identify the user” needs both.5
- The request isn’t the result. An agent’s tool call says what it meant to do. The server may store something else: a different id, a dropped field, a duplicate. Our FHIR benchmark post shows 11 of 17 synthetic writes where that happened.
- There is a decision in between. Something allowed the call: a rule, a person’s approval, or nothing at all. That decision is the most useful thing a reviewer can see, and ordinary logs don’t capture it.
A record for each agent action
Here is a field list that covers the provisions above and the standards that flesh them out. Every field is something you can capture at the point where the agent’s call leaves for the system it changes.
| Field | Example | Why |
|---|---|---|
| Agent identity | scribe-agent@clinic-a |
Who acted |
| On behalf of | The clinician’s user id | ISO 27789’s user5 |
| Patient reference | Patient/123, not the name |
ISO 27789’s subject of care5 |
| Action | update Observation/456 |
The function performed5 |
| Request digest | A hash of the request body | Shows what was asked without storing ePHI twice |
| Decision and reason | allowed by rule notes-draft-only or approved by user 42 |
What let it happen |
| Result | Status, server version id | What the system said |
| Check after | read back at version 3: matches |
What actually changed |
| Time | UTC timestamp | Date and time5 |
| Integrity | Signature or hash chain over the record | Integrity of the log itself1 |
Three design choices are worth making on purpose.
Keep clinical content out of the audit record. Store references and digests, not note text. The audit trail then isn’t a second copy of the chart, with its own access problem. You can still match a digest to the source record when a review needs the content.
Protect the record from the actor. The agent’s credentials should be able to add records, never change or delete them. Signing each record, or chaining them, lets a reviewer notice an edit. Why logs aren’t evidence goes into the difference.
Plan retention. The six-year rule covers required documentation such as policies and records of required actions.2 Whether a given log is that kind of record is a question for your privacy officer, so design the store so keeping it six years is possible without keeping the clinical payloads that long.
Reviewing the records
Activity review is required, and “regularly” is yours to define.3 For agents, review is easier than for people if the record has a decision field, because you can sort by it:
- Every refusal. Why did the agent try something a rule refused? Repeated refusals are worth a look.
- Every approval. Who approved what, and how quickly. Approvals given in two seconds are approvals nobody read.
- Every mismatch. Writes where the check after the write disagreed with the request.
- Volume by agent and patient. An agent touching far more patients than usual is a signal.
- A sample of allowed writes, read in full against the source record.
Write down what you reviewed and when. That written record is itself the kind of documentation the retention rule is about.2
What this post isn’t
This is an engineering post, not legal advice, and nothing here makes a system meet HIPAA. Your privacy and security officers decide how your organisation meets the rule. Nothing here is clinical: a record shows what an agent did, not whether it was the right thing to do.
We build Deedglass, which records agent actions this way, so here is what it covers. Its sealed records hold ids, digests, decisions and times, not the request or the result.7 In PHI mode, once an action is sealed and checked, it keeps ids and digests of the request and result rather than their content.7 Records export as FHIR R4 AuditEvent shaped to the IHE BALP profiles, and as Provenance.7 Limits apply, including that payloads are held while an action waits for approval or a check.7 The audit trail for AI in healthcare entry and our post on agents writing to patient records cover the rest; the agent action record entry describes the record format. To try the checks without installing anything, open the playground; to grade what an agent can reach on your own machine, run npx deedglass scan (the grade, explained).
Written with AI assistance and checked against our claims register.