What logging do AI agents need for the EU AI Act?

For a high-risk AI system, Article 12 of the EU AI Act asks that the system automatically record events over its lifetime, so that risks can be identified and its operation monitored, and Articles 19 and 26(6) ask providers and deployers to keep those logs for at least six months unless other law says otherwise. Immiscible records every agent decision, approval, freeze and change of authority automatically, in a hash-chained ledger whose head is signed, which you can export and verify offline; it is evidence your compliance file can rely on, not compliance itself.

This page is not legal advice. Whether an agent is part of a high-risk system depends on what it is used for (Annex III), and the application dates for high-risk obligations were moved by the EU’s Digital Omnibus (to December 2027 for the Annex III uses, at the time of writing). Check the current position with whoever owns your compliance.

#What does Immiscible record?

Each decision with the agent, the person it acts for, the rule it was judged under, the reasons and signals, who approved and when; every freeze and lift; every change to a rule or an agent’s tier; card authorisations; and per-request gateway records (model, cost, data region, budget, routing rule). Prompts and answers are kept as digests by default, not text. See what is recorded.

#How do I get the logs out?

# every record, checkpoint and key, as one JSON document (a service token with evidence:read)
curl "https://immiscible.fly.dev/api/w/$WORKSPACE/evidence/bundle" -H "authorization: Bearer $IMMISCIBLE_SERVICE_TOKEN" -o bundle.json

# check it offline: exit 0 means every record and checkpoint verified
node scripts/verify-evidence.mjs bundle.json --keys keys-you-kept.json

The verifier and the format are in the evidence specification. The bundle lists the record-keeping obligations it supports (for example Art. 12 and Art. 26(6)) as references for whoever writes the file. It can also go to your SIEM as OCSF or OpenTelemetry (SIEM export), and the gateway’s evidence pack for a period and risk tier is at GET /v1/evidence/pack. See getting it out.

#What makes the audit trail tamper-evident?

Each record carries the hash of the one before it, and the head of the chain is signed with Ed25519 at intervals. Rewriting or deleting a record breaks the chain at that point, and the verifier names the first record that broke. Keep the public keys, or the signed checkpoints, somewhere the operator cannot reach: a bundle on its own proves only that it is consistent with itself. See evidence.

#What are signed receipts for agent actions?

Every allow carries a short Ed25519-signed token naming the agent, the action, the rule and whether a person approved it. A merchant, an auditor or anyone else can check it with POST /v1/verify, with no account, or offline against the published keys. A receipt proves one action was allowed; settling the action records that it happened. See receipts.

#Does it help with human oversight?

Article 14 asks that high-risk systems can be overseen by people, including stopping them. Approvals by a named person before consequential actions, the kill switch and autonomy that is earned on evidence are built for that, and each is recorded. Whether they meet your obligations is for your compliance assessment.

#What does it not do?

• It does not certify anything or make anyone compliant. No regulator or notified body has assessed it.
• It records what passes through it. Agent activity that never reaches Immiscible is not in the ledger.
• Retention is set per workspace within the plan; set it to at least what your obligations require.