Policy DSL Reference

The Interven policy language is a JSON / YAML DSL. Each policy has a name and one or more rules; each rule has a match, condition, action, and priority.

This page is the authoritative reference. For the conceptual primer + common recipes, see Policies.

Structure

{
  "name": "policy name (unique per env)",
  "description": "free text",
  "env_names": ["production"],        // optional; omit = applies to all envs
  "rules": [
    {
      "rule_id": "stable-id-for-audit",
      "priority": 10,
      "match": { /* match keys */ },
      "condition": { /* conditions */ },
      "action": "ALLOW | DENY | SANITIZE | REQUIRE_APPROVAL | OPEN_INCIDENT"
    }
  ]
}

Match keys

match says which scans the rule applies to. Empty {} = every scan. All keys are ANDed together; multi-value fields are ORed within themselves.

Operation reference

The operations array accepts three forms:

Available categories per tool are in the Tools catalog.

Conditions

condition says when a matched scan triggers the rule. Empty {} = always. All keys are ANDed.

body_path_* examples

For body content like {"amount": 14500, "recipient": "..."}:

{
  "body_path_gt": { "path": "$.amount", "value": 10000 }
}

The path syntax is JSONPath subset: $.field, $.nested.field, $.items[*].field.

Combining conditions

{
  "condition": {
    "has_data_class": ["PII"],
    "is_external_principal": true,
    "trust_score_lt": 0.7
  }
}

All three must be true for the rule to fire. There's no top-level OR in the DSL — use multiple rules with the same action instead.

Actions

You can chain side effects with action modifiers (optional fields next to action):

Priority & precedence

Within a single policy: lower priority number wins (priority 10 evaluates before priority 20).

Across policies: each policy's matching rules are collected, then strictness escalates. DENY beats SANITIZE beats REQUIRE_APPROVAL beats ALLOW. So if any matching rule says DENY, the decision is DENY — regardless of priority.

OPEN_INCIDENT is treated as DENY for decision purposes plus the incident side effect.

Wildcards & globs

• Globs in *_patterns fields use shell-glob syntax: * matches anything, ? matches one char, [abc] matches a set.
• Regex is NOT supported; if you need it, use body_contains_any with multiple substrings or split into multiple rules.
• Case-insensitive matching is the default for body text; case-sensitive for URLs and identifiers.

Versioning & idempotency

POST /v1/policies/apply is idempotent on name + env_name. Re-applying the same policy creates a new policy_version row (audit trail preserved) but the active policy with that name in that environment gets the latest config.

To roll back: re-apply the old version's JSON. Or use the Console's "Version history → Restore" button.

Example: full healthcare HIPAA pack rule

{
  "name": "P-HIPAA-1: Deny PHI egress to chat",
  "env_names": ["production"],
  "rules": [
    {
      "rule_id": "phi-egress-chat-deny",
      "priority": 10,
      "match": {
        "tool_names": ["slack", "discord", "teams"],
        "operations": ["post_message", "send_message"]
      },
      "condition": {
        "has_data_class": ["PHI"]
      },
      "action": "DENY",
      "reason_code": "PHI_EGRESS_CHAT_BLOCKED"
    }
  ]
}

Validating policies offline

npm i -g @interven/policy-cli

interven-policy validate policies/*.yaml
# -> reports any DSL errors before you push

CI integration: add interven-policy validate to your linter step.

YAML vs JSON

The DSL accepts either. YAML is recommended for git-tracked policies:

name: "P-HIPAA-1: Deny PHI egress to chat"
env_names: ["production"]
rules:
  - rule_id: phi-egress-chat-deny
    priority: 10
    match:
      tool_names: [slack, discord, teams]
      operations: [post_message, send_message]
    condition:
      has_data_class: [PHI]
    action: DENY
    reason_code: PHI_EGRESS_CHAT_BLOCKED

See also

• Policies primer + recipes
• Starter policy packs
• Risk signals — what feeds risk_score_gt