Concepts
The eight nouns the rest of the documentation assumes you know. Read once, then skim the reference pages.
Endpoint
A Windows machine with the agent installed. Each endpoint has a hostname, an agent version and an enrollment record, and belongs to exactly one endpoint group.
Endpoint group
A bucket of endpoints that share a policy. Think Engineering, Reception, Kiosks. A new endpoint joins your default group unless its install command named a different one.
Each group has an optional discovery mode window. While it is set in the future, every rule action is coerced to audit server-side, so the agent sees the policy but does not disable anything.
Policy
A named, ordered list of rules. A workspace has many policies and each endpoint group has at most one assigned. Every workspace has a default policy, which is what an endpoint sees if its group has no explicit assignment.
Rule
One match condition plus one action: allow, block or audit. The five match conditions:
| Match type | Matches |
|---|---|
| vid_pid | A specific make and model |
| serial | A single physical device |
| device_group | A named set of VID, PID and serial triplets you maintain |
| vendor_name | Substring match against the manufacturer or friendly name |
| class | A broad category: USBSTOR, HIDClass, Printer and so on |
Rule precedence
The engine evaluates rules in tier order, most specific first. Within a tier, rules run in saved position order and the first enabled match wins. If nothing matches, the device is blocked.
- Serial and device_group: per-instance specificity
- vid_pid: an entire make and model
- vendor_name: substring match against the manufacturer
- class: broadest
Hardcoded guardrails
Keyboards and mice are always allowed by a guardrail built into the agent, so a misconfigured rule cannot lock you out of your own machine. The one exception, on agent 1.0.60 and later: a rule naming a specific device by serial or device-group entry is honored, because deliberate beats broad. Non-input HID gadgets are allowed by default but blockable by any matching rule.
Tray app
A per-user app running in every signed-in session, talking to the service over a named pipe. It shows status, recent events and a toast on every block. Enforcement does not depend on it, but every fleet should run it for the user-facing transparency.
Cloud control plane
The dashboard, API and Postgres database. Agents poll for policy on a configurable interval, ten minutes by default, using an If-None-Match etag so a no-op refresh costs almost nothing. Events flow the other way: buffered locally in SQLite, then batched up to the API.
Tenant
Your workspace. One billing relationship, RLS-isolated data, multiple users with roles, and many endpoints, groups and policies. One tenant per user is enforced.
Something missing or wrong here? Tell us. Documentation gaps get filled fast.