Fleet Policy Enforcement: Setting a Security Bar and Finding the Nodes That Fail It

Every security team eventually writes a sentence like this one: “All production machines must score at least 90 and carry no critical findings by Friday.” That sentence is a policy. The hard part was never writing it — it’s knowing, at any given moment, exactly which machines are not living up to it.

On a single laptop that’s trivial: run winsentinel --audit, read the score. Across a fleet of fifty or five hundred machines it’s a spreadsheet nightmare — and a stale spreadsheet is worse than none, because it tells you the fleet is compliant when three boxes quietly regressed overnight.

Pushing a policy is only half the job

WinSentinel Pro already lets an admin push a fleet policy — a small set of rules the whole fleet is expected to meet:

• min_score — every node must score at or above a number.
• require_grade — every node must hold at least a letter grade.
• max_critical / max_high / max_medium — cap the number of findings at a given severity.
• max_findings — cap the total open findings per node.
• no_finding — a specific check (say smbv1.enabled) must never be present.

Pushing that policy sets the bar. But a bar nobody measures against is just a suggestion. Enforcement is the other half: continuously answering “which nodes fail this bar, and on which rule?”

One command, worst-first

That’s what policies check does. It evaluates every enrolled node against every enabled policy and returns the machines that violate the standard — ranked worst-first, each with the exact rule it failed:

$ winsentinel-fleet policies check
Policy compliance check (nodes violating fleet policy)
  Policies:   2 policies  ·  5 rules enforced
  Compliance: 41/47 nodes pass (87%)  ·  6 violating
  Top rules:  min_score (4), no_finding (3), max_critical (2)

  ✗ db-prod-02  —  55 (F)  ·  3 violations
      [Baseline] min_score: score 55 < required 90
      [Baseline] no_finding: forbidden finding present: smbv1.enabled
      [Baseline] max_critical: 2 critical findings > allowed 0
  ✗ app-07  —  82 (B)  ·  1 violation
      [Baseline] min_score: score 82 < required 90

The command exits non-zero if any node violates policy, so it drops straight into a monitoring cron or a CI gate: fail the pipeline, page the on-call, or just wake up to an email when the fleet drifts below the bar you set. Add --csv for audit evidence (one row per violation, ready for a SOC 2 auditor) or --json to pipe it into your own tooling.

Why this is the mental model that matters

Free WinSentinel makes one machine genuinely best-in-class: all the audit modules, real-time monitoring, scheduled scans, PDF reports, one-click fixes — unlimited, local-only, forever. That’s a powerful standalone agent.

Pro turns those agents into a managed fleet with a control plane. Policy enforcement is the sharp edge of that value: you don’t just see your fleet’s posture, you declare the standard it must meet and get a live, prioritized list of the machines that don’t — the exact remediation queue, worst box first.

Pushing a policy is a wish. policies check is the enforcement.

Getting started

Install the free CLI (dotnet tool install --global WinSentinel.Cli) and harden your own machine today — no account, no license. When you’re ready to hold a whole fleet to a standard, WinSentinel Pro adds the control plane, fleet commands, and the policy enforcement shown here.