Policy Engine

Policy as code, enforced on the device.

A declarative YAML policy decides what happens when a detector fires. It's versioned, diffable, and reviewable in a pull request — because a security control nobody can read is a security control nobody can actually verify.

Four actions

Every rule resolves to exactly one.

allow

Let it through and record the decision. The default whenever no rule matches — a security control that blocks by default is a security control people find a way around.

redact

Swap out the sensitive span and send the rest. The person still gets their answer; the card number never leaves the machine.

warn

Show what was found and let the person decide. Good for grey areas, and it teaches where the line is instead of just enforcing it.

block

Stop the send and explain why. Reserved for categories with no acceptable reason to be there — private keys, government IDs.

What a policy looks like

Real syntax from the shipped DSL, not an illustration.

policy.yaml

rules:
  - id: block-secrets
    description: Block API keys, tokens, private keys
    when:
      categories:
        - secrets.aws_key
        - secrets.api_token
        - secrets.private_key
    then:
      kind: block
      message: Secrets are not allowed in prompts.

  - id: redact-contact
    description: Redact emails & phone numbers
    when:
      categories: [pii.email, pii.phone]
    then:
      kind: redact
      replacementTemplate: "[{{category}}]"

  - id: warn-source-code
    description: Warn when source code is pasted
    when:
      categories: [code.source]
      minConfidence: 0.7
    then:
      kind: warn
      message: This looks like source code. Check it's not proprietary.

Rules match on detector categories, raw patterns, or a confidence floor. Every matching rule is considered and the most severe action wins (block, then redact, then warn, then allow). A prompt that matches nothing is allowed through by default.

Versioning and rollback

A policy change is a deployment, and we treat it like one.

Published versions never change

A published policy version is immutable, enforced by the database itself rather than by convention. Tenants are pinned to an exact version, so there's never any ambiguity about which rules were in force when a decision was made.

Every version retained

Publishing a new policy version never overwrites the old one, and a version that has been published can't be deleted, so rolling back is just pinning a previous version.

Decisions carry their policy

Each telemetry event records which policy version produced it. An audit six months later can reconstruct exactly why a prompt was blocked.

Ships with a baseline

A comprehensive default policy comes included, so day one is a working setup to adjust rather than a blank file to fill in.

On the roadmap

Signed policy bundles. Cosign/Sigstore signatures so the extension can verify a policy actually came from your control plane and wasn't tampered with in transit. Designed, not shipped.

Publicly anchored audit log. The audit trail already hashes each entry to the one before it, so a deleted or edited row breaks the chain and is detectable on verification. Anchoring those hashes publicly to Sigstore Rekor, so the proof doesn't depend on trusting us either, is the remaining piece.

Policy simulation. Run a candidate policy against historical traffic to see what it would have caught before you switch it on.

See pricing