Arcezia / AI agent security / Healthcare
AI agent records for healthcare: who approved each action, and that nothing ran unapproved
A healthcare organisation can show, from signed records alone, that each AI agent action that went through the check was answered before it ran, what the answer was (ALLOW, REVIEW or BLOCK), and which held actions were later allowed and what each was waiting for. With its own system logs and its approval system’s logs, it can also show who approved, and that every executed action had a check. An auditor verifies the records offline with an open-source checker, without trusting Arcezia or the organisation.
This page is for hospitals, clinics, payers and health-tech firms whose agents act on patient systems. It sets out what the records hold, how to check them, and how they relate to HIPAA, the EU AI Act, India’s DPDP Act and Rules, and ABDM.
The records are designed to carry no patient data: the action itself is kept only as a digest. Names you choose, such as tool or policy names, appear as you wrote them.
What the evidence is
Each time an AI agent proposes a tool call, the call is checked before it runs. The answer is ALLOW (it may run), BLOCK (refused, with a reason) or REVIEW (held, naming what would release it, such as a person’s approval). Each answer is kept as a signed record.
- What one record holds: the answer and its reason or release labels, the time it was signed, the action type, the session and request it belongs to, a digest of the action (not its content), and the account. When a person’s approval was attached, the record also names it: its one-time id, its role, the fingerprint of the approval key that verified it, the call it was bound to, and whether it counted. Not the person’s name.
- Signed: each record carries an Ed25519 signature. Changing any signed field afterwards makes the signature fail.
- In order: each record names the one before it, so a record removed from the middle leaves a gap that shows.
- Complete to a point: signed checkpoints state how far the records reached and how many there were at a time, so records removed from the end also show. Records removed at the end of their retention period carry a signed statement.
- Yours to keep: the account owner can export every record at any time, on every plan.
This is evidence, not a certification. It does not make anyone compliant with any law or standard.
Check it yourself, offline
An auditor does not need to trust Arcezia or the account holder. arcezia-verify-records is a single open-source file in the arcezia package (MIT licence). It needs Python and one cryptography package, and no network. To try it first on a real export, use the sample export and its expected output.
pip install "arcezia[verify]"
arcezia-verify-records export-page-*.ndjson --use-export-keys --fingerprint <fingerprint from the account holder>The key decides everything, so it must not come only from the file being checked, nor only from Arcezia. The account holder reads the key’s fingerprint from its dashboard (API Keys page, “Record-signing key fingerprint”) or from GET /v1/account/record_keys, and gives it to the auditor directly. A key whose fingerprint does not match is not used.
It reports every record as PASS, PASS-ATTESTED (a record from before the current public format, whose content is vouched for by a current signed statement and whose place is proven by the links to a signed checkpoint), FAIL (a contradiction was found) or UNVERIFIED (nothing contradicts it, but something needed to confirm it, such as the key, is absent), then whether the export is complete. It checks signatures, the signed header of each page, order and completeness. It does not judge whether any answer was right. What each result means.
Audit procedure for healthcare: what to request, how to run the check, what each result proves and what it does not, and how to sample.
How the records relate to the rules
Where a rule applies to you is your own legal determination. Sources for each row are listed under the table.
| Rule | What the records give | What they leave to you |
|---|---|---|
| HIPAA Security Rule 45 CFR 164.312(b) audit controls | A mechanism that records each checked agent action on systems holding ePHI, and a tool to examine the records | Activity that was not a checked agent action |
| 45 CFR 164.308(a)(1)(ii)(D) information system activity review | Records and a repeatable offline check for the review | The review itself |
| 45 CFR 164.312(c) integrity of ePHI | Not covered. The signatures protect the decision records, not patient data. | |
| Proposed HIPAA Security Rule changes (January 2025) | Still a proposal, listed under long-term actions. Nothing here depends on it. | |
| EU AI Act, medical-device AI (Art. 6(1), Annex I; applies from 2 August 2028) and emergency triage (Annex III 5(d); from 2 December 2027): Art. 12 logging, Art. 14 oversight, Art. 26(6) keep logs at least six months | Signed, ordered records; held calls waiting for a person; exports to keep | Whether your system is high-risk; who the overseer was |
| India DPDP Rules 2025 (in force from 13 May 2027): Rule 6(1)(c) logs and review, 6(1)(e) keep logs one year | Records of held and refused agent actions a reviewer can examine; exports to keep | Access by anything other than a checked agent |
| DPDP Rules 2025, Rule 8(3) (processing logs kept at least one year); DPDP Act s.8(7) and s.12 (erasure) | Signed retention-removal statements make removal at the end of retention checkable. After account deletion, signed erasure statements show each erased record was erased, not altered | Your retention schedule; the erased content itself (keep the export taken before deletion) |
| ABDM Health Data Management Policy, cl. 27.5(a) audit trail of processing | An audit trail of checked agent actions | All other processing; consent logs |
Sources: 45 CFR 164.312, 164.308; status of the proposed Security Rule changes; EU AI Act; Regulation (EU) 2026/1744 (application dates); DPDP Act 2023; DPDP Rules 2025 (G.S.R. 846(E)) and their commencement: PIB note; ABDM Health Data Management Policy. Checked October 2026.
What the records do not show
- Calls that were never checked. A record exists only for a tool call that was sent for a check. Showing that every executed action had one means matching your own execution logs against the records.
- The approver’s name. The record names the approval (its one-time id, role, approval key fingerprint and the call it was bound to), not the person. Your approval system, which signs the approval, maps that id to the person.
- What happened when the tool ran. ALLOW means the call was permitted. The record does not show the tool’s result.
- Whether an answer was right. The checker shows the records are genuine, ordered and complete. It does not grade the decisions.
- Retention you did not keep. How long records stay with Arcezia depends on the account’s settings. Export and keep them for as long as your rules require; they can still be checked years later.
- Erased content. When an account is deleted, record content is erased and only hashes remain. The deletion gives the account holder a receipt, which they must keep (it cannot be recovered); with it they fetch the signed statements of the erasure, and the checker confirms each erased record was erased, not altered. What the erased records said cannot be recovered: keep the export taken before deletion.
Record format, export and retention settings: developer docs, receipts and compliance.