Command policies and approvals in SuperIT

Command policies decide what happens when SuperIT wants to run a command on a device through the SuperIT RMM agent: the command runs (Allow), is blocked (Deny), or waits for an engineer or admin to approve it (Needs approval). Any command no rule matches needs approval. You manage rules under Settings → Command policies and see pending requests under Command Approvals.

For why approvals exist and how they fit with ticket automation, see Autonomy and approvals.

How a command is checked

Every command is checked on the SuperIT server before it is sent to a device. On Windows, commands are PowerShell. The macOS and Linux agents are in Beta; each rule shows the OS it applies to.

1. Cmdlet rules. SuperIT parses the PowerShell command into its cmdlets and looks up a rule for each one.
   • If any cmdlet is Deny, the command is denied.
   • If every cmdlet has a rule, the strictest decision wins.
   • A matching Deny pattern from your team, or a locked Deny pattern, still overrides the cmdlet result.
2. Risky arguments. A command that cmdlet rules would allow still needs approval if it targets another computer (a remote-target parameter), uses a UNC path (\\server\share), or touches a non-filesystem location such as the registry or Env:.
3. Pattern rules. If cmdlet rules did not decide, regular-expression pattern rules are checked in priority order and the first match wins. Locked restrictive rules can still tighten that result.
4. Default. If nothing matched: Needs approval, with the reason "No matching policy found, approval required".

The default rules

SuperIT ships a default rule set for every team:

• Read-only diagnostic cmdlets, such as Get-Process and Get-Service, are Allow.
• Destructive or high-risk commands are Deny.
• Some default rules are locked: your team cannot change them.

The Command policies page

Go to Settings → Command policies. The page says "Control which commands the AI agent can run on your devices". Admins and Engineers can view it. Only Admins can add, edit or delete rules.

Each row shows:

Filter the list by Source, Decision and Type.

Add a rule

1. Go to Settings → Command policies.
2. Select Add rule.
3. Choose a Policy type: Cmdlet or Pattern.
4. Choose a Decision: Allow, Deny or Needs approval.
5. For a cmdlet rule, enter the Cmdlet name (for example Get-Process) and optional Notes.
6. For a pattern rule, enter the Pattern, the Operating system, a Priority and an optional Description.
7. Select Create.

An Allow pattern must match the whole command, so an allow rule for ping does not also allow ping; another-command.

Change or remove a rule

• Select the pencil icon (Edit) on a row. Editing a default rule creates a team copy marked Modified.
• For a Modified rule, open More rule options and select Reset to default.
• For a Custom rule, open More rule options to delete it.

Test a command

1. On Settings → Command policies, select Test a command.
2. Choose the operating system and paste a script.
3. Select Test.

The result is Approved, Denied or Needs approval, with the list of rules checked in order and the one that matched. "Default — no rule matched" means the command would need approval.

Approve or deny a pending command

When a command needs approval, SuperIT pauses and asks an engineer or admin. End users are never asked.

• In the chat. An approval card appears in the conversation. Admins and Engineers can approve or deny each command. In an investigation, the commands for each round share one card.
• In an end-user chat. The end user is never shown an approval card. A command that needs approval is denied automatically. If SuperIT can't fix the problem without it, it hands the issue to your engineers with a summary.

Command Approvals, in the account menu, lists past and pending requests with their Command, Status and Approver, so Admins and Engineers can check them. Statuses are Pending, Approved, Denied, Abandoned, Canceled and Auto-approved. Approve or deny a pending command on its approval card in the chat, not from Command Approvals.

When nobody is in the chat, for example during an automatic ticket investigation, there is nobody to approve. Unless automatic command review approves it, SuperIT leaves out a command that needs approval and continues with what policy allows.

Automatic command review

Automatic command review is rolling out to all teams. When it's on for your team, an AI reviewer checks commands that need approval in engineer and admin chats and during automatic ticket investigations, and can approve a command without waiting for a person. It doesn't run in end-user chats.

The reviewer only considers commands that:

• run on Windows, and are simple commands it can fully check;
• don't target another computer, read secret locations or use risky arguments; and
• if they run as SYSTEM, are read-only diagnostics from a reviewed list, such as reading services, processes, disk volumes or the System and Application event logs, and are allowed by your command policies.

Your command policies still come first: a Deny rule always blocks the command, and the reviewer can't change that. If the reviewer doesn't approve a command, it waits for an engineer or admin in a chat, or is skipped during an automatic investigation. Commands the reviewer approves show as approved by your AI agent in the command's history.

Auto-approve in a chat

An Admin or Engineer can turn on Auto-approve for one chat from the chat's more actions menu. While it is on, the chat shows "Auto-approve on — new commands run without asking", and commands that would need approval run without asking, including commands that run as SYSTEM. Deny rules still apply. It affects only new commands in that chat; select the ✕ (Turn off auto-approve) to stop it. Commands approved this way show as Auto-approved.

Where commands are recorded

Each command SuperIT runs is recorded with the device, the command, who approved it and the result. Admins and Engineers can see it on the device's Command history tab, and can see approval requests in Command Approvals.

Workflow actions use authorization policies

Command policies govern the commands SuperIT runs on devices during chats and investigations. Workflow actions, including actions that run on a device, are governed by the action's own Authorization policy instead, which decides who can run the action and who must approve it. See Approvals for workflow actions.

Related

• Autonomy and approvals
• Ticket automation
• Investigations
• RMM overview
• What SuperIT can and can't do