Full-Auto Execution: Auto-Remediation Without Per-Action Approval

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 logons 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. Shadow mode run for its minimum days

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", "Access in use", "No alert attached", "Not reversible", "Not observable", "Outside change window", or "Tier 0 or 1 target". The reasons are grouped by purpose. See What you see when an action is held.
• 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 deny list.

3. Everyone on the deny list matched to a directory account

The Deny 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.

1. Select Admin > AI Provider in the sidebar.
2. Open the Autonomy tab.
3. Under Autonomy controls, set an Operational Safety Metric: automatic threshold (0-100) above 0.
4. Under Actions Full-Auto may take, select at least one action.
5. Check that shadow mode reads "Shadow mode has run for its N days minimum."
6. Read the Shadow mode report.
7. Check that the escalation channel shows Verified.
8. Select Arm Full-Auto.
9. In Arm Full-Auto?, check that all three conditions are ticked.
10. If the report projects a limit would trip, tick the box that accepts the risk.
11. 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

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.

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 requiring a password change can't be undone completely, so the check holds those at Semi-Auto and the tab doesn't list them. Removing a group membership or a service principal name is listed: its original state is saved before the change runs, and if that save fails, the change doesn't run on its own. 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 logon events (4624 and 4625) GraphnAI collects, because a rollback watch needs them. Cloud-only identities have none, so actions on them stay at Semi-Auto. See Evidence requirement for the other limit on who is eligible.

Other controls

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.

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.

An action queued before the evidence gate existed has no evidence on record. At the change window it's refused with the reason, and escalated to a person if triage started it. It never runs at Semi-Auto in its place. A waiting action that ran its checks again at the window is refused too if its evidence no longer holds, for example because the access was used meanwhile.

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 canary stage 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 Take automatic action 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:

A victim, an added member, a target, a service or a group is never acted on automatically. That covers the account receiving failed logons 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 authentication came from an address the account usually logs on 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.

Take automatic action 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.

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 requirement

Full-Auto has to earn its eligibility from what GraphnAI has seen, and what it needs depends on the purpose of the action.

Removing access. Full-Auto removes a permission only when GraphnAI has shown that nobody uses it. For each permission the action removes, GraphnAI needs three things: audit coverage proven on that object for the whole window (90 days by default, and an administrator of the deployment can change it, down to 30), no use seen in that window, and a grant at least as old as the window. A permission that was used recently, one the directory doesn't record use of, or one granted recently stays at Semi-Auto. The check covers only the permission being removed. It doesn't ask whether everything else the identity holds has been used.

A group can grant access to file shares and applications that isn't recorded here, so removing a group member waits for approval. An administrator of the deployment can turn on a mode that judges a removal on every right the group gives the account. GraphnAI then runs it only when none of them was used in the window.

GraphnAI asks the directory whether a permission was changed or used when the action runs. The ranking and the plan you see in Select Fire use the checks already stored, so a plan can show Full-Auto where the live check at run time then holds it back. The receipt records the live result.

Containing an account. Full-Auto contains an account only for a confirmed compromise. That means an open, recent alert of High severity or above from a detection that has been verified for automatic containment, naming this account as the one compromised or attacker account. The alert has to come with the request. Open Select Fire from the alert on Detection Alerts, or from an alert on the identity's timeline, and the plan carries it. Select Fire opened from anywhere else has no alert, so containment waits for you.

GraphnAI also needs to see what depends on the account: sign-in auditing proven on every domain controller of the account's domain, so the list of computers and services that sign in as the account is complete, and failed sign-ins at the domain controllers watched after containment. A domain with a read-only domain controller (RODC) waits for approval in this release. Otherwise the action stays at Semi-Auto. An alert is used once for an account. Acting on that account again needs new evidence on the alert.

No detection has been verified for automatic containment yet, so containment runs at Semi-Auto today. A person authorizes it from Select Fire, and the receipt shows the alert checks.

A containment that would run on its own isn't queued. If its bridge is disconnected, it's refused, and an action that triage started goes to a person.

On a new deployment, little is eligible yet, because the evidence takes time to build. That's expected. Full-Auto never acts on access it has only inferred from the directory, and it never contains an account on an alert that hasn't been verified.

The observation confidence shown on an identity describes how much of its access GraphnAI has seen used. It's for reading only, and no check uses it.

When an action doesn't qualify, the reason appears in Select Fire and on the receipt. See What you see when an action is held.

What you see when an action is held

In Select Fire. When no action in the plan can run as Full-Auto, a note under the disabled Full-Auto card says why. The note starts "Every action in this plan needs your approval one at a time." With one reason, it follows with a sentence. With several, it lists each short label and how many actions it holds, for example "Access in use: 2 of 5 actions". For a containment held for lack of visibility, the note also names the domain controllers or computers GraphnAI can't see, with a See audit coverage link to the Audit coverage card in Platform Health.

The Recommended badge on the Full-Auto card appears only after the plan is built. Before that, a line under the card reads "The ranking suggests Full-Auto. It's confirmed when the plan is built." After the build, the badge shows only if at least one action can run as Full-Auto.

On a receipt. Open a receipt on the History tab and find Evidence in the decision record:

• Removing access lists each permission checked, with the object, the right, and a state: In use (with "Last used" and a date), Not used (with "Watched since" and a date), Can't be checked, or Not yet observed. It also shows when the access was granted.
• Containing an account shows the alert (detection, severity and age) and the checks it passed, such as "Open", "Verified detection", "Names this account", "Severity at or above High", "Fresh", "Has recorded events" and "Not used before for this account". A failed check reads in plain words, for example "This detection hasn't been verified for automatic containment yet." The last line states how many domain controllers have proven sign-in auditing and how many computers that use the account would be seen failing.
• A receipt recorded before this release says "This decision was recorded before evidence was kept per action."

For Can't see what depends on it, the detail lists the domain controllers and audit streams that aren't proven, such as "Kerberos Authentication Service (Success)", "Credential Validation (Success)" or "Event forwarding". It says when a domain controller hasn't reported at all, and when the account signed in from more than 500 computers. See audit coverage opens the card with the rows behind the sentence.

In the shadow mode report. The reasons under Held back by are grouped by purpose: Hygiene, Containment, Other and Earlier check, the last for reasons recorded before this release. Each reason shows its count. A group with no decisions is hidden.

Reason labels

An action whose original state can't be captured before it runs is refused at run time. It isn't run at Semi-Auto in its place, because nobody is there to approve it. A request that triage started goes to a person.

Admin self-protection

The deny 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 Deny 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:

1. Disable the Active Directory account.
2. For a hybrid account, block Entra ID sign-in.
3. 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 logons 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 logons 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:

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 observation confidence. 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:

1. Review the actions and any Needs confirmation lines.
2. 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:

1. The escalation channel shows Verified. If not, select Test delivery or Send verification link again.
2. Shadow mode has run for its minimum. The count starts when shadow mode was turned on and can't be back-dated.
3. Every Administrator and escalation contact is matched to a directory account. The Deny 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 Take automatic action or Quarantine automatically. Take automatic action has no action for any detection rule yet and escalates instead. Check the Triage tab.
• The Full-Auto card is disabled in Select Fire. The note under the card gives the reason. For a containment, open Select Fire from the alert, not from the identity's page, so the plan carries the alert. See Reason labels.
• Every action is held back. Open the receipt of a recent action and read its Decision Snapshot. Common reasons: "No alert attached" or "Alert doesn't qualify" for containment, "Use not yet observed" or "Access in use" for removing access (see Evidence requirement), "Not observable" (no Windows logon 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 logons 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.