Policies and adoption

Policies and adoption

Publish immutable revisions, resolve precedence, stage enforcement, and recover failed rollouts.

Policies define requested protection for assets. Publishing creates an immutable revision; each executor separately reports the revision it applied.

Create and assign a policy

You need Administrator authority for every target the policy selects. Families cover edge, endpoint, data loss prevention (DLP), device control, compliance, and access behavior. Configuration fields define each family's defaults and validation.

In Policies → Create policy, select the family, enter a name, and edit the draft. Detection and transfer-blocking rules begin in monitor mode. Access policies require explicit grants and otherwise deny admission, including while a policy draft is being evaluated.

Use Policy → Assignments → Add assignment to choose an asset or group. The effective policy is selected within each family in this order:

  1. The asset's explicit assignment.
  2. The matching group assignment with the highest priority, from 0 through 1000 inclusive.
  3. The organization baseline, when no explicit asset or matching group assignment applies.

Two explicit assignments for the same asset and family reject publication. Equal-priority group assignments that overlap also reject publication with assignment_conflict. Resolve the conflict before publishing; Guard does not merge competing policies.

Open Policy → Preview to review the effective revision and target set. Dynamic membership changes can alter future targets; review selectors before adding a broad tag rule. Permissions are checked against the complete resolved target set.

Publish and verify

  1. Open Policies → Policy → Preview and inspect the resolved targets, conflicts, and required capabilities. If a target lacks a required control, correct the assignment or configuration before publication.
  2. Select Publish and supply a change reason.
  3. Open Policy → Adoption and wait for every intended executor to report applied for the published revision. For offline, restore management connectivity; for failed, inspect the target's error before publishing a correction.

After publication, open Policy → Adoption. Executors validate the revision again when applying it. A changed target or executor version can report unsupported_capability even after the preview passed; that target keeps its previous revision. Inspect failed targets individually instead of treating publication as completion of the rollout.

Policy → Adoption distinguishes pending, applied, failed, and offline. An applied revision establishes configuration adoption, not that an attack was blocked. Check the feature's events for the expected rule ID, revision, and observed action using a benign pilot test. Newly enrolled devices enter the baseline until a more specific assignment is applied.

Offline behavior and rollback

Offline agents and gateways retain their last applied policy. On reconnect, they reconcile to the current published assignment; intermediate revisions need not execute. Response actions have separate deadlines and cannot be requeued by policy synchronization.

To roll back, open Policy → Revisions → Revision → Create draft from revision, review the target set, and publish it as a new revision. Under Policy → Adoption, confirm each target applied it. Prior revision IDs remain unchanged.

Policy rollback changes future enforcement. To release existing endpoint containment, use Release isolation or quarantine restoration. A transfer already blocked must be retried through its application after the corrected policy is applied.

Exceptions and deletion

Create bounded exceptions instead of removing protection for an entire group. An assigned policy cannot be deleted. Reassign its targets, verify adoption, then use Policy → Retire. Retiring removes it from new selection while preserving revision references in incidents and audit history. See Policy API for concurrency and publication requests.