Skip to main content
Customer guide

Policies and detectors

Choose an approved policy scope, validate a synthetic finding and read back adoption.

For: Security policy owner, Detector author, Approver

Before you begin

Name an accountable policy owner, a distinct approver where required and the exact data type and surface. Use synthetic values or an approved transformed exact-data corpus; do not upload customer originals to test a rule.

  1. Write the intended action and population before editing.
  2. Confirm the current mandatory hard-stop floor.

Supported scope and current status

The public site describes issuer-format validation, exact-data matching from transformed records and scoped detectors. A detector type in a registry is a capability claim, not proof that a policy is active on every surface.

  1. Choose the surface on /coverage.
  2. Check whether its action is pre-send enforcement, local observation or post-event discovery.

Compare this path with the published coverage table and the coverage guide.

Set up the path

Create or review the selected rule with the release-specific console workflow. Approve the exact scope and version, then publish it to the intended sensor or gateway; drafting a rule does not activate protection.

  1. Use one synthetic positive and one synthetic negative input.
  2. Read back the published version and adoption state.

Use the workflow

Exercise the approved rule through the named surface. Keep allowed, transformed and blocked outcomes distinct; only a supported path can perform a pre-send change.

  1. Observe what the destination received.
  2. Record the policy revision and detector identity without exposing the matched value.

Verify the result

Match the finding and action to the active policy version and actual downstream bytes or refusal. A preview or detector match alone is not an enforcement readback.

  1. Confirm the expected result on the selected surface.
  2. Check a negative value to expose overbroad matching.

Coverage references: 14 requirements, 0 currently passed

This guide is bound to 14 requirements in RedactWall's acceptance crosswalk, which is maintained internally and not published. A requirement counts as passed here only after current evidence for every bound scenario and authority has been published; none has been published yet.

See the public verification overview and the documentation coverage guide.

Denials and recovery

If approval is stale, a mandatory rule would be weakened or a detector cannot load, leave the prior approved policy in force and do not treat an empty result as clean.

  1. Have the appropriate owner correct the rule or input.
  2. Repeat the synthetic positive and negative checks after a fresh adoption read.

For customer-side next steps, read Recovery and support.

Billing and integration handoffs

Policy authority is separate from device seats and from each provider connection. A rule must be distributed to the exact enrolled device, routed gateway or configured connector where it is expected to act.

  1. Coordinate the surface administrator’s adoption handoff.
  2. Review /pricing before cohort expansion.

Limits to keep in view

A configurable category does not imply every detector, AI transformation or remediation is currently available. The market policy workflows have no current passed public evidence row, so require exact release proof before a customer-data test.

  1. Do not infer enforcement from a preview.
  2. Keep unsupported data formats and bypass paths visible.

Review the current Disclosures before relying on a capability.