Reason codes

Every reason code a Sealr guard can emit, what triggers it, and the guard's default decision.

A reason code is the guard's answer to "why". It appears in the record's verdict, in the Console, and in the deny message your agent sees. Policy rules match on these codes, so they are a stable API: the registry is append-only, and removing or renaming a code is a breaking change.

How to read the tables

Default decision is what the guard concludes when no policy rule matches. It is a conservative fallback, not a setting. A policy rule that matches the operation overrides it in either direction — your policy can downgrade SQL_DESTRUCTIVE_DDL to a warning, or block on TF_DELETE_PRESENT.

Risk class (Low, Medium, High, Critical) travels with the record and is what dashboards and the Exposure Report aggregate on.

Decisions are ordered ALLOW < WARN < REQUIRE_APPROVAL < BLOCK. When several codes fire on one operation, the strongest decision and the highest risk class win, and every code is recorded.

Core / pipeline

These come from the evaluation pipeline itself, before or around a guard.

Code	Trigger	Default decision	Risk
`INPUT_TRUNCATED`	Operation payload exceeded the 1 MiB cap. The guard never ran — oversized input is not parsed.	REQUIRE_APPROVAL	High
`GUARD_PANIC`	The guard panicked. Caught at the pipeline boundary; the record is written as `guard_error`.	REQUIRE_APPROVAL	High
`GUARD_TIMEOUT`	Registered for a guard that exceeds its 25 ms budget.	—	—
`POLICY_STALE`	Registered for decisions made against a policy cache older than 24 h.	—	—
`UNKNOWN_SURFACE`	Registered for an operation arriving on an unrecognized surface or method.	—	—

GUARD_TIMEOUT, POLICY_STALE and UNKNOWN_SURFACE are registered and selectable in policy rules, but no code path emits them today. Guard evaluation runs synchronously without a wall-clock timeout; staleness is handled through the binding's stale_action rather than by attaching a reason code; unrecognized surfaces route to the generic guard, which emits no codes at all. A rule that matches only on one of these three will never fire. Check sealr status for policy_stale instead.

The generic guard registers no codes of its own. An operation that no guard claims is recorded with an empty reason list — recorded, but not classified.

SQL guard

The SQL guard parses with the real PostgreSQL grammar (libpg_query). It is pure: no network, no clock, no connection to your database.

Code	Trigger	Default decision	Risk
`SQL_UNBOUNDED_WRITE`	`UPDATE` or `DELETE` with no `WHERE` clause.	BLOCK	Critical
`SQL_TAUTOLOGY_WHERE`	`WHERE` reduces to a constant-true predicate — `WHERE 1=1`, `WHERE true`.	BLOCK	Critical
`SQL_DANGEROUS_FUNCTION`	`COPY ... TO PROGRAM` or `COPY` with a server-side filename, a `DO $$` block, `ALTER SYSTEM`, or a call to a file/session function (see below).	BLOCK	Critical
`SQL_DESTRUCTIVE_DDL`	`DROP` of a table, schema, database, materialized view, sequence or foreign table; `TRUNCATE`; `DROP DATABASE`; `ALTER TABLE ... DROP COLUMN` or `DROP CONSTRAINT`.	REQUIRE_APPROVAL	Critical
`SQL_PRIVILEGE_CHANGE`	`GRANT`, `REVOKE`, `CREATE`/`ALTER`/`DROP ROLE`, `ALTER DEFAULT PRIVILEGES`.	REQUIRE_APPROVAL	High
`SQL_PARSE_ERROR`	The input did not parse as PostgreSQL. Malformed SQL is never silently allowed on a write surface.	REQUIRE_APPROVAL	High
`SQL_DIALECT_UNSUPPORTED`	Emitted alongside `SQL_PARSE_ERROR` when the text carries non-PostgreSQL markers — a backtick, or `SQL_NO_CACHE`.	REQUIRE_APPROVAL	High
`SQL_CTE_WRITE`	A data-modifying CTE: `WITH ... INSERT/UPDATE/DELETE`.	REQUIRE_APPROVAL on a `SELECT`; on a write statement it raises the risk to at least High and leaves the decision to that statement.	High
`SQL_STRUCTURAL_DDL`	Non-destructive DDL: `CREATE TABLE`, index, view, `CREATE TABLE AS`, schema, sequence, extension, `COMMENT`, `RENAME`, a non-destructive `ALTER TABLE`, `SELECT INTO`, or a `DROP` of an object type outside the destructive list.	WARN	Medium
`SQL_MULTI_STATEMENT`	More than one statement in one operation. Carries no decision of its own — the verdict is the maximum severity across the statements.	—	—
`SQL_RADIUS_UNAVAILABLE`	Registered for a degraded Connected-Mode EXPLAIN radius.	—	—

CREATE FUNCTION is the one exception to the SQL_STRUCTURAL_DDL row: it emits that code but defaults to REQUIRE_APPROVAL at High risk, because a function body is code that runs later.

SQL_RADIUS_UNAVAILABLE is registered but never emitted. Connected-Mode EXPLAIN radius is not implemented — the SQL guard always uses static estimation, and radius.method is static or none on every record.

Functions treated as session-dangerous: pg_read_file, pg_read_binary_file, pg_ls_dir, pg_stat_file, lo_import, lo_export, pg_reload_conf, pg_rotate_logfile, dblink, dblink_exec, dblink_connect, pg_terminate_backend. The scan walks every function call in the parse tree, including nested ones.

Statements outside all of these classes — EXECUTE of a prepared statement, MERGE, anything unrecognized — default to REQUIRE_APPROVAL at High risk with no reason code. Conservative by construction: an unclassified statement is not an allowed one.

Terraform guard

The Terraform guard analyzes terraform show -json plan output. Raw HCL is recorded, not analyzed.

Code	Trigger	Default decision	Risk
`TF_PROTECTED_RESOURCE_DELETE`	The plan deletes or replaces a resource whose type matches a protected pattern.	REQUIRE_APPROVAL	Critical
`TF_DELETE_THRESHOLD_EXCEEDED`	More than 3 deletions in one plan.	REQUIRE_APPROVAL	High
`TF_STATE_COMMAND`	A state-manipulation subcommand in the argv: `state rm`, `state mv`, `import`, `taint`, `untaint`, `force-unlock`, `apply -replace`. These are invisible in a plan.	REQUIRE_APPROVAL	High
`TF_PLAN_PARSE_ERROR`	The payload looked like JSON but did not parse as a plan.	REQUIRE_APPROVAL	High
`TF_DELETE_PRESENT`	The plan contains at least one resource deletion.	WARN	Medium
`TF_REPLACE_PRESENT`	The plan contains at least one delete+create replacement, in either order.	WARN	Medium
`TF_HCL_UNANALYZED`	The payload on a Terraform surface is not JSON, so it is raw HCL. Recorded, not analyzed.	WARN	Medium

Protected type patterns compiled in for V1 (glob-lite, * and ?):

aws_db_instance          aws_rds_cluster           aws_s3_bucket
aws_dynamodb_table       aws_kms_key               google_sql_database_instance
google_storage_bucket    azurerm_*sql*             azurerm_storage_account
*_iam_*                  kubernetes_namespace

The deletion threshold is 3 and the patterns above are compiled in. Both are described in the spec as policy-extensible; in V1 they are not configurable from a policy file.

Git guard

The Git guard reads three input shapes: wrapper argv (git push ...), hook context, and GitHub App events. Content-based detection needs diff visibility, which the App does not have.

Code	Trigger	Default decision	Risk
`GIT_SECRET_PATTERN`	A curated secret pattern matched in visible diff content.	BLOCK	Critical
`GIT_FORCE_PUSH_PROTECTED`	Force push targeting a protected branch.	BLOCK	Critical
`GIT_REF_DELETE`	Remote branch or tag deletion: `--delete`, `-d`, or a `:refspec`.	REQUIRE_APPROVAL	High
`GIT_PROTECTED_DIRECT_PUSH`	A non-force, non-delete push straight to a protected branch.	REQUIRE_APPROVAL	High
`GIT_FORCE_PUSH`	Force push to a ref that is not protected.	WARN	Medium
`GIT_UNSIGNED_COMMIT`	An unsigned commit pushed to a protected branch, when diff content is visible. The guard emits the code; the policy decides whether it matters.	WARN	risk unchanged

Force is recognized from --force, -f, --force-with-lease, --force-with-lease=<ref>, and a +refspec.

Default protected branch patterns: main, master, release/*, prod*.

Secret patterns

GIT_SECRET_PATTERN is tuned for precision, not recall. This is not a DLP product: it catches credentials with recognizable shapes and will miss ones without. 25 patterns cover AWS keys, GitHub and GitLab tokens, Slack tokens and webhooks, Stripe live keys, Google API keys and service account JSON, PEM private keys, JWTs, npm, OpenAI and Anthropic keys, Twilio, SendGrid, Azure storage keys, database URLs with inline credentials, and basic-auth URLs.

On top of that, an entropy gate flags an assignment whose right-hand side is at least 24 characters, has Shannon entropy above 4.0 bits per character, and more than 50% distinct bytes — reported as high_entropy_assignment. Only the kind is recorded. The matched value never leaves the machine and never enters a record.

Using codes in policy

Reason codes are the matching surface for rules. The Console's policy builder lists the same registry this page documents, and sealr policy test shows exactly which codes an operation produces:

sealr policy test ./policy.yaml \
  --integration sql \
  --resource db:prod-main \
  --input "UPDATE accounts SET balance = 0" \
  --json

{
  "guard_decision": "Block",
  "guard_reasons": ["SQL_UNBOUNDED_WRITE"],
  "risk": "Critical",
  "final_decision": "Block",
  "matched_rule": "...",
  "mode": "Enforce"
}

CLI reference

Every subcommand and flag, including policy test.

Configuration

Recorder home layout and Console environment variables.