RustDesk Policies

Policies → RustDesk controls how the RustDesk client behaves on each managed machine. You write a policy with all 31 RustDesk client options (permissions, network, idle disconnect, recording and the client window) and assign it to all agents, a collection, a tag or one agent. Each policy also holds the machine's Approval mode, which is the consent setting: whether the person at the computer is asked before a RustDesk session starts. One policy wins on each machine, and Athena sends every agent its own settings.

Where it appears#

Permissions

With view only, the policy name opens the editor read-only ("Read-only: you can see this policy but not change it.") and the New policy, edit, delete and assignment controls are not shown. The connection and password settings still use the RustDesk permissions described in RustDesk Remote Access. See Permission Model.

The Default policy created on upgrade#

The first time the server starts with this module, it creates one policy from your old Settings → Agent → Remotes options:

• It is named Default, or Default (from Remotes) if a policy called Default already exists. Its description reads "Created on upgrade from the old Remotes settings", followed by the date.
• It is assigned to All agents at the last priority, so any policy you add later wins over it.
• Every option keeps the value the server used before. A value no policy accepts falls back to the default, and the server log names the setting. If the old IP whitelist had addresses, Use IP whitelisting is ticked.
• This runs once, and it runs even on a server whose licence doesn't include the module.

Consent never gets weaker on upgrade. Before, two settings decided consent: Athena's "ask first" checkbox (with the per-machine override), and RustDesk's own approval mode. If either of them asked, the Default policy (or, for a machine whose old override differed, a per-agent exception) is set to Click to accept. If neither asked, the old approval mode is kept. When this changes anything, the Policies page shows a one-time line: "Created on upgrade. Consent never weakens: N device(s) Athena asked consent for will also be asked by RustDesk itself, and N device(s) RustDesk asked for will also get Athena's prompt." The audit log records a rustdesk.legacy-seeded event with the same counts.

Quick start#

1. Open Policies → RustDesk and click New policy.
2. Enter a Name (up to 100 characters) and, if you want, a Description (up to 500). Set Approval mode and any other options, then click Save. A new policy starts with every option at its default. After the first save the editor reopens on the saved policy.
3. In the Assigned to card, choose a Type (All agents, Agent, Collection or Tag). Then pick the collection or tag, or type the agent's Hostname, and click Add assignment. Start with a small test collection.
4. Open a test machine's RustDesk Policy tab. Check the Effective policy, check Consent on this device, and wait until Last config sent shows Applied.

A policy reaches no machine until it is assigned. The editor then says "Not assigned: this policy reaches no device yet."

Approval mode (consent)#

Approval mode, in the editor's Consent section, is the only consent setting for RustDesk sessions. There are three choices. Click to accept asks in a different way depending on the machine's OS:

The default for a new policy is Password or click (unattended). When a policy is unattended, the editor shows "Unattended: sessions start with nobody asked, on every device this policy covers." When it is Click to accept and some of its machines run Linux or macOS, the editor tells you how many.

• The server checks consent each time a session starts. It uses the policy (or exception) stored on the server, not what the agent last confirmed, so a send that failed or is still waiting never weakens consent.
• A machine that no policy matches keeps its current RustDesk options, and Athena still asks for consent before every session to it. Linux and macOS machines have no Athena prompt, so every Athena session to an unmatched Linux or macOS machine is refused. Its tab says so: "Assign a policy."
• The prompt itself, its outcomes and the messages the technician sees are described in RustDesk Session Consent.

The policy options#

A policy always holds every option. There is no "not configured", because RustDesk can't undo an option. When a different policy wins on a machine, all of its values replace the old ones. The editor uses checkboxes and lists. The RustDesk option name is what the REST API and PowerShell use.

RustDesk's own recordings are written on the machine by the RustDesk client. They are separate from Athena's screen-share recordings. The agent tab reminds you: "The Record policy in this agent's Info section is Athena's screen-share recording. RustDesk's own recording is set in the RustDesk policy."

What a device receives

The editor's What a device receives card lists the exact options a machine will get for the form as it stands. "All 31 options are always sent. The server address and key come from Settings > Remotes, not from this policy." Empty values are sent too, so clearing a whitelist or a folder reaches every machine. For Click to accept, the card shows two approve-mode lines: one for Windows (password-click, "Windows - Athena asks") and one for Linux and macOS (click).

Assignments and which policy wins#

• Lowest number wins. Athena checks the assignments in priority order. The first one that matches a machine decides its whole policy. Values are never merged.
• Being more specific doesn't win. "An Agent assignment does not beat a Tag above it." To make one machine different, move its assignment above the others, or use an approval-mode exception if only consent should differ.
• Targets: All agents, a Collection, a Tag or one Agent. On the Policies page, Add assignment offers All agents, collections and tags. The editor's Assigned to card also takes an agent by hostname. A deleted collection matches nothing.
• New assignments go to the bottom (lowest precedence). Use Move up / Move down in the Assignments list to reorder.
• A disabled policy is skipped. Its machines fall through to the next matching policy. Untick Policy enabled in the editor to disable one.
• Deleting a policy also deletes its assignments. Its machines fall through to the next match. A machine with no match keeps its current RustDesk options, and Athena asks for consent before every session to it. Deleting the Default policy does this to every machine it covered.

In the Policies list, the Devices column shows how many machines each policy wins ("N device(s)"), plus "N use a policy above" for machines it matches but loses. In the editor, a warning line names the policy that wins those machines and its priority. The Key options column shows each policy's approve-mode, access-mode and whitelist.

When agents get the change#

• After every save. Saving a policy, an assignment, a reorder or an exception re-sends the settings to the affected connected agents. Each agent gets its own policy. An agent whose settings didn't change is skipped.
• When an agent connects. An agent that was offline gets its own settings the next time it connects.
• Dynamic collections. When a dynamic collection gains or loses members, nothing is sent on its own. Schedule the task RustDesk policies: re-send changed configs in the Scheduler. It re-checks every agent and re-sends only to those whose settings changed since they last applied them. Scheduling it needs rustdesk.policies.manage.
• If sending fails, the save still stands. The policy is stored and audited, and it is delivered on the next connect or the next re-send.

The agent RustDesk Policy tab#

Approval-mode exception for one machine#

An exception changes only one machine's Approval mode. Everything else still comes from its policy. Use it for a single unattended server inside a "click" collection, without giving it a whole policy of its own. In the tab's Approval-mode exception section, pick an Approval mode, enter a Reason (up to 500 characters) and click Save. You'll see "Approval-mode exception saved and sent to the device." To remove it, click the delete button: "Exception cleared: the device follows its policy again."

The exception wins over the policy, both for the consent check and for what the device is sent. The section shows who set it and when. Setting or clearing an exception needs rustdesk.policies.manage. It is always audited as a Warning, because it changes whether a person is asked.

Licence states#

In every state the consent check still runs at each session start. Your policies are kept, so a renewed licence carries on where it stopped. See Separately licensed modules.

Audit events#

The RustDesk session events (started, denied) also record where the consent decision came from (consentSource: Exception, Policy, Unmanaged, Legacy or Frozen). See Audit Event Types Reference.

REST API#

Every response uses the standard { success, data, message } envelope (see API Reference). Out-of-range values are a 400, never clamped. A write on a server whose licence lacks or lost the module is a 403.

Option values use RustDesk's names. On/off options are True / False. The connection and password names (server-url, server-key, password and so on) are refused: "'server-url' is set in Settings > Agent > Remotes, never in a policy."

PowerShell#

The Athena PowerShell module 2.18.0 and later includes:

# A policy that asks the person first, assigned to the "finance" tag
$p = New-AthenaRustDeskPolicy -Name 'Finance - ask first' -Option @{ 'approve-mode' = 'click' }
Add-AthenaRustDeskAssignment -PolicyId $p.Id -TargetKind Tag -TargetKey finance

# Turn off file transfer in an existing policy
Set-AthenaRustDeskPolicy -Id $p.Id -Option @{ 'enable-file-transfer' = $false }

# Who is asked on one machine?
Get-AthenaRustDeskPolicyState -AgentId $agentId

Troubleshooting#

Related#

• RustDesk Remote Access: enabling RustDesk, the server connection, installing and passwords.
• RustDesk Session Consent: Athena's prompt, its outcomes and reconnects.
• Policies: the Policies group and its other modules.
• Unattended Access: consent for the WebRTC screen-share.
• Collections and Agent Tags: the groups you assign policies to.