DORA Art. 17 evidence for AI agents: what an auditor actually needs
DORA has been in force since January 2025. Here is a precise mapping of what Art. 17 requires for ICT incident documentation, and how a signed .cal certificate satisfies each requirement.
What DORA Art. 17 actually requires
The Digital Operational Resilience Act has been in force since January 2025. Article 17 mandates that financial entities maintain documented, reproducible evidence of ICT incident timelines. Specifically, the regulation requires:
- Identification and classification of the ICT-related incident
- Timestamp and duration of the incident
- Identification of the affected ICT assets and components
- Description of the incident's impact on operations
- Actions taken in response and their outcomes
For a 2026 regulated fintech running autonomous AI agents, this translates into a concrete question: if your CI/CD pipeline agent is compromised tonight, what artifact can you hand your auditor tomorrow morning?
The gap existing tools leave
Traditional incident response tooling was not built for autonomous AI agents. SIEM systems capture network and application logs — but a living-off-the-land attack that uses only legitimate syscalls produces no anomalous network traffic and no application-layer errors. EDR tools classify known malware signatures — but a prompt-injected agent using ptrace to scrape process memory uses no known malware. The attack is structurally invisible to these tools.
The result is an incident report that says "we detected unusual activity at 03:14 UTC" but cannot demonstrate the exact behavioral sequence, cannot prove the agent identity, and cannot show what was observed versus what was assumed. This is not a DORA Art. 17 compliant incident report.
The .cal certificate as a DORA artifact
An H7 .cal certificate produced at the moment of detection contains every field the regulation requires:
| DORA Art. 17 requirement | .cal field |
|---|---|
| Incident timestamp | ts_ns — nanosecond precision, UTC |
| Affected ICT asset | agent_id + host |
| Detection mechanism | channel (L1–L5) + divergence measure |
| Incident evidence chain | syscall_trace — full kernel event sequence |
| Actions taken | action — alert emitted, operator notified |
| Non-repudiation | Ed25519 signature over all fields |
The signature is verifiable offline by any party — your compliance team, your external auditor, or a Notified Body — using only the published public key. No Pulsaride infrastructure is required for verification.
What "non-repudiable" means in practice
The Ed25519 signature covers the canonical JSON encoding of all fields in the certificate. A single flipped bit — in any field, in any position — invalidates the signature. This means:
- The timestamp cannot be altered retroactively.
- The agent identity cannot be changed after the fact.
- The syscall trace cannot be amended or redacted.
- The action field accurately reflects what H7 did — and what it did not do (auto-isolation).
Run this on a tampered certificate and the result is deterministic:
$ h7 cal verify-alert tampered.cal --public-key h7-cert-issuer.pub
[verify] signature: INVALIDE ✗The 6-week path to DORA-ready attestation
The H7 6-week pilot is structured specifically around producing a DORA Art. 17 ready evidence trail in your production or staging environment. By the end of Week 5, you will have:
- A populated
incident-<date>.calbundle from a real (synthetic) breach episode in your environment - A DORA Art. 17 incident report template populated with your actual agent fleet identifiers
- A signed audit package (manifest +
.calsidecars) reviewed by your compliance team
The August 2026 EU AI Act high-risk provisions add a parallel requirement for runtime audit trails. A single H7 deployment satisfies both: the same .cal bundle maps to DORA Art. 17, NIS2 Art. 21, and EU AI Act Art. 9. See the full compliance mapping for the article-level field table.
Try it in 10 minutes
Clone the demo kit and reproduce the detection yourself — no cloud account, no signup.