CEL policies

Match authenticated, structured tool calls with bounded CEL expressions and turn matches into DefenseClaw findings.

DefenseClaw uses a deliberately narrow CEL engine to match authenticated, structured tool calls. CEL sees normalized command, path, network, and data-flow facts—not raw connector payloads—and returns a Boolean match. The rule supplies the finding metadata, while the active policy profile maps that finding to allow, alert, confirm, or block.

CEL complements OPA/Rego

CEL performs semantic matching inside a trusted tool-call boundary. OPA/Rego continues to own admission, firewall, sandbox, audit, and policy-domain decisions. CEL does not scan prompts or ordinary tool-result text and does not expose a separate policy endpoint.

Author CEL rules

Learn the rule schema, ActionFacts model, enum constants, portable predicates, and validation workflow.

Understand the CEL engine

Review the admitted language subset, compiler and runtime limits, ownership, fallback, and evaluation behavior.

Stateful connector lifecycle

See connector outcome guarantees, ordered-state behavior, tool-surface matrices, and rollout holds.

Validate rule packs

Use the authoritative loader locally or in CI before activating a candidate pack.

Where CEL fits

The connector contract establishes trust. CEL never trusts a payload to declare itself structured, and an uncertain projection stays on that rule owner's regex fallback.

The authenticated route and its server-resolved action contract establish the tool-call boundary. This includes trusted single-call inspection and supported native pre-tool hooks; only the latter can participate in durable ordered state. DefenseClaw normalizes the action into private ActionFacts and exposes one typed variable, f, to CEL. A semantic rule owner takes exactly one route: authoritative facts plus CEL, or that same owner's compatible regex fallback.

Start with a complete rule

Add organization rules in a file with a unique category. This example finds a command that reads a protected directory and joins the command to its path by ID so facts from different commands cannot accidentally satisfy the rule.

rules/my-org.yaml

version: 1
category: my-org
rules:
  - id: ORG-PAYMENTS-SECRETS
    tool_call_only: true
    expression: >-
      f.commands.exists(c,
      defenseclaw.guardrail.semantic.v1.OperationKind.OPERATION_KIND_READ in c.operations &&
      f.paths.exists(p, p.command_id == c.id &&
      p.access == defenseclaw.guardrail.semantic.v1.PathAccess.PATH_ACCESS_READ &&
      (p.resolved == '/srv/payments/secrets' ||
      p.resolved.startsWith('/srv/payments/secrets/'))))
    pattern: '(?i)(?:^|\s)/srv/payments/secrets(?:/|\s|$)'
    title: "Payments secret directory read"
    severity: CRITICAL
    confidence: 0.95
    tags: [credential, payments, file-sensitive]

The expression only decides whether the action matches. A true result creates the YAML-defined finding; connector mode, severity thresholds, HITL, and enforcement evidence determine the runtime action. The required pattern preserves compatible detection when structured facts are not authoritative.

Continue with Authoring CEL rules to adapt this rule to command, path, network, and data-flow cases.

Validate and activate

Compile the candidate with the same Go loader used by the gateway, then restart with the exact directory. Rule-pack files are not live-watched.

defenseclaw guardrail validate-pack \
  ~/.defenseclaw/policies/guardrail/my-org

defenseclaw setup guardrail \
  --rule-pack-dir ~/.defenseclaw/policies/guardrail/my-org \
  --restart

defenseclaw doctor

Exit 0 means the candidate is valid, 1 means it is invalid, and 2 means the authoritative validator was unavailable. Validation proves that the pack is admissible; exercise representative positive and negative calls in observe mode before enabling action mode. See Validate rule packs for CI output and partial-pack behavior.

Choose the next page

If you need to…	Continue with…
Write or review expressions	Authoring CEL rules
Understand admission, limits, fallback, or enforcement evidence	CEL engine
Check connector pairing, ordered chains, or artifact promotion	Stateful connector lifecycle
Validate a complete pack locally or in CI	Validate rule packs