Arcezia / AI agent security / Banks
AI agent records for banks: who approved each action, and that nothing ran unapproved
A bank 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 execution logs and its approval system’s logs, it can also show who approved, and that every executed action had a check. An auditor, examiner or insurer verifies the records offline with an open-source checker, without trusting Arcezia or the bank.
This page is for banks and financial firms whose agents act on accounts, payments or data. It sets out what the records hold, how to check them, and how they relate to the EU AI Act, DORA, PCI DSS, RBI directions and India’s DPDP Rules.
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 banks and financial services: 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 |
|---|---|---|
| EU AI Act Art. 12(1) logging, Art. 26(6) deployers keep logs at least six months (high-risk systems, for example credit scoring under Annex III 5(b); applies from 2 December 2027) | Automatic, signed, ordered records of each checked agent action, exportable | Whether your system is high-risk; keeping the export |
| EU AI Act Art. 14(4) human oversight | Held calls waiting for a person, and what followed | Who the overseer was |
| DORA, RTS (EU) 2024/1774 Art. 12(2)(d): protect logs against tampering and deletion | Alteration and removal are detectable offline | Preventing them; access to your copies |
| PCI DSS v4.0.1 10.3.2 (logs protected from modification), 10.5.1 (12 months) | Modification is detectable; exports to retain | User identity, origin and affected resource fields of 10.2.2 |
| RBI IT Master Direction 2023, para 15: audit trails, forensic evidence, non-repudiation | An audit trail of agent checks whose answers cannot be altered undetected | Logging in the systems the agent acts on |
| RBI FREE-AI report (2025, recommendations, not directions): Rec. 16 oversight of autonomous AI, Rec. 24 audit of decision outputs | Held actions before they ran; signed decision outputs | Data inputs, models, governance |
| 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) |
| Federal Reserve SR 26-2 (model risk) | Not mapped. SR 26-2 states that generative and agentic AI models are not within its scope. | |
Sources: EU AI Act; Regulation (EU) 2026/1744 (application dates); RTS (EU) 2024/1774; PCI DSS v4.0.1 (PCI Security Standards Council); RBI IT Master Direction; RBI FREE-AI report; SR 26-2 (attachment, footnote 3); DPDP Act 2023; DPDP Rules 2025 (G.S.R. 846(E)) and their commencement: PIB note. 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.
Record format, export and retention settings: developer docs, receipts and compliance.