TL;DR: Cayosoft says Gartner named it a Sample Vendor in Identity Recovery and AI Agent Action Rollback, highlighting a shift from prevention-only identity security toward precise restoration of changed roles, permissions and policies. That shift matters because recovery controls must now handle human errors, ransomware and autonomous agent actions without restoring unrelated state.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Cayosoft's research: Identity recovery is moving from backup-centric restoration to precision rollback for directory changes, including those made by AI agents.
Why it matters: IAM and PAM teams need recovery processes that can isolate and reverse only the affected identity state, because prevention controls do not stop every bad change and point-in-time restore can amplify blast radius.
By the numbers:
- By 2030, 70% of organizations will prioritize the recoverability of identity systems alongside preventive IAM controls, up from less than 15% in 2026.
Context
Identity recovery is not the same as restoring files or servers. The control problem is preserving trust in directory state after a bad change, whether that change came from a human administrator, a script, or an AI agent. Traditional backup tools tend to restore snapshots, but identity teams need to understand which permissions, memberships, policies, or authentication settings actually changed.
As AI agents are granted delegated access inside business systems, the recovery question becomes sharper. If an agent can alter directory objects, access packages or app role assignments, identity teams need a way to identify the exact window of impact and restore only what is contaminated. That is why recovery planning now sits beside prevention, not behind it.
Key questions
Q: How should teams handle identity recovery after a malicious directory change?
A: Identity recovery after a malicious directory change should restore exact objects, memberships, permissions, and policy state from a known-good baseline, not just the whole directory. The plan needs authoritative change logs, tiered backups, and a controlled reapplication of admin roles, group nesting, and service account bindings so the attacker’s changes are removed without reintroducing stale access.
Q: Why does point-in-time restore often fail for identity incidents?
A: Point-in-time restore often fails for identity incidents because directory state is not just data, it is access state. A restore can bring back deleted accounts while also resurrecting compromised group membership, delegated admin rights, or outdated secrets. A change-aware approach compares the restored state with current entitlements and replays only trusted identity changes.
Q: How do AI agents change identity rollback requirements?
A: AI agents raise rollback requirements because their delegated access is often wider, more dynamic, and tied to runtime tool permissions rather than a single account. Recovery must identify the agent, its human owner, its issued tokens, and every permission grant to APIs, data stores, and orchestration systems, then revoke or replace them in the right order.
Q: What should an identity recovery plan prove before an incident?
A: An identity recovery plan should prove that you can restore authentication, privilege and ownership after a compromise without relying on the affected directory, secrets store or admin account. It should document break-glass access, offline backups, rotation of API keys and certificates, and a tested path to re-establish control outside the failure domain.
Technical breakdown
Why point-in-time restore is too blunt for identity systems
Identity systems are stateful in a way that file systems are not. A single directory change can alter authentication, authorisation, group membership, policy enforcement and downstream application access. Point-in-time restore can recover the state of the directory, but it cannot tell you which of hundreds of intervening changes were legitimate and which were malicious or mistaken. That creates a recovery dilemma: restore too far and you lose valid work, or restore too little and preserve the intrusion. The architectural issue is not backup availability. It is recovery granularity. See the AI Agent Authorisation Guide.
Practical implication: Design identity recovery around object-level and attribute-level rollback, not only whole-environment restoration.
Why AI agents complicate recovery history
AI agents can create identity state changes through delegated permissions, app role assignments, access packages and group memberships without holding the kind of standing privileged role that normally draws attention. Their actions may arrive quickly and in volume, but the directory only sees changes to objects and attributes. That means recovery teams need change history precise enough to attribute the impact window even when the actor is non-human. The harder problem is not that agents behave differently from admins in the directory. It is that they can create the same kind of recoverable state at machine speed. See the Agentic AI Identity Guide.
Practical implication: Track non-human identity activity with the same change-history fidelity you expect for privileged administrators.
How recovery isolation keeps rollback executable
Recovery fails when the recovery path depends on the same directory, credentials or management plane that has been compromised. If the console signs into the broken environment, or the backup repository is reachable with production credentials, the restore path inherits the incident blast radius. Effective identity recovery therefore needs isolation, validation and a clean execution path that survives the primary compromise. Rehearsal matters for the same reason: a recovery method that has never been tested is only an assumption about safety, not an operational capability.
Practical implication: Separate recovery infrastructure from production identity dependencies so rollback remains usable during a directory outage.
Breaches seen in the wild
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Identity recoverability is becoming a first-class control, not a backup afterthought. Directory state now carries business continuity, access integrity and audit trust all at once. When identity fails, applications fail with it, so recovery has to be measured by how precisely it can restore trust, not by how quickly it can restore volume. Practitioners should treat identity recoverability as part of the core control stack, not a separate storage exercise.
Point-in-time thinking breaks down when directory state includes both legitimate and malicious change. A restore point is only useful if the team can separate intrusion from normal administration inside the same change window. That is the governance gap: backup systems preserve the whole history, but identity teams need a trusted way to identify which objects, attributes and policies belong to the incident. Practitioners should assume the most recent backup may also contain the compromise.
AI agent action rollback is an identity governance problem before it is a recovery feature. Agents that act through delegated permissions create recovery scenarios without requiring a privileged directory account of their own. That means the control assumption that a human operator is always behind the change no longer holds. Task-scoped identity authorisation becomes part of recovery design because the same delegated access that enables the action also determines what must be reversed.
Recovery blast radius is now part of identity architecture design. If restoration depends on the compromised directory, the recovery path is already broken. Teams should design for clean standby environments, independent credentials and validation paths that survive the outage. The practical conclusion is simple: a restore plan is only credible if it can be executed from outside the failure domain.
Granular rollback is the named capability that will separate mature identity programmes from reactive ones. The field needs a more precise concept than generic backup, because identity incidents rarely require full rebuilds. Organizations that can reverse only the affected identity state will preserve more legitimate work, recover faster and reduce unnecessary disruption. Practitioners should make that granularity the benchmark for identity recovery maturity.
From our research library:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
- Read next: AI Agent Authorisation Guide
What this signals
Granular rollback will become the default expectation for identity operations. Teams that still think of recovery as a full snapshot restore will keep losing legitimate changes every time they try to fix a directory incident. The operational shift is toward recovering the affected object, attribute or policy rather than the entire environment.
Identity recovery and AI governance are converging on the same issue: trust in state after delegated action. When a human, script or agent can all modify the same objects, the programme needs a way to prove what changed and why. That creates pressure to integrate recovery telemetry, access governance and change attribution instead of running them as separate disciplines.
By 2030, 70% of organizations will prioritize the recoverability of identity systems alongside preventive IAM controls, up from less than 15% in 2026, according to the 2026 Infrastructure Identity Survey. That trajectory suggests the market is moving away from prevention-only identity thinking and toward operational resilience built around reversible change. Practitioners should expect recovery capability to become a board-visible requirement, not just an admin convenience.
For practitioners
- Define the identity recovery blast radius Map which directory objects, attributes, group memberships, policies and authentication settings must be reversible without restoring the entire environment.
- Separate recovery from production dependencies Keep recovery consoles, backup repositories and standby forests outside the same credentials and management plane used for day-to-day administration.
- Validate recovery points before restoring Confirm that a restore point does not reintroduce privilege escalation, stale permissions or reinfection before any rollback is executed.
- Extend change history to non-human actors Record agent-driven changes with the same attribution depth used for privileged administrators so recovery teams can isolate the correct incident window.
- Rehearse object-level and forest-level recovery Test both small-scope rollback and catastrophic directory restoration so the team can prove which recovery mode fits each incident class.
Key takeaways
- Identity incidents are different from ordinary data restores because directory state encodes permissions, policy and trust as well as content.
- The clearest evidence in the source material is the shift from less than 15% today toward 70% prioritising identity recoverability by 2030.
- Practical resilience now depends on precise rollback, isolated recovery paths and change attribution for both human and non-human actors.
Related NHI Mgmt Group resources: AI Agent Authorisation Guide · AI Agent Observability, Audit and Incident Response Guide · Agentic AI Identity Guide · Agentic AI Security Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Identity recovery must account for excessive delegated permissions that widen rollback scope. |
| NHI-03 — Vulnerable Third-Party NHI | Agentic and delegated access paths can behave like third-party identities inside the directory. | |
| Recommendation — Review delegated access and reduce overprivilege before recovery depends on it. Inventory delegated non-human access paths and isolate those that can alter directory state. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent-driven directory changes illustrate how delegated privileges can be abused at runtime. |
| Recommendation — Constrain agent privileges to the minimum needed for each task and monitor changes they make. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centers on restoring permissions, entitlements and authorizations to a trusted state. |
| Recommendation — Restore entitlements and permissions from validated state rather than restoring everything indiscriminately. | ||
| MITRE ATT&CK | TA0003;TA0004;TA0008 — Persistence; Privilege Escalation; Lateral Movement | The recovery problem follows attacker persistence and privilege movement inside directory state. |
| Recommendation — Map directory tampering to persistence, escalation and lateral movement to scope detection and rollback. | ||
Key terms
- Identity Recovery: Identity recovery is the process of restoring identity systems to a trusted state after compromise. It includes containment, forensic validation, removal of persistence, and confirmation that access controls and directory relationships no longer expose the environment.
- Granular Rollback: Granular rollback is the selective reversal of specific identity or directory changes instead of restoring an entire system. It is used to undo a limited set of objects, group memberships, permissions, or policy edits while preserving trusted changes, which helps avoid reintroducing old access states.
- Standby Forest: A standby forest is a pre-built, separate Active Directory environment that can take over recovery when the primary directory is unavailable or compromised. It is maintained in advance so identity services can be restored without rebuilding the directory from scratch during an outage.
- Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on November 4, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org