Skip to content

Docs

Team and Enterprise

Guardrails

Guardrails are policies matched against a query/command before it runs. Each rule has a regular-expression pattern and an action: allow, deny, or require_approval. Rules are evaluated by priority (lowest number first) and the first match wins; if nothing matches, the action is allow (RBAC still applies).

Create a rule

  1. Go to Guardrails → New rule.
  2. Give it a name and a regex pattern (matched case-insensitively against the statement).
  3. Choose an action and severity, and a priority (lower = checked first).
  4. Save. Toggle Enabled on/off any time.

In a hurry? On the Guardrails page, Apply recommended baseline installs a curated set of high-severity rules in one click. It's idempotent — rules you already have are skipped, so it's safe to re-run, and it never changes anything until you click it.

Test before it bites

Writing a regex you can't try is a foot-gun. Two ways to check one:

  • On the Guardrails page, expand Test a command or query, pick a target type and paste a sample. It runs the sample through the whole rule set (server-side, honest priority + scoping) and shows the decision and which rule matched — nothing is executed.
  • While editing a rule, the Test against a sample field shows live whether the pattern matches what you paste. That's a client-side preview (JS regex); the server uses Go RE2, so use the page-level test for the authoritative answer.

Common rules (recipes)

Copy the pattern into a new rule and pick the action. Patterns are case-insensitive, so drop also matches DROP.

Guardrails run on every query before it executes — reads included. So yes, you can gate or block plain SELECTs too (e.g. require approval to read a sensitive table). RBAC's read/write split is separate and applies first.

SQL (Postgres / MySQL)

\bdrop\s+(table|database|schema)\b deny

Block dropping tables, databases or schemas outright.

\btruncate\b deny

Block TRUNCATE (instant, irreversible data wipe).

^\s*delete\s+from\s+[^\s;]+\s*;?\s*$ deny

Block a bare DELETE FROM <table> with no WHERE filter. The engine is RE2 (no lookahead), so the UPDATE-without-WHERE case can't be written as one negative match — gate writes behind approval instead.

\b(delete|update|insert)\b require_approval

Require approval before any write (DELETE / UPDATE / INSERT).

\b(grant|revoke|alter\s+user|create\s+role)\b deny

Block privilege / user-management statements.

\bfrom\s+payments\b require_approval

Require approval to read a sensitive table (e.g. payments / pii) — yes, this gates SELECTs.

\bselect\s+\* require_approval

Discourage unbounded SELECT * (gate it behind approval).

\bselect\b require_approval

Aggressive: require approval for any read on this target.

Redis

^\s*(flushall|flushdb)\b deny

Block wiping the whole keyspace.

^\s*(config|shutdown|keys)\b require_approval

Gate admin / expensive commands (CONFIG, SHUTDOWN, KEYS *).

Mongo

"(drop|dropDatabase|deleteMany)" deny

Block destructive Mongo commands (the query is a JSON command document).

SSH (server terminals)

Set the rule's target type to server (or * for everything). The pattern is matched against each command line you type — evaluated when you press Enter, before the command reaches the host. A denied command is never run; the line is cleared and a notice is shown.

\brm\s+-rf?\b.*\s/(\s|$) deny

Block recursive deletes that touch the filesystem root.

\b(shutdown|reboot|halt|poweroff)\b deny

Block commands that take the host down.

\bsystemctl\s+(stop|restart|disable)\b require_approval

Gate service-disrupting actions behind a just-in-time grant.

Important — SSH command rules are best-effort, not a hard boundary. They reconstruct the typed line, so a determined user can bypass them (bash -c "…", base64/eval, here-docs, :!cmd from an editor, history recall, or pasting multi-line scripts). Parsing is also suspended inside full-screen apps (vim, htop, less), where Enter is not a command boundary. Treat them as a guard against mistakes and casual misuse — real enforcement stays in RBAC, the per-server require approval to connect flag, and full session recording/replay.

Kubernetes & Docker resource actions

Set the rule's target type to kube or docker (or *). These gate every mutating resource task — apply, setimage, scale, restart, start/stop, delete — whether run from the Resource manager or a scheduled task. The pattern is matched against a stable statement line built from the action and its target, e.g. kubernetes.delete Deployment/api ns=production or docker.scale Service/web replicas=0.

^kubernetes\.delete\b.*\bns=production\b deny

Block deleting anything in the production namespace (target type kube).

\breplicas=0\b deny

Block scaling any workload / service to zero (target type *).

\bimage=\S+:latest\b deny

Block rolling out a mutable :latest tag via setimage / apply.

^docker\.delete\b require_approval

Gate removing any Docker container / service / volume / network (target type docker).

Pick a starting rule from the templates on the New rule page — there's a Kubernetes and a Docker tab alongside SQL / Redis / Mongo / SSH.

Allow exceptions

Because the first matching rule wins, put a narrow allow rule at a lower priority (checked first) to carve an exception out of a broader deny:

# priority 10 — allow deletes on the scratch table
pattern:  \bdelete\s+from\s+scratch\b
action:   allow

# priority 100 — deny every other delete
pattern:  \bdelete\b
action:   deny
Regex tips: \b marks a word boundary so \bdrop\b doesn't match "dropdown"; \s+ matches any whitespace; ^ anchors to the start (handy for Redis commands). Patterns match the raw statement text, so they are a safety net, not a SQL parser — keep them simple and layer deny + require_approval.

What happens

  • deny — the query/command/action is blocked, recorded, and a system log is written.
  • require_approval — for interactive sessions (database console, SSH terminal), blocked unless the user holds an active just-in-time grant for that target (see Access requests); the console shows a "Request access" button and the terminal a dismissible banner. For non-interactive work — resource tasks and scheduled tasks — there's no interactive approval step, so require_approval is treated as a block.

Guardrails apply per-statement to the database console, per-command to SSH terminals (target type server), and per-action to mutating Kubernetes / Docker resource tasks — both one-off (Resource manager) and scheduled (target type kube / docker). If the rule set can't be loaded, evaluation fails closed — the action is blocked rather than allowed.

Permissions

guardrail.read guardrail.manage