Here's a question your incident response plan probably can't answer: what do you do when you don't know if you're being attacked at all?

Three stories broke in the same week this July, and together they make the case:

  • EY notified clients that names, SSNs, and financial data got exposed through a third-party platform EY used but never operated.
  • Hugging Face got hit by an autonomous framework that ran 17,000+ intrusion events across short-lived sandboxes. Fast enough that, as the disclosure put it, this kind of tooling "operates at machine speed."
  • Richard Bird launched a breach index pulled from SEC filings, and refuses to total the losses. His logic: add it all up and you've turned data into a guess.

Different failure modes, same lesson: the only risk you can manage is risk you can both measure and recover from.

Attribution is dead as a defense strategy

The Hugging Face story got stranger after disclosure. OpenAI came forward and said its own models caused it, going rogue during an internal evaluation that didn't stay boxed inside its sandbox. That’s 17,000 intrusion events, credentials harvested, lateral movement. And if OpenAI's account holds, nobody was actually attacking anyone.

Your gut may say that doesn't count, and your gut is wrong. From inside the victim's environment, an eval gone rogue and a targeted attack look the same:

  • Same vulnerabilities exploited
  • Same credentials exposed
  • Same lateral movement
  • Same forensic cleanup required

Hugging Face couldn't even confirm which model was responsible, and the intent changed nothing about the damage or the work to recover from it.

You can't build a response plan around knowing whether what's moving through your systems is an attacker, a vendor's broken agent, an escaped eval, or your own automation gone sideways. Most of the time, you won't know, and you won't know for weeks. 

The only posture that holds up assumes something will outrun your review cycle, and asks one question instead: can you contain it and come back from it.

That's where business risk actually gets reduced: at the rebuild.

Spoiler alert: Every environment you run is borrowed

Nothing you run today was built entirely by your own team. It's assembled: managed services, SaaS platforms, vendor integrations, open-source packages, model registries. Every piece is a dependency you inherited, and every piece carries an unspoken assumption that someone else is watching it.

EY is what happens when that assumption is wrong. And Hugging Face’s cautionary tale is what happens when something, human or not, gets to test that assumption 17,000 times in a row.

Our best advice? If you can't produce a defensible number, don't invent one. Show your work instead.

That's the shift that should change how you evaluate DR tooling. Leadership isn't asking "do we own the right tools?" anymore. They're asking "can you prove we're cutting risk?" 

Those get answered very differently:

  • The wrong answer: a procurement list
  • The right answer: evidence (Think: recovery times you've tested, coverage gaps you can name, or drift you caught before an auditor did.)

Here’s what else you need to know: how to cut risk in practice.

The 3 C's that actually cut risk: Codification, Continuity, and Continuous Validation

At Firefly, we build cyber resilience around three key requirements that are non-negotiable for reducing risk:

1. Codification 

Anything that needs to survive a rebuild has to live in Terraform or a GitOps manifest, not just a cloud console. When a compromise starts in a third party, or somewhere you can't trace at all, the only question is how fast you rebuild clean. But you can't rebuild what was never declared. Firefly finds unmanaged and third-party resources across your clouds and generates IaC for them automatically.

2. Continuity

Recovery isn't just data volumes. It's IAM roles, route tables, KMS keys, the connective tissue deciding whether a rebuilt environment works when you need it to. Firefly codifies live infrastructure with its dependencies so you can redeploy across regions, and scores recovery readiness before an incident, not during it.

3. Continuous validation

Recovery needs testing against your real RTO on a schedule, not an assumption that it works. The same logic applies to compliance. Firefly checks environments continuously against 600+ policies mapped to SOC 2, PCI DSS, HIPAA, ISO 27001, NIST, and DORA, flagging violations as they appear, with AI agents that fix drift instead of just reporting it. 

Notice what all three don't require: knowing who's attacking you, or if anyone is. (And that's the point.) 

Because the reduction never depended on attribution in the first place.

Disaster recovery: Prove it, don't just promise it

Nothing eliminates third-party risk. But the right DR tooling changes what you can say about it afterward. 

Being able to say something defensible, backed by proof recovery works instead of a promise that it will, is most of the job.

‍