The first thing an attacker deletes is the logs

Ask any incident responder what they find first, and the answer is often the same: nothing. The logs for the critical window are gone, cleared, truncated, or quietly edited. Erasing the record is not an afterthought of an intrusion. It's step one.

Attackers understand something defenders sometimes forget: the log is the only account of what happened, and whoever controls the log controls the story. Clear the event history, and the investigation starts blind. It's why "clear logs" sits near the top of nearly every intrusion playbook, right after gaining access.

This was always a problem. What makes it urgent now is that a second actor has entered the same picture, your own AI.

Two questions now collide

Security operations are handing more and more decisions to AI: triaging alerts, enriching cases, isolating hosts, disabling accounts, and increasingly, taking autonomous response actions. That's a genuine force-multiplier for stretched teams. But it changes what you need to be able to prove after an incident. You now have to answer two questions at once:

• What did the attacker do? The classic forensic question.
• What did our AI agent do? Which host did it isolate, which account did it disable, on what signal, and was that the right call?

Both answers live in the same place: your logs. And in an adversarial setting, ordinary logs are exactly the wrong place to keep the one record you cannot afford to lose.

If your evidence can be edited by whoever breached you, it isn't evidence. It's a story they get to rewrite.

Why mutable logs fail under attack

Standard logging assumes a cooperative environment. An intrusion is the opposite. Three failure modes show up every time:

1. Deletion looks like silence

When an attacker wipes a window of logs, what's left behind is an absence, and absence is deniable. You can't tell a quiet period from a scrubbed one. There's no built-in signal that says "records are missing here."

2. Edits are invisible

A sufficiently privileged intruder doesn't have to delete anything. They can change a timestamp, drop a line, alter a field, and nothing about a plain log proves it wasn't always that way. Tampering leaves no fingerprint.

3. Your AI's actions are trapped in the same fragile record

When the account of your autonomous agent's actions lives in the very logs an attacker can reach, you lose the ability to cleanly separate "what the attacker did" from "what our automation did in response", precisely when that distinction matters most.

The shift: from mutable logs to tamper-evident records

The defensive answer isn't more logging. It's records that are built to survive an adversary. Instead of appending a mutable line, each significant event, an attacker-relevant action or an AI agent's decision, is captured as a signed, hash-chained receipt:

Two properties change the game in an adversarial setting:

• Tampering becomes detectable. Each receipt is cryptographically linked to the one before it. Alter a past record and every later verification fails; remove one and the chain has a hole that proves something was taken. Deletion stops being deniable.
• The record is independently verifiable. A receipt checks out with a public key alone, no trust in the compromised system required. An investigator, an auditor, or an insurer can confirm what happened without taking your word for it.

Why this matters more as agents get more autonomy

Every step toward autonomous defense raises the stakes on the record. An AI that only surfaces alerts is low-risk to get wrong. An AI that isolates production hosts, revokes credentials, or blocks transactions is making consequential calls, and each one needs a tamper-evident account for detection, forensics, and control. When individual actions each look legitimate, misuse and drift stay invisible until the damage is done. A verifiable trail is how you catch them.

The teams thinking clearly about this treat the evidence layer as part of the security architecture, not a reporting afterthought, because the one record you'll wish you had is the one an attacker made sure you didn't.

This article is general information, not security or legal advice. Evaluate any control against your own threat model before relying on it.