Stolen AI access leaves companies with *cloud bills of up to $1 million*

The fraud that runs on autopilot

It's the sort of thing that sounds like a prank until the invoice arrives. Someone logs into your cloud account with credentials they lifted from a config file or a phishing attempt, spins up a few powerful instances, points them at a large language model and leaves them running. You get a bill for compute time you never asked for, often running into six figures before anyone notices.

Think of it like someone breaking into your office, finding the company credit card and ordering a few lorries' worth of server time to their own specification. The card works, the order goes through and the supplier doesn't ask questions, because as far as the system can tell, you placed the order.

Google and Mandiant call it LLMJacking ^[1]. The pattern is simple: attackers compromise cloud credentials, use them to run resource-intensive AI workloads and vanish before the organisation spots the unusual activity. In documented cases, daily costs have exceeded $100,000, with total exposure reaching $1 million ^[1].

The sectors hit include financial services, retail and technology. The attackers' motives vary, from cryptocurrency mining to running their own AI models on someone else's infrastructure ^[1].

Two problems, one compromise

The immediate problem is the bill. The slower problem is the evidence.

When the finance team asks what happened, IT has to explain which systems were used, what they ran, who asked for it and when it started. That means looking at logs: access logs, compute logs, API call logs. The question that follows is whether those logs can be trusted.

Logs live on systems controlled by the people being asked to produce them. If an attacker had the credentials to launch instances, they may have had the access to alter the logs as well. Even if they didn't, the question hangs in the air: could someone with the right access have quietly edited the record?

For regulated firms, the stakes are higher. DORA's technical standard on ICT risk management says logs must be protected against tampering, deletion and unauthorised access ^[2]. The Swedish Cybersecurity Act, which implements NIS2, requires an early warning within 24 hours of becoming aware of a significant incident ^[3]. The clock starts when you know, not when it's convenient, and the report has to explain what happened.

That explanation rests on logs you can stand behind.

The gap between keeping logs and proving them

Most organisations log plenty. Access control, monitoring and off-site backups are standard practice, and they matter. What they don't do is settle the question of whether a log has changed since it was written.

Access controls say who is allowed to read or write. Monitoring says who did. A backup says what the log looked like at a point in the past. None of them proves that the log you are looking at today is exactly what was written at the time.

When an auditor, a supervisor or an insurer asks whether the logs are intact, the answer often amounts to: we trust our own systems, and you should trust us. That works until trust isn't enough.

How a digital witness closes the gap

Here, the thing to seal is each log segment as it closes: API call logs every few minutes, access logs at short intervals, compute activity logs as they are written.

Sealing takes a fingerprint of the segment, not the data itself, so the log never leaves your systems. The fingerprint is posted to WitniumChain, where any later change to the chain would show. To check, you calculate the fingerprint of the log segment again and compare it with the sealed one. If they match, the segment hasn't changed since it was sealed. Change a single character and it won't match.

Internal audit, supervisors and incident responders can check it. You give them the log segment and the witness ID. They run the check themselves. No need to take your word for it.

A digital witness doesn't replace access control, monitoring or backups. It answers a different question: can you show that this log is the one written at the time, even to someone who doesn't have to trust you?

In an LLMJacking case, that means being able to show which API calls were logged when the compromise happened, in a form that holds up when the bill is disputed or the incident is reported.

How it would work

1. Your logging system sends a fingerprint of each closed log segment to the REST API, the SDK or the MCP server, and stores the witness ID with the segment.
2. When the logs are reviewed, the reviewer calculates the fingerprint again and checks it against the sealed one.
3. If it matches, the segment is unchanged. If it doesn't, someone has altered it.

It doesn't show that the log is complete, that the response was adequate or that the compromise was handled well. It shows that the segments you are looking at are the ones written at the time.

What this means for you

If you run cloud infrastructure or buy cloud services, here are three questions worth asking this week:

• Could we show an auditor or a supervisor which logs existed when we became aware of unusual activity, in a way they can check themselves?
• Do our incident response procedures cover how we document what happened and when, with evidence that holds up outside the team?
• If someone with administrator access wanted to edit a log after an incident, would we be able to show they had done it?

For organisations under DORA or NIS2, the deadlines are short and the expectations are high. The logs matter, and so does being able to stand behind them.

What to watch

The Swedish Cybersecurity Act's early warning deadline is 24 hours from when you became aware of a significant incident ^[3]. That means deciding early what counts as significant and having a way to show when you knew.

DORA's technical standards on ICT risk came into force on 17 January 2025 ^[2]. Financial firms are expected to have logging in place that meets the standard, including protection against tampering.

For AI systems placed on the market under high-risk rules, automatic logging applies from 2 December 2027 for Annex III systems ^[4]. The logs have to exist. Whether they can be trusted is a separate question, and one to settle before the deadline.