Enforcement.
How Vericto decides what to do with each query: the split between severity and action, the possible decisions, and observe mode (dry-run) for validating your ruleset before blocking in production.
Overview
Every query that passes through Vericto is analyzed against the workspace ruleset. The analysis produces two distinct things: a severity, which describes how dangerous the query is, and an enforcement action, which describes what Vericto does about it. Separating the two concepts is what lets you tune the response without changing the risk classification.
The action is resolved by the workspace enforcement policy based on the severity. The final result of each query is one of five decisions: ALLOWED, FLAGGED, MONITORED, BLOCKED, or PARSE_ERROR.
Only BLOCKED stops a query. The other decisions forward the query to the database; they differ in the telemetry and alerts they generate. When observe mode is active, not even BLOCKED stops anything: all BLOCK actions are downgraded to FLAG.
Severity versus action
Vericto deliberately treats these two axes separately:
- Severity: how dangerous the query is. It is a property of the rule that fires and does not change between workspaces. The levels are Critical, High, Medium, Low, and Informational.
- Enforcement action: what Vericto does when a query violates a rule. The actions are
BLOCK(stop),FLAG(forward with an alert), andMONITOR(forward and log, no alert). The action is decided by the workspace enforcement policy.
The practical benefit: two organizations may agree that a DELETE without a WHERE is Critical severity, but one chooses to block it and the other only to alert while it adjusts its processes. Severity is a fact about the query; the action is a policy decision.
Per-query decisions
After analysis, each query receives exactly one of these decisions. Only BLOCKED prevents the query from reaching the database:
| Decision | Source action | Behavior |
|---|---|---|
ALLOWED |
— | The query violates no rule. The proxy forwards it to the database unchanged. |
FLAGGED |
FLAG |
The query violates a rule with a FLAG action. It is forwarded to the database, but it generates telemetry and fires an alert to the configured notification channels. |
MONITORED |
MONITOR |
The query violates a rule with a MONITOR action. It is forwarded and logged in the audit trail, without firing alerts. |
BLOCKED |
BLOCK |
The query violates a rule with a BLOCK action. The TCP proxy returns SQLSTATE 42501 and the query never reaches the database. The CLI and API report status BLOCKED and exit_code 1. |
PARSE_ERROR |
— | The query syntax is invalid and could not be parsed. By default Vericto operates fail-open: it forwards the query and logs it, without counting it as a block. The behavior is configurable to fail-closed per workspace. |
Default policy
When you turn on enforcement, Vericto applies this severity-to-action mapping. You can tune it per rule, but these are the starting values:
| Severity | Default action | Resulting decision |
|---|---|---|
| Critical | BLOCK |
BLOCKED |
| High | BLOCK |
BLOCKED |
| Medium | FLAG |
FLAGGED |
| Low | MONITOR |
MONITORED |
| Informational | MONITOR |
MONITORED |
| Parse error | Allow + report (fail-open) | PARSE_ERROR |
Default policy in brief: Critical and High are blocked, Medium is flagged, Low and Informational are monitored, and parse errors are allowed and logged.
Observe mode (dry-run)
Observe mode is a dry-run mode for validating the impact of your ruleset before blocking real traffic. While it is active, all BLOCK actions are downgraded to FLAG: nothing is blocked, but the dashboard shows you exactly which queries would have been blocked and by which rule.
In the actual schema, observe mode is controlled by a time window: while NOW() < observe_mode_expires_at, every BLOCK decision is downgraded to FLAG. There are two related fields: observe_mode_expires_at (when the window expires) and monitor_mode (a boolean).
Choice during onboarding
When you connect your first database you choose between two modes:
- Observation (recommended): a 7-day window in which Vericto blocks nothing and only flags what it would have blocked. Ideal for measuring impact with no risk.
- Immediate protection: enforcement is active from the very start and
BLOCKactions stop queries for real.
How to turn on real enforcement
While observe mode is active, the dashboard shows a banner with the days remaining in the window. You can leave observe mode and turn on real enforcement at any time from Dashboard → Rules. Once you leave, BLOCK actions start stopping queries again immediately.
While observe mode is active, your database is not protected against destructive queries: everything is forwarded. Use it to calibrate your ruleset and move to real enforcement as soon as you are confident about the impact.
The state can be read and changed via API with GET and PATCH on the enforcement-policy endpoint, which exposes the fields observe_mode_active, observe_days, and monitor_mode.
Parse error handling
When a query has invalid syntax and Vericto cannot parse it, there is no AST to analyze against the ruleset. The behavior in that case is defined by the workspace policy:
- Fail-open (default): the query is forwarded to the database and logged as
PARSE_ERROR. It does not count as a block. It prioritizes availability: a malformed query usually fails on its own in the database engine. - Fail-closed (configurable): the query is blocked if it cannot be parsed. It prioritizes security, at the cost of rejecting queries the parser does not recognize even if they were legitimate.
The default is fail-open because it avoids outages from SQL dialects or constructs the parser does not yet cover. If your environment requires that nothing reaches the database without being analyzed, switch to fail-closed in the workspace configuration.
Frequently asked questions
What is the difference between severity and action?
Severity describes how dangerous a query is and is a property of the rule that fires. The action describes what Vericto does (block, flag, or monitor) and is decided by the workspace enforcement policy. You can change the action without changing the severity.
What does the client receive when a query is blocked?
The TCP proxy returns SQLSTATE 42501 and the query never reaches the database. With the CLI or API, the status is BLOCKED and the exit_code is 1, which lets you fail a CI/CD pipeline on a dangerous query.
Does observe mode protect my database?
No. In observe mode all BLOCK actions are downgraded to FLAG, so no query is stopped. It is for measuring the impact of your ruleset, not for protection. Move to real enforcement from Dashboard → Rules when you are ready.
Can I change the action for a specific severity?
Yes. The default policy table is only a starting point. You can tune the action per rule from Dashboard → Rules, for example lowering a High rule from BLOCK to FLAG while you adapt your processes.
What happens if Vericto cannot parse a query?
By default, in fail-open, the query is forwarded and logged as PARSE_ERROR, without counting as a block. If your workspace is in fail-closed, the query is blocked because it cannot be analyzed.