Remediation Reversibility and Undo
See whether a remediation action can be undone before it runs, and undo a completed one from the Remediation page.
Requires role: Operator or Admin (History tab and Undo). Admin to read a receipt's Decision Snapshot. Related: Semi-Auto Execution, Select Fire, Closed-Loop Rollback, Delegation Risk, Fix Kerberos Delegation Findings
Overview
Every remediation action carries a reversibility badge. It appears on each action row in the Select Fire™ Decision step, in the History table and on the action's receipt.
For an action that can be undone, GraphnAI saves a copy of the original state before it changes the directory. The copy is stored with the action's history record. Undo restores from that copy, so it never depends on reading an object that may have changed or been deleted since.
Undo runs through the same checked path as the original action. It doesn't build a new instruction or guess at the earlier state.
How Reversibility Is Classified
| Badge | Color | What it means | Examples |
|---|---|---|---|
| Reversible | Green | The action's opposite undoes it. No saved state is needed. | Disable user, Enable user, Block delegation, Block Entra sign-in, Require Kerberos pre-authentication, Clear unconstrained delegation |
| Reversible from saved state | Blue | Undo needs a value that can't be rebuilt later, so a saved copy of the original state is taken before the change runs. | Remove group membership, Remove the service principal name, Move to another organizational unit, Remove GPO link, Remove directory role assignment, Remove app role assignment, Remove OAuth permission grant, removing a permission entry, removing an account from a resource-based delegation setting |
| Partly reversible | Orange | Undo restores the main change, but some detail can't come back. Hover the badge to read "Undo restores the main change, but some detail can't be brought back." | Require smart card, Quarantine the account, Require a password change |
| Not reversible | Red | No undo exists for this action. | Revoke Entra sessions, Reset password, Remove the carried-over identifier |
The saved copy holds what the directory can't tell you afterwards: the exact group a member was removed from, the container a computer was moved out of, or the Entra role assignment that was deleted.
Require smart card is the common Partly reversible case. Setting it makes Active Directory replace the account's password with a random one. Undo clears the smart card requirement, but the old password is gone.
In the Decision step, Authorize is disabled for a Not reversible action, with the tooltip "A change that can't be undone isn't run from here." An action with no directory write shows a Simulate only badge instead of a reversibility badge.
Undoing a Completed Action
Prerequisites
- Operator or Admin role.
- The directory confirmed the change. The row's status reads Verified.
- The action's badge is Reversible, Reversible from saved state or Partly reversible.
- For a Full-Auto action, its rollback watch has ended. See Closed-Loop Rollback.
Steps
- Select Detection & Response > Remediation in the sidebar. The History tab opens.
- Find the action. Narrow the list with the status, action and reversibility filters.
- Select Undo at the right end of the row.
- Check the confirmation dialog. It lists the Action, the Subject, the Reversibility badge and what Undo does.
- Select Undo action. Select Cancel to change nothing.
The table sorts by Initiated, newest first. For a multi-step action, Undo does reads "Undoes each step, last first". For a Partly reversible action, the dialog adds "Undo puts back the main change. Some detail can't be restored."
After you confirm, the row's status reads Running while the undo runs, then Reverted once the directory confirms the original state. A message reports the result:
| Message | What it means |
|---|---|
| Action undone | The directory shows the original state again. |
| Undo escalated for review | The undo ran, but the result couldn't be checked. Look at the object in the directory. |
| Undo is running | The undo was sent and hasn't finished yet. The row updates when it does. |
Before the dialog opens, "Checking this change" can show for a moment. GraphnAI is checking whether this undo needs a typed confirmation.
Confirming an Undo on a Protected Object
Some changes act on protected directory objects, such as domain controllers and built-in administrator accounts. Those changes run only after a person types the object's name. Undoing one asks for the same confirmation again, because the undo gives back the access the change took away.
- The dialog. It's titled "Restore access to a protected object". It lists What this restores and names who ran the original change. Type the object's name, then select Restore access. The button stays disabled until the name matches exactly.
- Anyone with the role can undo it. Undo isn't limited to the person who ran the change. A bad change shouldn't stay in place because that person is away.
- Ordinary undos need no typing. An action that needed no confirmation to run needs none to undo.
- An old change still works. The confirmation belongs to the history record, so it doesn't go stale when the plan changes. If the object can't be found in the directory anymore, the dialog says so and uses the details saved when the change ran.
- Closed-Loop Rollback doesn't watch these changes. An automatic undo would restore protected access with nobody confirming it, so the confirmed undo is the only one.
- Only a signed-in person can confirm. An API key can't give this confirmation, whatever its role.
See Confirming a Change to a Protected Object for how the first confirmation works.
If the check itself fails, the dialog reads "Couldn't check whether this undo needs a typed confirmation. Try again." Nothing is undone.
When the Undo button is disabled
Hover the disabled Undo button to read why.
| Tooltip | What it means |
|---|---|
| This action has already been reverted. | The undo already ran. |
| An undo is already running. | Wait for it to finish. |
| Undo is available after the rollback watch ends. | A Full-Auto action is still inside its watch window. |
| An action escalated for review can't be undone here. | Open the receipt to see why. Reverse the change in the directory with your own tools. |
| Undo is available once the directory confirms the change. | The action is still running, waiting for the bridge, or not verified yet. |
| This change can't be undone. | The action's badge reads Not reversible. |
| There's no saved copy of the original state to undo from. | The action has no reversibility class. |
| There's no confirmed copy of the original state to undo from. | The saved copy wasn't complete when the action ran. See Troubleshooting. |
Refused and failed rows show no Undo button, because nothing changed in the directory.
If the server refuses an undo you started, the message names the reason. For example, "The bridge for this domain is offline. Reconnect it, then try again."
What Undo Restores
Undo restores the directory setting the action changed. A removed member is added back. A moved computer goes back to its original container. A deleted Entra role assignment is created again from the saved copy.
Access can take time to follow:
- Active Directory: A user may need to sign out and back in, because their Kerberos ticket and group memberships refresh at sign-in. Computers pick up administrative access at the next Group Policy refresh, which can take up to 90 minutes.
- AdminSDHolder: Protected accounts have their permissions reset from the template about every 60 minutes. A restored permission in that class can look missing until the next reset.
This is normal Active Directory timing. The receipt shows the state the directory confirmed. If access hasn't followed yet, wait for the next sign-in or refresh, then check again.
Container Removals
A removal made from the Delegation Risk page changes the permissions on a container. The directory then applies the change to every object below it. Remediation history follows both steps.
Follow the directory update
Open Detection & Response > Remediation and select the action. A container removal adds a Directory update section to its details. The History table shows only the action's status; the directory update is in the details.
| Badge | What it means |
|---|---|
| Directory updating | "Removed at the container. The directory is still updating the objects below it." The section adds how many checked objects have changed so far. |
| Applied | "All 8 checked objects below the container lost the permission." The section names the domain controller it checked under Checked on. Other domain controllers apply the change as they replicate it. An undo reads Restored: the checked objects have the permission back. |
| Stalled | "Stalled: 3 of 20 checked objects still have the permission." The checks ran out of time. The badge is a warning. |
| Couldn't check | "The objects below the container couldn't be checked." The sample couldn't be read, or too few objects could be confirmed. |
| Stopped by an undo | "This change was undone, so the directory update isn't checked any more." |
The section also shows "Checks continue until" or "Checks ended" with a time, and a Checked objects list. Each object reads Not yet, Changed or Not affected.
GraphnAI checks a sample of up to 20 objects on the domain controller that made the change. It checks at 1, 2, 5, 10 and 20 minutes, then every 30 minutes, for up to 4 hours. It never switches to another controller partway through.
A line under the badge says where the permissions view stands:
| Line | What it means |
|---|---|
| Waiting for the directory before updating the permissions view. | The directory hasn't converged yet. |
| Updating the permissions view: 12,431 of 911,352 objects | The background update is running. A Permissions view update meter shows the progress. |
| Partially updated. The next full sync completes it. | Part of the update ran. |
| The permissions view updates at the next full sync. | The check stalled or couldn't run. A delta sync doesn't re-read the objects below a container. |
| The permissions view couldn't be updated. The next full sync brings it up to date. | The background update failed. |
The permissions view changes only after the directory converges. A stalled or unchecked removal is never shown as done.
Check again
Operators and Admins can select Check again on a Directory updating, Stalled or Couldn't check removal. It runs one more check at once on the same domain controller. If every checked object has changed, the removal moves to Applied and the permissions view update starts.
The button reads "Checking…" while it runs. Checks are limited to a few a minute, and then it says "Too many checks in a row. Wait a moment and try again." The button is hidden while an undo is running.
| Message | What it means |
|---|---|
| None of the objects below this container could be checked, so the directory update can't be confirmed. The permissions view updates at the next full sync. | No object could be read. |
| This change is being checked right now. Try again in a moment. | A check is already running. |
| This change is being undone, so it isn't checked again. | An undo is in progress. |
| This change didn't take effect in the directory, so there is nothing below the container to check. | The removal didn't apply. |
Undo a container removal
Undo works as for any other action. See Undoing a Completed Action.
- The entries come back as they were. The saved copy holds every removed entry. Undo puts each one back at its original position. If nothing else changed on the container, its entries match the state before the removal exactly.
- Access follows the directory. The objects below the container regain the permission as the directory applies the change. The action shows Directory updating for the undo, with "Restored at the container. The directory is still restoring the permission on the objects below it."
- The permissions view is restored too. GraphnAI puts back the rights and the access paths it removed from its view. If it can't, the line reads "Restored in the directory. The permissions view updates at the next full sync."
- Your changes in between block it. If the container's permissions changed after the removal, restoring an entry at its position could leave the list out of order. Undo then changes nothing and says "This object's permissions changed since the removal, so restoring the entry at its original position would put the list out of order. Nothing was changed; restore it manually."
- An unreachable controller stops it. Undo uses the controller that made the removal. If it's down, undo changes nothing and says "The domain controller this change was checked against isn't reachable, so nothing was changed." Try again when it's back.
- A running update stops. Undoing a removal whose directory update is still running ends that update. The original row shows Stopped by an undo.
When the undo is applied, the delegation row on the Delegation Risk page stops showing a removal state.
Differential Impact Analysis
The Select Fire Simulate step counts only the identities and resources that would lose access. An identity that still reaches the resource another way, such as through a group membership that stays, isn't counted. The panel says "Counts only what nothing else still reaches."
On a very large action, the analysis can reach its limit. The Simulate step then says "The blast radius hit the analysis limit, so the loss may be larger." Full-Auto won't run that action, whatever its safety score, because the count can't be trusted. The receipt's Decision Snapshot records "The blast radius was too large to count, so Full-Auto was refused."
Operational Safety Metric™: One Number
The Operational Safety Metric™ in the Simulate step is the same number Full-Auto checks before it acts. Both come from one calculation.
What the score reflects
The score measures the action's combined impact across all selected targets against what's typical in your organization. An action that removes access from far more identities than usual scores higher, which means more caution. The comparison includes identities with no access, so your busiest accounts don't set the bar.
The score is relative to your own organization. The same number can mean something different in a small organization and a large one.
Before the first full sync
Until a full sync gives GraphnAI your organization's distribution, some factors use a fixed scale instead. Select Show factors on the score card to see them: each one carries an Estimated badge, and the score shows with a tilde, such as "~73". A score with estimated factors never recommends Full-Auto.
When the score can't be computed
If the calculation fails, the score card shows Unavailable where the grade would be. The simulation couldn't be built, a query timed out, or analytics aren't ready yet. GraphnAI doesn't guess a score.
The blast radius and affected identities in the Simulate step are still valid. When you authorize, the score is computed again. If it still can't be computed, the action is refused in Semi-Auto and Full-Auto, and only Safe Mode (a script) is left.
Reading the score in the receipt
Open an action in the History tab to see its receipt. An Admin sees the Decision Snapshot section, which records the Operational Safety Metric and risk score at the moment of the decision, each against the limit Full-Auto needed. Other roles see "A decision was recorded for this action. Only administrators can see it."
A note under the scores says where they came from:
| Note | What it means |
|---|---|
| Both scores were measured, not estimated. | Both scores are real measurements. |
| This identity had no risk score from a sync yet, so the action was held for a person. | No sync had scored the identity yet. |
| This identity's risk score was older than the maximum age for automatic actions, so the action was held for a person. | The risk score was out of date. |
Troubleshooting
The Undo button is missing for a completed action
Refused and failed rows have no Undo button, because nothing changed. A row whose status is still Starting has none either. If the history won't load at all and shows "Couldn't load remediation history", check your role: the history needs Operator or Admin.
"There's no confirmed copy of the original state to undo from"
The copy of the original state wasn't complete when the action ran. The directory may have answered the capture read unexpectedly. The action itself still applied, and only its undo is affected. Undo the change by hand in the directory, for example by adding the member back with your usual Active Directory tools.
Undo completed but access isn't back yet
Undo restored the directory setting, and access follows normal directory timing. See What Undo Restores. If the receipt shows Reverted, the directory confirmed the original setting is back.
The Operational Safety Metric shows Unavailable in the Simulate step
The score couldn't be computed. The blast radius and affected identities are still valid, so you can review the impact. Continue to the Decision step: the score is computed again when you authorize. If it's still unavailable, use Safe Mode or try again later.
A container removal says Stalled
The directory didn't finish applying the change to the checked objects before the check window ended. The removal itself landed on the container. Select Check again. If objects still hold the permission, look at the domain controller named under Checked on. The permissions view updates at the next full sync either way.
The Delegation Risk row still shows Updating view
The permissions view is updating in the background. The row says how many objects are done. If it stays there, check the action in Remediation history. An update that couldn't finish reads "The permissions view couldn't be updated. The next full sync brings it up to date."
Undo escalated for review
The undo ran, but the directory read didn't confirm the original state in time. Open the receipt, compare the before and after values, and check the object in the directory. If it isn't in the original state, fix it there, or ask the person responsible for that domain.