When an AI Agent Breaks In: What Cathedral's Alleged Hack Shows About Autonomous Risk

What happened

According to the AI Incident Database, Cathedral Intelligence, a cybersecurity firm, reportedly deployed AI agents to exploit third-party software vulnerabilities and gain unauthorised access to internal systems at Anthropic, the AI developer behind Claude ^[1]. The details are sparse, but the pattern is clear: an AI system acted autonomously to find weaknesses and get in.

That's faster than a human penetration tester, and harder to follow in real time. When an AI agent runs on its own, the people who set it loose often can't say exactly what it did until they look at the logs afterwards—if the logs are complete and trustworthy.

The reporting clock

Under the Cyber Resilience Regulation, which applies from 11 September 2026, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents through ENISA's common platform ^[2]. The early warning is due within 24 hours of becoming aware, not 24 hours from when it suits you.

For the organisation on the receiving end, Sweden's Cybersecurity Act, which entered into force on 15 January 2026, sets three deadlines: an early warning within 24 hours, an incident notification within 72 hours and a final report within a month ^[3]. That's the same rhythm as NIS2.

Those deadlines count from awareness, which is a bit like when you notice you've lost your bank card: the clock starts when you realise, not when the card was actually taken. So proving when you first knew matters, especially if a supervisor or an insurer later asks why the early warning came in after 30 hours instead of 24.

The agent's black box

AI agents are built to act: they call tools, make decisions and change things. That's the point. The difficulty is that once an agent starts, it can move through systems faster than a human can narrate. By the time someone asks what it did, the agent may have called dozens of APIs, accessed files, altered configurations or deleted traces.

A log of agent actions is the natural answer, but logs kept by the same people who ran the agent—or by the agent itself—are easy to question. When something goes wrong, the other side will ask whether the log is complete and whether anyone quietly edited it to make the agent look better, or worse.

Think of it like a car's dashcam: useful as long as nobody doubts the footage, but harder to rely on if the driver keeps the recording and could have trimmed the file.

What to seal, and when

Here, two things matter: the incident timeline and the agent's own actions.

The incident timeline

When an intrusion happens, you need to show when you first detected it, when you escalated it internally and when each report went out. Sealing the detection note, the escalation decision and each report as it is sent gives you a record nobody can rewrite afterwards. The content stays with you; only a fingerprint goes to WitniumChain through the REST API, the SDK or the MCP server. To check it later, anyone you share the record with calculates the fingerprint again and compares it with the sealed one. If the record has changed—even by someone with administrator rights—the fingerprint won't match.

That doesn't show the report was complete or the response adequate, but it does show when each step was recorded. Supervisors, auditors and insurers can check it themselves. The first 2,000 witnesses a month are free.

The agent's actions

For AI agents, the thing to seal is each instruction the agent received, each tool it called and each result it got back. You seal those as the agent acts. Say an agent changes a customer's standing order and the customer later says nobody asked it to. A sealed record of the instruction, the tool call and the confirmation shows what the agent did and when, in a way that holds up even if the agent's operator could have altered the log.

The MCP server fits here. It seals agent actions as they happen, without adding a step for the developer. The agent gets a witness ID back with each action, and that ID can be logged alongside the action itself.

Sealing doesn't authorise the action or make it correct. It doesn't replace monitoring or access controls. What it does is let you show that the record of what the agent did hasn't changed since it was sealed, which turns out to matter when someone questions whether the log tells the whole story.

What this means for you

If you build or operate AI agents, or if you manufacture connected products, here are three questions to ask this week:

• When an incident happens, can we show when we first knew about it and when each report went out?
• If an AI agent acts on its own, do we have a checkable record of what it did, or just the agent's own log?
• If a customer, a supervisor or a court asked for proof that a log or a timeline hasn't been altered, what would we send them?

What to watch

The Cyber Resilience Regulation's reporting duties apply from 11 September 2026. Sweden's Cybersecurity Act has been in force since 15 January 2026, and the first deadline reports under it are already being filed. AI agent frameworks are moving fast, but the regulations on accountability haven't caught up yet.

Cathedral's alleged breach is one incident in a database that now holds hundreds. The pattern is the same each time: by the time someone asks what happened, the only evidence left is the log, and the question becomes whether anyone can trust it.