Request access
Verdict propagation

When the verdict changes, make it flow downstream.

When a malicious email is caught and pulled, it has already copied itself into backups, archives, ticketing, shared mailboxes, and AI indexes — and every copy still reads as safe. Cascade carries the new verdict down to all of them, and proves it.

One email is delivered delivered
SOURCE · INBOX
stale verdict verdict cascading secured
The gap

Remediation stops at the inbox. The threat doesn't.

Email security tools are good at catching a malicious message and pulling it — after delivery, once they've changed their mind. But delivery is also when a message multiplies. By the time the verdict flips, copies are sitting in systems the security tool has no reach into.

Those copies keep the old disposition. The backup restores a live threat. The archive hands it to an auditor. The AI assistant retrieves it as a trusted source. Nobody told them the verdict changed — because nothing was built to.

Why guard

The backup doesn't just store the threat. It puts it back.

Every other copy sits still. This one comes back. A restore is the one system that re-delivers a message into the live mailbox — unread, clickable, and carrying the verdict it had before anyone changed their mind.

The sequence is ordinary, which is what makes it dangerous. An attacker seeds phishing over weeks. Some of it is caught and pulled. Later they land something real — bad enough that the mailbox gets restored from backup, or a retention hold reaches back into the archive. That snapshot was taken before the cleanup. So the restore faithfully returns every malicious message the security tool had already removed.

The remediation is undone. Nothing alerts, because nothing was built to watch the restore path — the backup is doing exactly what it was bought to do. The user opens a message they were already protected from, delivered this time by the recovery tool.

01 / PULLED

The verdict flips

The security tool removes the message from the inbox.

02 / RESTORED

The backup hands it back

A recovery from backup or archive returns the message: live, unread, clickable.

03 / CAUGHT

Cascade sees the return

It re-checks what came back against every verdict it holds.

04 / CLEARED

Pulled again, on the record

The reintroduced copy is removed, and the action is written to the disposition record.

You can't fix this inside the backup. Backups are immutable on purpose — that immutability is the product. So Cascade doesn't fight the backup. It guards the door the backup opens: watching the restore path, re-evaluating what re-enters against the current verdict, and acting on what shouldn't have come back.

The approach

A control plane for the changed verdict.

Cascade is vendor-neutral. It takes a verdict from whatever security stack produced it, finds every place the message went, and applies the strongest action each of those systems will accept — then records what it did.

01 / MAP

Find every copy

Trace the message across mail, backup, archive, ticketing, file stores, and indexes — by identity, not by keyword.

02 / PROPAGATE

Carry the verdict

Apply the strongest action each system accepts — remove, restrict, tag, or flag — reversibly, never destructively.

03 / PROVE

Show your work

Produce a disposition record: what was found, what was done, and where — an answer for the audit, not a guess.

Early access

Built for the teams who own the aftermath.

Cascade is in early development with design partners. If you run security for an organization — or for other organizations — and this problem is familiar, we'd like to talk.

We read every request.