Chainalysis breach shows the evidence gap when *AI agents attack*

What happened

On 28 March 2025, Chainalysis, a blockchain analytics firm whose tools are used by law enforcement and financial institutions, disclosed a security incident ^[1]. According to reports, attackers used what the company called 'offensive agentic techniques'—AI agents designed to probe systems, find vulnerabilities and exploit them ^[2].

The details are thin, but the pattern is familiar: an attacker gets in, moves around and leaves. What's new is the tool. Traditional attack tools run scripts someone wrote in advance. AI agents write their own.

The evidence gap

Think of it like this: if someone breaks into a warehouse, you check the CCTV. If the burglar brought a robot that learned as it went, worked out which door was easiest and changed its approach when the first attempt failed, the CCTV shows a robot moving, but not what it was thinking or why it chose that door.

That's the evidence gap with AI agents. A human attacker leaves a trail: attempted logins, file access, commands run. An AI agent generates the commands, tests them and adapts in real time. Unless you log what it tried, why it tried it and which approach worked, the log just shows that something happened.

The question for anyone running systems that matter is whether your logging would capture that.

What the rules require

Three pieces of regulation put pressure on logging and incident response.

DORA, which has applied to financial firms since January 2025, requires logging routines that protect log systems and log information against tampering, deletion and unauthorised access ^[3]. The technical standard doesn't say how, but it does say the logs must be protected.

The Cybersecurity Act, Sweden's implementation of NIS2, applies from 15 January 2026 to essential and important entities in 18 sectors ^[4]. It requires early warnings within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours and a final report within a month. The clock starts when you knew, not when it suited you.

The Cyber Resilience Act applies from 11 September 2026 to makers of connected hardware and software, excluding medical devices and type-approved vehicles ^[5]. Article 14 requires manufacturers to report actively exploited vulnerabilities and serious incidents through ENISA's common platform, with similarly tight deadlines.

All three rely on logs. If an auditor, a supervisor or a court asks what happened, the log is the first place everyone looks. A log you can quietly rewrite is a diary. A log you can prove hasn't changed is evidence.

What makes agent-driven attacks harder to prove

AI agents don't follow a script. They generate one. Say an agent is told to find a way into a system. It might:

• scan for known vulnerabilities,
• try different payloads and see which ones get through,
• adapt its approach based on the responses,
• use one successful entry to explore further.

Each step generates new commands. A traditional intrusion detection system flags known attack patterns. An AI agent can generate patterns nobody has seen before.

That's why logging what the agent tried matters. If you only log what succeeded, you miss the fifteen attempts that failed and taught it what to do next. The full picture of the incident—what was tried, what worked and how the agent adapted—only exists if your logging captured it.

What this means for you

If you're responsible for systems covered by DORA, NIS2 or CRA, here are three questions worth asking your technical teams this week:

1. Do our logs capture enough detail to show what an AI-driven attack tool tried, not just what succeeded?
2. Could someone with administrative access edit a log after an incident, and would we be able to show they hadn't?
3. If we had to send an early warning within 24 hours, do we have the records to back it up a year later?

The regulations set the deadlines and the consequences. The logging is what lets you meet them.

How a digital witness fits here

This is exactly the kind of case where sealing log segments continuously makes the difference.

Here's what you seal: log segments at short intervals, say every few minutes, as each segment closes. The fingerprint goes to WitniumChain through the REST API, the SDK or the MCP server, and you get a witness ID back. The logs themselves stay in your systems.

When an incident is investigated, internal audit, supervisors or incident responders can check whether a log segment has changed since it was sealed. Calculate the fingerprint again, compare it with the sealed one, and any change shows up—even one made by someone with administrator rights.

What it shows: that the log segment is exactly what was written at the time it was sealed, unchanged since.

What it doesn't: it doesn't replace access control, monitoring or backups, and it doesn't show that the logging was complete or that the response was adequate. It just makes sure the logs you have are the ones you can rely on.

The first 2,000 witnesses a month are free. Integration takes an afternoon, not a quarter.

What to watch

• 15 January 2026: the Cybersecurity Act enters into force, bringing the 24-hour early warning deadline for essential and important entities.
• 11 September 2026: the Cyber Resilience Act starts to apply, with reporting duties for manufacturers.
• Standards on AI incident reporting are still being developed under the AI Act; expect guidance from the AI Office on what counts as a serious incident and what logs are expected.

By the time those dates arrive, it's too late to decide your logging wasn't detailed enough. The time to ask that question is now, before the next incident.