Query risk scoring
Score every statement as low, medium or high risk and choose what each level does.
Risk scoring labels every statement on a connection as low, medium or high risk and lists the reasons. The level appears on audit rows, and you choose what each level does. It works alongside policies. When both apply, the stronger action wins: deny beats approve, approve beats alert, and alert beats allow.
Risk scoring is rolling out gradually and is off by default on every connection. Like policies, it requires the Team plan or higher.
Turning it on
On the Policies page, open Query risk scoring, pick a connection, turn on scoring, and choose an action for each level:
| Level | Default | Typical statements |
|---|---|---|
| Low | Allow | Filtered, bounded reads; filtered writes |
| Medium | Allow | Reads with no filter and no limit, CREATE/ALTER, several statements in one message, calls to custom functions, bulk COPY, statements Relay cannot parse |
| High | Alert | UPDATE/DELETE with no WHERE or one that is always true (WHERE 1=1), DROP/TRUNCATE, GRANT/REVOKE, writes to sensitive tables, code execution (DO, COPY ... PROGRAM, xp_cmdshell, MongoDB $where) |
Actions are allow, alert (run the query and record a policy_alert),
approve (hold the statement until it is approved, as with an approve policy
rule; see Query approvals; needs the query_approvals
flag and current agents) and deny (block it; the database never sees it).
Sensitive tables are globs such as payments, billing.* or *.cards.
Any write to a matching table is high risk.
Planner estimates (PostgreSQL)
For PostgreSQL connections you can also use the planner's estimates. Relay then flags reads that are estimated to return more rows than a threshold, that cost more than a threshold, or that scan a large table sequentially.
- Only single read statements are explained, and only after your policies allowed them. Writes are never explained.
- Relay runs
EXPLAIN (FORMAT JSON)and neverANALYZE, so the query is planned, not executed. It runs on a separate read-only connection with a short timeout (200 ms by default). - If the planner is slow or fails, the score falls back to the rules above.
What you see in audit
Medium and high risk rows show a risk badge. Expand a row to see the level and
the reasons, for example write_without_filter: delete sessions. When a risk
action alerts or denies, the matching policy_alert or policy_blocked event
has rule id risk:<level>.
Performance
Without planner estimates, scoring reuses the parse the agent already does and adds well under a millisecond per statement. Planner estimates add one round trip to the database, bounded by the timeout.
External verdicts
Agent operators can point the agent at their own verdict service, for example
an LLM, with RISK_VERDICT_URL. The service receives each statement that
policies allowed, and can only raise its level. If the service fails or times
out, the agent keeps its own score. The URL is set on the agent host and is never
sent from Relay.