Policy

Policies let you override DriftWise's default risk scoring for specific patterns. Use them to escalate risks that matter to your org or suppress known-safe patterns. For endpoint shapes and the policy.Policy schema, see the policy tag of the API reference.

How policies work

A policy is an ordered list of rules. Each rule matches a risk flag pattern (optionally narrowed by resource type) and overrides its severity:

Flag: "public-ingress-0.0.0.0"  →  Default severity: medium
Policy rule: flag_pattern "public-*"  →  Override to: critical
Result: "public-ingress-0.0.0.0" reported as critical

Rules are evaluated in order — the first matching rule wins. Put the most specific rules first if you need carve-outs inside broader patterns.

Saving a policy

Policies are replaced as a whole — the PUT endpoint is a full overwrite, not a patch. Send the complete rule set; anything omitted is removed. The version field auto-increments on each save so consumers can detect stale reads.

Policy mutations are owner/admin only. A viewer installing a permissive policy would mask real drifts for every org member, so the role gate is load-bearing. Before save, each rule's reason field is sanitized — control characters stripped, high-confidence secret patterns redacted, surrounding whitespace trimmed, then truncated to 200 characters. The rule set is then validated; invalid configs return 422 Unprocessable Entity with the failing rule ID (or index, if the rule has no ID yet). Severity values must be supplied in lowercase exactly as listed below — uppercase or mixed-case values fail validation rather than being auto-normalized.

The initial read of an org that has never saved a policy returns an empty one (version: 0, rules: []), not a 404 — callers don't need to special-case "no policy yet."

Rule fields

Field	Type	Required	Description
id	string	yes	Unique identifier within the policy
flag_pattern	string	yes	Glob pattern matching risk flag IDs
resource_pattern	string	no	Glob matching resource types. Empty = all
severity	string	yes	Override: critical, high, medium, low, ignore
reason	string	no	Why this override exists. Sanitized and truncated to 200 chars. Included in the classifier prompt when non-empty

Pattern syntax

Both flag_pattern and resource_pattern support glob matching:

Pattern	Matches
public-*	Any flag starting with public-
*-encryption	Any flag ending with -encryption
*wildcard*	Any flag containing wildcard
exact-flag-id	Only this exact flag
aws_s3_*	Any S3 resource type

Patterns are restricted to [a-zA-Z0-9_*-] — no regex metacharacters, no slashes. Keeps policies easy to reason about and prevents accidental ReDoS.

Severity levels

These are the values a rule's severity field can take. Each one is an override target — when a rule matches, the classifier is instructed to treat the matched flag at this level.

Level	Override target
critical	Highest severity — use for flags that must page on sight
high	Requires attention
medium	Standard severity
low	Acknowledged, non-urgent
ignore	Silence the matched items. Does not lower the overall severity set by other flags on the same change — it only removes the matched flags from consideration

Policy overrides are applied by the LLM classifier. When the classifier falls back to deterministic scoring (e.g. LLM unreachable), policy rules are not applied — scoring reverts to the built-in flag defaults.

Limits

• Maximum 50 rules per policy
• Rule IDs must be unique within the policy
• Patterns must match [a-zA-Z0-9_*-]
• reason field max 200 characters

Examples

Escalate all IAM changes to critical:

{
  "id": "iam-critical",
  "flag_pattern": "iam-*",
  "severity": "critical",
  "reason": "IAM changes require security team approval"
}

Ignore encryption flags on dev resources:

{
  "id": "dev-encryption-ok",
  "flag_pattern": "*-encryption",
  "resource_pattern": "aws_*",
  "severity": "ignore",
  "reason": "Dev environment does not require encryption"
}

Escalate public access on S3 only:

{
  "id": "s3-public",
  "flag_pattern": "public-*",
  "resource_pattern": "aws_s3_bucket*",
  "severity": "critical",
  "reason": "Public S3 buckets are a data leak risk"
}

Endpoint reference

Policy endpoints live under the policy tag of the API reference. Custom rules and plan-noise suppressions — also rule-management surface — share the same tag.