Full-Auto Execution
Let qualifying remediations run without a person authorizing each one, with rollback watches that undo the change or escalate it when dependent services start failing.
Requires role: Admin (Autonomy settings, arming, the Autonomy Activity tab); Operator or Admin (escalation notifications, and Full-Auto from Select Fire) Related: Semi-Auto Execution, Closed-Loop Rollback, Select Fire™, Remediation Reversibility and Undo, Detection Alerts
Overview
Full-Auto is the most automated of Select Fire™'s three modes. Safe Mode gives you a script to run yourself. Semi-Auto runs each change after you authorize it. Full-Auto runs a qualifying change with no one authorizing it.
Full-Auto starts in two ways:
- Unattended: A triage policy acts on a detection alert, and the action runs on its own. This needs Full-Auto to be armed. Most of this guide covers it.
- From Select Fire: You approve a whole plan once, and each action runs at the highest mode its checks allow. See Full-Auto in Select Fire.
Full-Auto uses the same execution path as Semi-Auto: the same safety checks, ledger, reversibility rules, and directory read-back. It adds a list of checks, run before every action. When they all pass, the action runs, and a Closed-Loop Rollback watch starts on it. If failed sign-ins or failed services appear on the hosts that depend on the account, the watch undoes the change or escalates it to a person. See Closed-Loop Rollback.
What Full-Auto never acts on: A platform Admin, the escalation contacts, the Operators needed to keep enough people able to sign in, and the accounts GraphnAI itself syncs, writes, and signs in with. The same goes for their on-premises Active Directory accounts. When an alert names one of them, the action drops to Semi-Auto, and a person decides. That stops an attacker from using an admin-looking account to lock you out of your own emergency controls.
Prerequisites
Full-Auto can't be armed until the first three conditions below are met. The server enforces them, so editing the settings directly can't skip them. The fourth is what any change needs before it can run.
1. Completed shadow-mode calibration period
Before anything runs on its own, shadow mode records what Full-Auto would do and runs nothing. That gives you a record of the decisions Full-Auto would have made, by action type and by what held each one back, before you let it act.
Shadow mode must run for its minimum, 7 days by default. The count starts when an Admin turns shadow mode on, and it can't be back-dated. The Shadow mode report fills in as decisions come in. It shows:
- Would have run in Full-Auto: How many decisions would have run on their own.
- Runaway projection: The Peak actions in an hour against the hourly limit, and the Rollbacks, worst case against the circuit breaker. Each row shows Under limit or Would trip.
- By action type: For each action, how many were Evaluated, how many would have run in Full-Auto, and what Held back by the rest, such as "Admin self-protection", "Some access not seen in use", "Not reversible", "Not observable", "Outside change window", or "Tier 0 or 1 target".
- Decisions (N): Each decision, with the result of every check.
The projection counts only decisions that would have run in Full-Auto. Decisions held back don't inflate it. When it projects that a limit would trip, arming asks you to accept the risk first.
2. Verified out-of-band escalation channel
Full-Auto needs a way to reach a person outside GraphnAI when something goes wrong, for example when a containment watch trips at 3:00 AM.
Set it up in Escalation channel on the Autonomy tab. Transport offers two options:
- Webhook (HMAC-signed POST): Enter the Webhook URL, select Save channel, then Test delivery. Any 2xx response from your endpoint verifies it.
- Email: Fill in the SMTP server settings and select Save SMTP. Choose Recipients: Operators and Admins are selected by default, and you can add a custom address. Select Save channel, then Send verification link. The channel is verified when a recipient opens the link, which works for 30 minutes. Email verification needs the server's external address to be configured.
The card shows Verified, Unverified, or Verified (pending re-check) while you edit it. Changing the channel clears its verification, so verify it again.
The Admin who runs the test becomes the channel's owner, shown as "Verified by …". The owner and the Operators and Admins selected as email recipients join the safety list.
3. Everyone on the safety list matched to a directory account
The Safety list panel shows who automation will never act on: Administrators, Escalation contacts, Operators, and Platform accounts. It also shows how many Operators and Admins can still sign in, against the minimum.
Every Administrator and escalation contact must be matched to a directory account. Until then, no automation runs, and the line beside Arm Full-Auto reads "Match every administrator and escalation contact to a directory account first."
4. Execution prerequisites already in place for Semi-Auto
Full-Auto runs through the same path as Semi-Auto. Remediation credentials must be saved and validated for the domain, and its bridge must be connected. See Semi-Auto Execution.
Arming Full-Auto
Arming turns shadow mode off and lets qualifying actions run on their own.
- Select Admin > AI Provider in the sidebar.
- Open the Autonomy tab.
- Under Autonomy controls, set an Operational Safety Metric: automatic threshold (0-100) above 0.
- Under Actions Full-Auto may take, select at least one action.
- Check that shadow mode reads "Shadow mode has run for its N days minimum."
- Read the Shadow mode report.
- Check that the escalation channel shows Verified.
- Select Arm Full-Auto.
- In Arm Full-Auto?, check that all three conditions are ticked.
- If the report projects a limit would trip, tick the box that accepts the risk.
- Select Arm Full-Auto.
Arming also saves the other settings on the tab. Without a threshold above 0 and at least one action, arming turns shadow mode off and nothing runs on its own.
The line beside the arm button says what's still missing, for example "Still needed: 2 more days of shadow mode and a verified escalation channel." Once armed, it reads "Full-Auto is armed."
To stop Full-Auto, do one of these:
- Turn shadow mode back on. Full-Auto goes back to recording only. Arming again needs a fresh minimum period.
- Set the automatic threshold to 0, or clear every action, then save.
- Stop all automation with the kill switch. See The Kill Switch.
The Autonomy Settings
The Autonomy tab on Admin > AI Provider holds every Full-Auto setting. Select Save autonomy settings to apply changes to the controls, the change window, and the canary stages. The shadow mode switch, the escalation channel, and arming save on their own.
Threshold sliders
| Setting | What it controls |
|---|---|
| Operational Safety Metric: automatic threshold (0-100) | Actions scoring at or below this run on their own. A higher value lets more actions run. 0 turns Full-Auto off, which is the default. |
| Operational Safety Metric: Semi-Auto threshold | Actions scoring between the two thresholds wait for approval. It must be higher than the automatic threshold. Default: 30. |
| Risk score threshold (0-100) | An identity's risk score must reach this before Full-Auto acts on it. Below it, the action waits for a person. Default: 70. |
| Automatic actions per hour | The most actions Full-Auto takes in one hour. Default: 10, maximum 100. A change window opening doesn't reset it. |
Allowed action types
Actions Full-Auto may take lists the actions Full-Auto can run on its own. An action that isn't ticked waits for a person, even when every other check passes. Nothing is ticked by default.
| Option | What it covers |
|---|---|
| Disable user | Disabling an account, blocking Entra sign-in, and quarantining an account |
| Require Kerberos pre-authentication | Turning pre-authentication back on for an account that skips it |
| Require a password | Stopping an account from signing in with a blank password |
| Stop storing a recoverable password | Turning off reversible password encryption |
| Allow modern Kerberos encryption | Stopping an account from being limited to DES encryption |
| Apply the password expiry policy | Letting a password expire on schedule |
| Require a password change | Making a user choose a new password at the next sign-in |
The server owns this list, so the tab always matches what the server accepts. It lists only actions the reversibility check can admit to Full-Auto. Revoking sessions and resetting a password can't be undone, and removing a group membership or a service principal name needs a saved copy of the original state that exists only after the change runs. The check always holds those at Semi-Auto, so the tab doesn't list them. Every action not listed here, such as removing a permission entry or an Entra role, always waits for a person.
Current scope: Full-Auto acts only on identities whose Windows sign-in events GraphnAI collects, because a rollback watch needs them. Cloud-only identities have none, so actions on them stay at Semi-Auto. See Evidence coverage requirement for the other limit on who is eligible.
Other controls
| Setting | What it controls |
|---|---|
| Minimum reachable operators | Full-Auto won't quarantine an account if fewer Operators and Admins than this could still sign in. 0 turns this off. Admins are always protected. Default: 1. |
| Shadow mode minimum (days) | How long shadow mode runs before Full-Auto can be armed. Default: 7, range 1 to 90. Raise it when alerts are too rare to give a useful sample in a week. |
| Risk score maximum age (days) | How old an identity's risk score can be for an automatic action. Past this age, a person decides instead. Default: 7. 0 uses the server default. |
A note below these settings reads "Unattended automation never acts on Tier 0 or Tier 1 targets". That isn't a setting, and it can't be turned off.
Shadow mode
The Shadow mode card has a switch. On, Full-Auto records what it would do and runs nothing, and a meter shows the days run against the minimum. Turning it on starts the count. Turning it off opens Arm Full-Auto?.
Change window
Change window sets when Full-Auto may run. Outside the window, an action that qualifies waits in a queue. It stays a Full-Auto decision, and it runs when the window opens.
| Schedule | Behavior |
|---|---|
| Always | No timing limit. The default. |
| Business hours | Monday to Friday, 09:00 to 17:00 in the chosen time zone. |
| Custom (cron) | A five-field cron schedule (minute, hour, day of month, month, day of week). |
Choose the Time zone for Business hours and custom schedules. The default is UTC. A line under the card states the schedule and the current time in that zone, so you can check it against your clock.
A change window only sets timing. It doesn't add an approval step. When the window opens, each waiting action runs through every check again. If the hourly limit, the circuit breaker, or an arming condition holds it, it keeps waiting. If any other check now fails, such as the kill switch or a change in the identity's tier, it's refused instead of running. Waiting actions run in canary stages and count toward the hourly limit.
A waiting action expires 24 hours after it was queued, or one hour after the next window opens, whichever is later. A window more than 7 days away gets the 24-hour limit.
To make an approval part of a schedule, use Semi-Auto. Full-Auto with a change window means "run on its own, but only during these hours."
Canary staging
When one policy matches many identities, Full-Auto runs them in stages. Canary stages defaults to 1, 10, then the remainder. Enter the stages as numbers separated by commas, and use 0 or "remainder" for the last stage.
Each stage's rollback watches must end with no failures before the next stage starts. If a watch trips, the rest of the batch stops, and Admins get a Full-Auto batch stopped notification. Review the batch before arming again.
Every stage counts toward the hourly limit, so a match larger than the limit runs over several hours.
Escalation channel
See Verified out-of-band escalation channel.
How Full-Auto Decides to Act
Full-Auto acts when a triage policy says to. On the Triage tab of Admin > AI Provider, each detection rule has a policy. When a rule's Actions include Fix automatically or Quarantine automatically, an alert from that rule proposes an action.
Triage acts only on an account that did something or that an attacker holds. It never acts on an account that was attacked, added, changed or named in a ticket. An alert lists its accounts by the part each played, and the policy's action runs on the one account in the right part:
| Rule | Quarantine automatically acts on | Anything else |
|---|---|---|
| DCSync | The account that replicated the directory | |
| Tier 0 group change | The account that made the change, never the account added | Removing the added account is a manual action |
| Trust manipulation | The account that changed the trust | |
| Audit tampering | The account that changed the audit settings | |
| Password spray succeeded | The targeted account the attacker signed in as | Resetting its password is a manual action |
| Every other rule | Nothing. A person decides |
A victim, an added member, a target, a service or a group is never acted on automatically. That covers the account receiving failed sign-ins in a brute force alert, the accounts a password spray tried, and the account a Golden Ticket or AS-REP Roasting alert names. An attacker can choose any of them, so acting on one would let the attacker pick the account to lock out.
Triage sends the alert to a person instead, with the reason in the notification, when:
- The alert doesn't name exactly one account in that part, or the account doesn't match an identity in the graph.
- The account is a computer account (its name ends in
$) or SYSTEM. - The account, or the account the alert is assessed on, is Tier 0 or Tier 1.
- For Password spray succeeded, the sign-in came from an address the account usually signs in from. It may be the owner, so confirm with them.
Close automatically runs only on an alert whose main account is one that acted or was compromised. For any other alert it sends the alert to a person instead.
Fix automatically has no action for any detection rule yet, so it also sends the alert to a person.
Every proposed action then runs through these checks, in order. All of them must pass for it to run on its own. A check that fails drops the action to Semi-Auto, or refuses it outright. The decision snapshot records which check did it.
| Check | What it checks |
|---|---|
| Safety list | The identity isn't a protected object, such as KRBTGT, which refuses the action outright. It also isn't a platform Admin, an escalation contact, or an account GraphnAI runs with. See Admin self-protection. |
| Rolled back recently | The same change wasn't undone by a rollback watch recently. Repeating it would loop. |
| Allowed actions | The action is ticked under Actions Full-Auto may take. |
| Reversibility | The change can be undone: it's Reversible, or Reversible from saved state with a confirmed saved copy. |
| Observability | GraphnAI collects Windows sign-in events for the identity, so a rollback watch can see trouble. |
| Operational Safety Metric and risk score | The score was computed with no estimated factors, the blast radius wasn't cut off, and the score is at or below the automatic threshold. The identity's risk score exists, isn't older than the maximum age, and reaches the risk threshold. |
| Evidence | Every permission the identity holds has been seen in use. See Evidence coverage requirement. |
| Tier | The identity isn't Tier 0 or Tier 1. |
| Hourly limit and circuit breaker | The hourly limit isn't reached, and the rollback circuit breaker isn't open. See Closed-Loop Rollback. |
| Kill switch | Stop all automation isn't on. |
| Armed | Full-Auto is armed, and its escalation channel is still verified. |
| Change window | The window is open. Otherwise the action waits for it. |
When every check passes, the action runs, and a rollback watch starts on it. It shows as Running, then Watching while the watch counts down.
Evidence coverage requirement
Full-Auto has to earn its eligibility from what GraphnAI has seen. This is the Tiered Fidelity™ model at work. Every permission starts as Theoretical: configured, but not confirmed. It becomes Constrained once an environmental control has been checked against it, such as a Conditional Access policy, a Group Policy setting, or a delegation permission. It becomes Validated only once GraphnAI has seen it used. Full-Auto needs every permission the identity holds to be Validated. Most of them, or an average, isn't enough.
"Every permission" means every way the identity holds power over something else: direct grants, app role assignments, ownership, directory role assignments, delegation rights (including resource-based constrained delegation), the right to read a managed service account's password and sign in as it, and access carried over through SID history. The check covers access the identity holds. Permissions others hold over it are checked when those identities are evaluated.
Permissions the identity holds through its groups count too. Today, only direct permissions can be confirmed in use, so an identity that holds any permission through a group stays at Semi-Auto.
On a new deployment, no identity is eligible yet, because nothing has been seen in use. That's expected. Eligibility grows as telemetry confirms which permissions are actually used. Full-Auto never acts on access it has only inferred from the directory, even when that access looks unused.
When an action doesn't qualify, the reason appears on the receipt and in Select Fire, for example "Some access not seen in use" when part of the identity's access hasn't been confirmed, or "No permissions to assess" when the check found none. See Risk Narrative and Gradient of Control for every reason.
Admin self-protection
The safety list check holds back Full-Auto for any identity on this list:
- Every platform Admin, and their on-premises Active Directory accounts in a hybrid environment
- The escalation channel's owner and the Operators and Admins selected as email recipients
- Any Operator whose loss would leave fewer reachable Operators and Admins than Minimum reachable operators
- The accounts and apps GraphnAI syncs, writes, and signs in with
A match drops the action to Semi-Auto with the reason "Admin self-protection". A person has to authorize any action that touches the people who run the platform. The protection covers the on-premises account even when the alert names the Entra ID identity.
The list is worked out again for every action. If an Admin or escalation contact can't be matched to a directory account, all automation stops until they are. The Safety list panel shows who is unmatched.
Containment Quarantine
When an alert calls for isolating an account, such as a DCSync detection, Full-Auto runs a Quarantine the account action. It's one action with several steps:
- Disable the Active Directory account.
- For a hybrid account, block Entra ID sign-in.
- For a hybrid account, revoke active Entra ID sessions.
The quarantine is Partly reversible. Undo re-enables the account and unblocks sign-in, but revoked sessions can't come back. Revoking sessions doesn't change the account's access beyond the disable. It ends any live token right away, so there's no gap between the quarantine and the revoke.
When a step fails, the earlier steps stay in place, and the action is escalated to a person. A partly contained account is safer than one re-enabled automatically.
A quarantine's rollback watch escalates rather than undoing the change. Failed sign-ins or failed services after a containment are an expected result: services that used the compromised account now fail. The watch asks a person to look instead of undoing the isolation. Check whether the failing service was legitimate before you release the quarantine.
To release a quarantine after its watch ends, select Undo on its row on the History tab. A quarantine escalated for review can't be undone there, so release it with your own directory tools. Releasing a containment is always a person's decision.
The Kill Switch
The kill switch is the Stop all automation button at the top of Admin > AI Provider, above the tabs. Select it, then confirm Stop automation. Every automatic action stops right away, including fixes, alert closes, and investigations. Automatic work that's running stops too. Graphne still answers questions. To stop every AI feature, including Graphne, see AI Safety Controls.
While it's on, a banner reads "AI automation disabled. Every automatic action is blocked." and names who turned it on. Actions that would have run on their own drop to Semi-Auto and wait for a person.
The kill switch doesn't:
- Stop rollback watches already running
- Stop an undo already in progress
- Prevent an undo of a change that already ran
It stops new automatic actions only. GraphnAI can always undo a change it already made, so the kill switch can't strand an undo halfway.
To turn automation back on, select Turn automation back on, then Turn on. It's never locked by the license, so it works during an incident whatever the license state.
Autonomy Activity Tab
Admins see an Autonomy Activity tab on Detection & Response > Remediation. It shows:
- Armed watches, Awaiting review, and Full-Auto actions: A count for each.
- Armed rollback watches: A card per running watch, with its time left and how many hosts it watches.
- Awaiting review: Actions escalated for review, and watches that saw failed sign-ins or failed services. "Nothing is waiting for review." when there are none.
- Recent Full-Auto activity: Every action Full-Auto ran, with Initiated, Subject, Action, and Status.
Full-Auto actions use these status badges:
| Badge | Meaning |
|---|---|
| Running | The change is being made through the bridge. |
| Watching | The change was made, and its rollback watch is counting down. |
| Verified | The watch ended with no failures. |
| Reverting | The watch saw failures on a hygiene change, and GraphnAI is undoing it. |
| Reverted | The undo finished, and the directory confirmed it. |
| Escalated for review | The watch saw failures on a containment change, or an undo failed. A person has to look. |
| Waiting for bridge | The action is queued, for the bridge or for the change window, and runs when it can. |
Select any row or card to open its receipt on the History tab. The receipt's Decision Snapshot shows every check's result, the Operational Safety Metric, the risk score, and the evidence level. Its timeline and Changes section show what happened.
Every Full-Auto action is also written to the governance audit log. Each entry names the triage policy that allowed the action and the platform identity that ran it. The log is kept for seven years.
Full-Auto in Select Fire
In the Select Fire Decision step, you can choose Full-Auto for the plan in front of you. It builds the same plan as Semi-Auto, then shows Approve the plan:
- Review the actions and any Needs confirmation lines.
- Select Approve and run N actions.
One approval runs the plan's actions in order. An action whose checks allow Full-Auto runs as Full-Auto, with a rollback watch. Every other action runs as though you'd authorized it in Semi-Auto. An action that can't run is skipped, and the panel says how many before you approve.
When the plan finishes, one result replaces the rows. Its title says how it went, such as "Plan finished" or "Plan finished with problems", over a bar of the outcomes. Each action's result is listed below.
Before you approve a plan with several steps, the panel may warn that each step's rollback watch can trip after the next step has already run.
The same roles apply as in Semi-Auto. An Operator can run only the actions on Critical or High targets. An action that would run as Full-Auto also needs a license that includes it.
Troubleshooting
Arm Full-Auto is disabled after the shadow period ends
Read the line beside the button. It names what's missing. Check each condition:
- The escalation channel shows Verified. If not, select Test delivery or Send verification link again.
- Shadow mode has run for its minimum. The count starts when shadow mode was turned on and can't be back-dated.
- Every Administrator and escalation contact is matched to a directory account. The Safety list panel shows who isn't.
If the report projects a limit would trip, tick the box in Arm Full-Auto?. The box clears each time you open the dialog.
Full-Auto is armed but nothing runs
- No policy asks for it. Full-Auto acts only when a triage policy's Actions include Fix automatically or Quarantine automatically. Fix automatically has no action for any detection rule yet and escalates instead. Check the Triage tab.
- Every action is held back. Open the receipt of a recent action and read its Decision Snapshot. Common reasons: "Some access not seen in use" (see Evidence coverage requirement), "Not observable" (no Windows sign-in events for the identity), "Action not enabled", and "Outside change window".
- The hourly limit is reached. Actions wait until the hour's count drops.
A queued action isn't running
Actions waiting for the change window run when it opens, up to the hourly limit. If one isn't running:
- Check that the window is open now. The line under Change window gives the current time in its zone.
- Check that the kill switch isn't on.
- Open its receipt. If its Queue expires time has passed, it expired and was refused. The next alert for the same identity proposes the action again.
An escalation arrived for a quarantine
That's expected when a containment watch sees failed sign-ins or failed services. GraphnAI doesn't undo a containment on its own, because that would let the threat back in. Open the receipt and review the watched hosts:
- If the failing service was legitimate and used the account's credentials, restore its access with your own directory tools, then decide whether to release the account.
- If the failures came from a source you recognize as the attacker's, the containment is working. Close the escalation.
See Closed-Loop Rollback for the full investigation.
A "Full-Auto paused" notification appeared
The rollback circuit breaker tripped: 5 or more changes were undone, or escalation deliveries failed, within 10 minutes. Actions wait for approval until the count within the last 10 minutes drops below 5. Review recent Reverted entries on the History tab to find the cause, and test the escalation channel.
If the cause isn't fixed yet, turn shadow mode back on or use the kill switch. If the shadow mode report projected this, consider lowering Automatic actions per hour or clearing some Actions Full-Auto may take before arming again.
The escalation channel test fails even though the webhook is reachable
The test sends a signed HTTPS POST with a JSON body and waits for a 2xx response. Common causes:
- The endpoint returns a status outside the 2xx range, such as 404 or 500. 202 Accepted works.
- A firewall blocks the GraphnAI server's outbound address.
- The endpoint's TLS certificate has expired, or its root CA isn't trusted by the GraphnAI server.
The UI shows only whether it verified. The server log has the HTTP status or connection error.
A decision shows "Admin self-protection"
Full-Auto didn't act, because the identity is a platform Admin, an escalation contact, or an Operator needed to keep the minimum reachable. The action dropped to Semi-Auto as designed. Review whether the account is compromised, then authorize it in Semi-Auto.
If the identity isn't one of those, check whether its on-premises Active Directory account is linked to a platform user. The protection covers the on-premises account of every Admin, as well as the Entra ID identity.