Policy guide
A policy is an ordered list of rules. Each rule has one match condition and one action. The engine walks rules in tier order, most specific first, then within a tier in your saved order.
The five match types
vid_pid
Match a specific make and model. Use it when the manufacturer plus model is the right granularity: every YubiKey 5, every Logitech MX Keys, every iPhone.
{ "match_type": "vid_pid", "match_vid": "1050", "match_pid": "0407", "action": "allow" }serial
Match a single physical device by VID, PID and serial. This is the rule for "the exact thumb drive issued to Joe."
{ "match_type": "serial", "match_vid": "0781", "match_pid": "5567", "match_serial": "AA010401190902103045", "action": "allow" }Some cheap devices report a dummy serial such as 0000000000. The engine treats those as no serial available, not as a match against every empty serial.
device_group
Match against a named set of VID, PID and serial triplets. Build a group like "Approved engineering thumb drives" once and reference it from any rule. Adding members changes the effective behavior of every policy that references it.
vendor_name
Case-insensitive substring match against the manufacturer string or friendly name. Useful for "allow anything from Logitech." Inconsistent vendor strings (Logi, Logitech, Logitech Inc.) are why this is substring-based rather than exact-match.
class
Match by Windows PNP class: USBSTOR, HIDClass, Printer, Image, Media and so on. The engine matches against the full class set (PNPClass, Service and child enumerations) rather than only the parent class, so a rule blocking USBSTOR really does block thumb drives even though their parent USB device shows class USB.
Tier ordering
Tiers run most specific to broadest. Within a tier, rules evaluate in saved position order, and the first enabled rule that matches wins. If nothing matches, the device is blocked.
- Serial and device_group: per instance, most specific
- vid_pid: an entire make and model
- vendor_name: narrower than class, broader than vid_pid
- class: broadest
Actions
| Action | What happens |
|---|---|
| allow | Device is enabled. Logged at info severity. |
| block | Device is disabled through Configuration Manager APIs. Logged at warn, and the tray notifies the user. |
| audit | The decision is logged but enforcement is skipped. Useful for testing a rule before flipping it to block. |
Discovery mode
Per endpoint group and time-bound. While it is active the API rewrites every rule action to audit server-side. The agent does not know it is in discovery mode: it simply sees a policy where nothing blocks.
Hardcoded guardrails
Keyboards and mice are protected by a guardrail in the agent itself. A class rule, a vendor rule or the default block never touches them, so a misconfigured block-everything policy cannot lock you out of your own machine.
Since agent 1.0.60 the guardrail is scoped to actual input devices and admits one deliberate exception: a rule that names a specific device, whether a serial rule or a device-group entry, is honored even against a keyboard, so you can block a device you have explicitly identified. Other HID devices such as busy lights, macro pads and UPS monitors are allowed when no rule matches them but respect any rule that does. On agents before 1.0.60, everything HID-class was allowed unconditionally.
Authoring patterns
A common starting policy, and exactly the pattern your seeded default ships with:
- Allow specific security keys by vid_pid (YubiKey, Titan)
- Allow vendor_name substrings for trusted peripherals (Logitech, Microsoft)
- Allow class for printers, audio and video
- Block the USB storage device type. The default deny catches it anyway, but an explicit rule makes audit logs read clearly
- Optional: allow specific approved thumb drive serials at the top tier for individual users
Something missing or wrong here? Tell us. Documentation gaps get filled fast.