Frontier AI cleared every OT attack goal Booz Allen set in its lab

AI reached every goal on its own

Booz Allen Hamilton built an isolated testbed that mirrors a real operational-technology environment: PLCs, SCADA systems, human-machine interfaces and a robotic arm ^[1]. The firm then gave frontier AI models access to the network and set them eight objectives. The models completed all of them, autonomously ^[1].

The objectives included reconnaissance, exploiting known vulnerabilities, privilege escalation and taking control of the robotic arm. At no point did a human guide the models or write code for them. They searched documentation, adapted to what they found and moved through the network on their own ^[1].

It's a bit like giving someone a locked building, a toolkit and a list of rooms to reach, and coming back to find every door open and every light switched on.

What the demonstration showed

The testbed was isolated, so nothing was at risk. The vulnerabilities were known ones, not zero-days. The models didn't invent new attack techniques; they applied existing ones effectively ^[1].

What matters is that they did it without instructions. Operational technology has historically been harder to attack than IT systems, partly because OT networks are less standardised and require specific knowledge of industrial protocols. Frontier AI models now have that knowledge, or can acquire it as they go ^[1].

The demonstration isn't a proof that AI will autonomously attack real systems. It's a proof that it can.

The evidence question when an incident happens

When an OT system is compromised, three questions come quickly. What happened, when did it start, and who did it?

If the attacker is an AI acting on someone's behalf, attribution gets harder. Logs show commands and access, but they don't always show intent or who gave the instruction. If an AI agent is involved, the organisation running it may not know what it did until afterwards.

Under the Swedish Cybersecurity Act, essential and important entities must report significant incidents: an early warning within 24 hours, an incident notification within 72 hours and a final report within a month ^[2]. The clock starts when you become aware of the incident, not when it suits you ^[2].

That makes the logs the starting point. If they've been edited after the event, even by someone with the right access, questions follow.

How a digital witness helps here

A digital witness seals log records as they are written, so you can later show they haven't changed.

Here, the thing to seal is each entry in the OT system's access log and SCADA event log, or segments of logs at short intervals, for example every few minutes. Sealing takes a fingerprint of the record, not the record itself, so the log stays in your systems. If an incident is investigated months later, anyone you share the log with can check that it's the one written at the time.

Your organisation sends a fingerprint to WitniumChain through the REST API, the SDK or the MCP server, and gets a witness ID back. To check, anyone calculates the fingerprint again and compares it with the sealed one. The first 2,000 witnesses a month are free. Read the docs.

A witness doesn't show that the log is complete, or that your response was adequate. It shows that the records you kept are the ones written on the day, unchanged since.

How it would work

1. Your SCADA system or log collector sends a fingerprint of each closed log segment to the witness.
2. When an incident is reported, you share the sealed logs with your CSIRT, the regulator or an investigator.
3. They calculate the fingerprint of what you've given them and check it against the sealed one. If it matches, nothing has changed.

What this means for you

If you run OT systems, or advise organisations that do, here are three questions worth asking now.

Can you show what was logged during an incident, in a way that holds up when questioned? Access controls and monitoring are the foundation, but they don't prevent someone with administrator rights from editing a log after the fact. A witness per log segment does.

If an AI agent or model touches your OT network, do you log what it does? Frontier models can act autonomously, so the instruction and the action may not be close together in time. Logging each step makes it possible to reconstruct what happened.

When the 24-hour reporting deadline starts, can you show when you first became aware of the incident? Sealing the detection note and each escalation step as it happens gives you a timeline nobody can quietly rewrite.

What to watch

The Cybersecurity Act's reporting deadlines have applied since 15 January 2026 ^[2]. The early warning is due within 24 hours of becoming aware, not of deciding the incident is significant.

Booz Allen's demonstration was published in October 2026 ^[1]. Expect more demonstrations, and more questions about how to attribute actions when AI is involved.

If your sector falls under the Cybersecurity Act, check now whether your logs would hold up if questioned. Frontier AI can reach objectives on its own. Proving what happened afterwards is still your job.