Custom Rules.

What are custom rules?

Vericto's standard rules cover the most common destructive patterns (DELETE without WHERE, DROP TABLE, TRUNCATE, etc.). Custom rules let you extend that ruleset with conditions specific to your business, defined through a YAML condition over the query's AST syntax tree.

Like all Vericto rules, custom rules are deterministic: the same input always produces the same result. There are no ML models, no variance. A query either meets the condition or it doesn't, no ambiguity.

Common use cases:

• Block SELECT * (bulk exfiltration). A SELECT cannot be scoped to one table; to protect specific columns, tag them in Sensitive columns
• Prevent UPDATE without a WHERE clause on high-criticality tables
• Detect calls to dangerous functions like SLEEP() or PG_SLEEP()
• Block TRUNCATE and DROP TABLE at runtime, outside migrations
• Scope a DELETE or UPDATE without WHERE to one critical table with relation

Availability by plan

Custom rules are available starting with the BUILDER plan ($79/mo).

If you try to create a custom rule on the Free plan, the API responds with 403 Forbidden (code PLAN_UPGRADE_REQUIRED) and an upgrade link. At your plan's limit the same response carries reason: "custom_rule_limit".

YAML schema

Each custom rule carries a YAML condition that defines when it fires. The only required field is node_type; rule is an optional label.

rule: nombre-interno-de-la-regla   # identificador libre
node_type: DeleteStmt              # tipo de nodo AST a capturar
condition:
  where_clause: null               # solo si falta WHERE

YAML fields

AST node types

AST nodes represent the type of SQL statement or expression that Vericto detects in the syntax tree. The dialect determines which parser is used (pg_query for PostgreSQL, sqlparser-rs for MySQL).

Available conditions

Inside condition: you can use the following predicates, grouped by the node type they apply to. Combining them matters: a predicate the node never carries would make the rule never fire, so Vericto rejects that combination when you save or preview (error NEVER_FIRES, with the line), in the dashboard and in the API. Example: target_list: "*" with relation on a SelectStmt.

For DELETE / UPDATE / INSERT / ALTER TABLE

For DELETE / UPDATE / SELECT

For SELECT

For FuncCall

For DropStmt

For AlterTableStmt

Practical examples

1. Block SELECT * (mass exfiltration)

rule: block-select-star
node_type: SelectStmt
condition:
  target_list: "*"

Blocks queries like SELECT * FROM users or SELECT * FROM payments. Allows queries with explicit columns like SELECT id, email FROM users.

2. Block UPDATE without WHERE

rule: block-update-no-where
node_type: UpdateStmt
condition:
  where_clause: null

Blocks UPDATE users SET status = 'blocked' but allows UPDATE users SET status = 'blocked' WHERE id = $1.

3. Detect SQL injection tautologies

rule: block-or-tautology
node_type: DeleteStmt
condition:
  where_always_true: true

Blocks queries like DELETE FROM users WHERE id = 1 OR 1=1 by detecting the trivially true OR branch in the AST.

4. Block SLEEP calls (DoS) — one rule per dialect

# MySQL
rule: block-sleep-calls
node_type: FuncCall
condition:
  func_name: sleep

# PostgreSQL — la función tiene otro nombre
rule: block-pg-sleep-calls
node_type: FuncCall
condition:
  func_name: pg_sleep

func_name matches the exact function name (case-insensitive), not a family. MySQL calls the function SLEEP and PostgreSQL calls it PG_SLEEP, so one rule does not cover both: func_name: sleep lets SELECT pg_sleep(10) through silently. Verified against the proxy. To cover both, create both rules. The built-in VERICTO-070 does cover the whole family, because it is implemented in the engine rather than as a predicate.

5. Block SELECT without LIMIT

rule: require-limit-on-select
node_type: SelectStmt
condition:
  has_limit: false
message: "Las queries SELECT deben incluir cláusula LIMIT para evitar scans completos de tabla"

Useful for very large tables where a full scan without a limit can significantly degrade performance.

6. Block DROP of any object

rule: block-all-drops
node_type: DropStmt

Without condition:, the rule triggers for any DROP (TABLE, INDEX, SCHEMA). Useful in production environments where no DROP should run from the application.

7. Protect a specific table

rule: protect-payments
node_type: DeleteStmt
condition:
  relation: payments
  where_clause: null

With relation you scope the rule to a single table: it blocks DELETE FROM payments without WHERE, but leaves other tables untouched. Combine any predicate with relation to limit its scope.

8. Block DROP COLUMN

rule: block-drop-column
node_type: AlterTableStmt
condition:
  alter_kind: drop_column

Blocks ALTER TABLE users DROP COLUMN email (irreversible data loss) but allows other changes like RENAME or ADD COLUMN.

Monitor first, then enforce

A new custom rule starts in monitor mode: the engine evaluates it and records its matches in the audit trail, but it never blocks. When you trust it, open it in Rules and use Promote to enforce: the confirmation says what the rule will do in your workspace (for example BLOCK) and links its latest simulation, or warns you when you did not simulate it, when the simulation failed or when it found legitimate flows that would break. You can go back to monitor at any time.

How it works: the engine has no per-rule action, it resolves every match through the policy's severity → action map. So a monitor rule is sent to the engine with the mildest severity of your policy that does not block (Monitor or, if there is none, Flag). Its events show that severity; the rule keeps its own, which is what promoting it puts into force. If every severity of your policy blocks, a monitor rule is paused (not evaluated) and the dashboard says so.

Rules that existed before this change stay enforced, exactly as they were: no rule in production changed behaviour. In the API, POST /rules/custom accepts "mode": "enforce" if you want a rule enforced from the start, and PATCH /rules/custom/:rule_id with {"mode": "enforce"} promotes it; the change is recorded in the audit log as rule.mode.changed.

To edit a rule, open it: you see its condition, its history and its latest simulation. While you edit, the condition is checked as you type, and before saving you see a side-by-side diff against the saved version.

Preview before activating

Before saving a custom rule, the dashboard offers a preview that evaluates the YAML against the workspace's historical queries from the last 7 days.

The preview shows:

• Whether the YAML is valid (validation_result.valid: true/false)
• How many historical queries this rule would have blocked
• An example query that triggers the condition
• List of matching audit trail events

For a change with more at stake, the rule simulator replays your workspace's traffic (up to 30 days on Builder, 90 on Team and per contract (up to 180) on Enterprise; you choose the window on each run) with the new or edited rules, compares them with the current ones and separates the legitimate flows that would break. From the dashboard or from CI, on Builder plans and above.

REST API for custom rules

Create a custom rule

POST /api/v1/workspaces/:workspace_id/rules/custom
Authorization: Bearer <token>

{
  "name": "Bloquear SELECT * (cualquier tabla)",
  "description": "Obliga a listar columnas explícitas; evita exfiltración masiva",
  "severity": "high",
  "dialect": "postgres",
  "ast_condition_yaml": "rule: block-select-star\nnode_type: SelectStmt\ncondition:\n  target_list: \"*\"",
  "mode": "monitor"
}

// Response 201
{
  "rule_id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
  "code": "CUSTOM-001",
  "name": "Bloquear SELECT * (cualquier tabla)",
  "severity": "high",
  "is_active": true,
  "mode": "monitor",
  "created_at": "2025-06-20T10:00:00Z",
  "validation_result": { "valid": true, "errors": [] }
}

// Promote it to enforce
PATCH /api/v1/workspaces/:workspace_id/rules/custom/:rule_id
{ "mode": "enforce" }

// A condition that can never fire: 400
{
  "error": {
    "code": "INVALID_RULE_CONDITION",
    "details": [
      { "field": "ast_condition_yaml", "code": "NEVER_FIRES", "line": 4,
        "params": { "key": "relation", "node_type": "SelectStmt" },
        "suggestion": "sensitive_columns" }
    ]
  }
}

Preview before saving

POST /api/v1/workspaces/:workspace_id/rules/custom/preview
Authorization: Bearer <token>

{
  "ast_condition_yaml": "rule: block-select-star\nnode_type: SelectStmt\ncondition:\n  target_list: \"*\"",
  "dialect": "postgres",
  "lookback_days": 7
}

// Response 200
{
  "matching_queries": [...],
  "total_matches": 3,
  "validation_result": { "valid": true, "errors": [] },
  "example_triggering_query": "SELECT * FROM users"
}

Required fields

Current limitations

• YAML conditions only support the predicates documented above: you can't write arbitrary expressions over the AST yet.
• A SELECT cannot be scoped to one table: the engine records no table for a SELECT. For personal data, tag the columns in Sensitive columns.
• Maximum of 5 custom rules on the Builder plan, 20 on Team and unlimited on Enterprise.
• The condition is validated on the server (and in the dashboard as you type): malformed YAML, an unknown predicate or a combination that never fires returns 400 with code INVALID_RULE_CONDITION and, in details, each problem with its code and line.
• Custom rules don't support data-modifying CTEs yet (e.g.: WITH x AS (DELETE ...)). Standard rules VERICTO-001 through VERICTO-020 do detect them.

Do you have a use case the current conditions don't cover? Write to us. Real customer cases guide the roadmap for new predicates.