Security teams spend a lot of time thinking about how to detect and contain an attack. Recovery asks a harder question: what can you still trust?
Once an incident is contained, the business wants systems back online. The security team has to choose a recovery point, and that choice depends on knowing when the compromise began and what changed after it. That has always been difficult. AI makes the uncertainty more consequential because it can compress far more activity into far less time, often through the same credentials, tools and workflows that legitimate users rely on.
For example, a stolen credential can look like a normal sign-in. A rogue admin account created through a legitimate workflow can look like routine provisioning. A burst of malicious file changes can blend into a migration or other high-volume activity.
The OpenAI-Hugging Face incident this summer is useful because it shows what machine-speed activity can look like, even though it was not a conventional criminal attack.
During internal cybersecurity evaluations with reduced safeguards, OpenAI reported that models circumvented isolation controls, gained internet access and compromised parts of Hugging Face’s systems. A later analysis by Hugging Face reconstructed roughly 17,600 actions over several days. At that scale, investigators have to work out which of those thousands of actions actually changed the security state of the environment, such as a new account, a granted permission or a modified policy.
That has direct consequences for recovery. Most plans assume the team can identify roughly when the compromise began, what the timeline for the attack and individual actions was, and restore to a pristine state from a snapshot taken before that point. But if the attack timeline is an estimate and understanding of actions incomplete, the restore is an estimate too. You can potentially bring back the initial vulnerability or weakness, attacker’s persistence mechanism via the compromised account, token, permission change or even the infection with encrypted data.
An alert tells the team where to start investigating. Before anyone chooses a recovery point, that investigation has to produce evidence of what changed, how far the compromise spread, what can still be trusted, and which snapshot predates the compromise timeline.
Start with identity, even if identity was not the entry point
Identity does not have to be how an attacker first got in to become central to recovery. Once inside, attackers often use accounts, tokens, roles and permissions to expand access and maintain persistence.
Before restoring, I would want clear answers to a few questions:
- Which identity was used, and was it a person, a service account or an AI agent?
- If an agent was involved, was that authority explicitly delegated to it, or did it inherit the access of whoever launched it?
- Were privileges escalated, new accounts created, OAuth consents granted or policies changed?
- What else did that identity touch, and where did it go next?
Getting those answers requires a history of how identities and permissions changed over time.
Risk often appears as a sequence: a permission changes on Monday, a new service account appears on Tuesday, and a conditional access policy is loosened on Thursday. Correlating evidence helps reconstruct the timeline of events.
During recovery, that is what identity resilience has to deliver: not another alert, but the ability to show how access changed and what needs to be reversed.
Establish a trusted pre-attack state
“Clean” is not just a date. It is a state you can defend with evidence.
A snapshot taken before encryption began can still contain an attacker-created account, a compromised token or a weakened access policy introduced days earlier. Teams need a version history of the environment, including identity and security configuration, stored separately from the production systems involved in the incident.
With that history, investigators can compare the current state with earlier points in time, identify the changes associated with the compromise and decide whether to restore an earlier state or reverse only specific unauthorized changes.
Data needs the same scrutiny. Ransom notes, unusual file extensions and mass renaming are useful indicators, but legitimate work can create similar patterns. Before restoring, teams should validate what those signals mean by inspecting the data itself and comparing it with earlier known-good versions. That is how you separate suspicious activity from confirmed impact and identify the most recent copy you can trust.
Validate the recovery point before you restore
Before restoring, the team should be able to document three things:
The scope of the identities, configurations and data affected by the compromise.
The containment actions already completed, such as revoking tokens, removing unauthorized accounts and reversing malicious permission changes.
The recovery point selected, the evidence that supports it and any remaining uncertainty.
If the team cannot do that, I would not recover full operations yet.
Security teams still have to take the business pressure seriously. There may be situations where leaders choose to restore before every question is resolved. But that should be an explicit risk decision, not an assumption that the newest available backup is probably fine.
There is one more check teams often miss: what should exist after the recovery. A snapshot can contain the right data and still reintroduce an account, token or permission that was deliberately removed during containment. Recovery plans have to account for identity state as well as data state.
The question to ask now
Every security leader should be able to answer this before the next incident: if we had to recover systems and data from an attack today, what evidence would show us that the identities, configurations and data we are bringing back can be trusted?
AI will keep compressing the time between access and impact. It does not change the basic requirement for recovery. It raises the cost of guessing. If the answer is a timestamp and a hunch, there is still a gap in the recovery plan.
Join our LinkedIn group Information Security Community!
