Denial reasons

When Midplane denies a query, the MCP tool result and the DECIDED audit row both carry a policy_rule naming the rule that denied, plus a human-readable reason. This page maps each rule to the cause and the fix. The engine evaluates four rules in order, and the first rule that denies wins. The order is parse_error → multi_statement → table_access → dangerous_statement. Two are always-on guards (parse_error, multi_statement); the rest are driven by your policy — table_access and the dangerous_statement guardrails default on. See the policy engine.

`policy_rule`	Default	Cause
`parse_error`	Always on	The SQL didn’t parse.
`multi_statement`	Always on	More than one statement in one query.
`table_access`	On (`read`)	A read or write the table’s access level doesn’t grant.
`dangerous_statement`	On (`0.9.0+`)	A whole-table write (no `WHERE`) or a DDL statement, regardless of `table_access`.

`table_access`

A query referenced a table at a permission level its policy doesn’t grant. A query is denied if any referenced table fails — including writes hidden in CTEs, subqueries, UNION arms, or JOINs, caught by the recursive AST walk. There are three sub-cases:

Cause	Fix
Write blocked — a write (`INSERT` / `UPDATE` / `DELETE`) to a table that’s `read`.	Mark the table `read_write` in `table_access.tables`.
Read blocked — a `SELECT` from a table that’s `deny`.	Mark the table `read` (or `read_write`).
No target / unlisted — the table falls through to a `default` that denies the access (`default: deny`, or a write under `default: read`).	Add a per-table override, or raise the `default` (carefully).

-- with table_access.tables.users = read:
DELETE FROM users WHERE id = 1     -- DENY (users is read; writes need read_write)
SELECT * FROM audit_log            -- DENY (audit_log is deny; no access at all)

To grant the write, mark the table read_write:

table_access:
  default: read
  tables:
    users: read_write

Run midplane policy test to confirm the change before you ship it.

`multi_statement`

The query contained more than one top-level statement. Midplane allows exactly one statement per query — stacked statements (the classic SQL-injection vector) never reach the database.

SELECT 1; DROP TABLE users;   -- DENY (2 statements)
SELECT 1;                     -- ALLOW (trailing semicolon, still 1 statement)

Fix: split the query into one statement per call. A trailing semicolon is fine; a second statement is not.

`dangerous_statement`

A guardrail denied a categorically-destructive operation — regardless of table_access. On by default (0.9.0+), so this fires even on a table you’ve marked read_write. Two independent guards produce it:

Cause	`policy_rule`	Fix
Whole-table write — a `DELETE` / `UPDATE` with no `WHERE` clause.	`dangerous_statement`	Add a `WHERE` that scopes the rows you intend to change, or set `guardrails.block_unqualified_dml: false`.
Schema change (DDL) — a `DROP`, `TRUNCATE`, or `ALTER`.	`dangerous_statement`	Run the DDL out-of-band, or set `guardrails.block_ddl: false`.

DELETE FROM orders            -- DENY (no WHERE — whole-table write)
DELETE FROM orders WHERE id=1 -- the WHERE makes it qualified (dangerous_statement passes)
DROP TABLE orders             -- DENY (DDL)

The agent-facing message names the operation and the flag to relax it, for example:

Midplane denied this query because this DELETE on `orders` has no WHERE clause,
which would affect every row in the table. Add a WHERE clause that scopes the rows
you intend to change. This guardrail blocks whole-table writes regardless of
table-access policy; set `guardrails.block_unqualified_dml: false` in your policy
YAML to disable it.

Because the guardrail runs last, a statement another rule would also deny (for example a DROP under the no-YAML deny-all-writes default) surfaces that other rule’s reason instead — the statement is blocked either way. See the guardrails schema.

`parse_error`

The input failed to parse. libpg_query, the real Postgres parser, decides this — anything that isn’t valid Postgres SQL is denied. Midplane never enforces policy on text it can’t read. Fix: rewrite the query as valid Postgres SQL. Midplane parses with the Postgres parser, so dialect-specific or exotic syntax it doesn’t recognize is denied — rewrite it into a supported form.

Result masking

column_masking is not one of the ordered policy rules above — those decide whether a query runs. It fires when the engine can’t safely apply column masking to a query that touches a masked table, failing closed: the query is denied before it runs and all rows withheld rather than risk returning an unmasked value.

`policy_rule`	When	Behavior
`column_masking`	A query references a masked table in a shape the engine can’t safely rewrite — a view over a masked table, a whole-row or composite serialization (`to_jsonb(users)`, `row_to_json`), an opaque or dynamic-SQL function (`query_to_xml`, `dblink`, a UDF), a system column, or a stale catalog.	Fail-closed — the query is denied before execution, every row withheld, nothing leaks.

Plain aggregates and joins over a masked table are not denied — they rewrite and run. The agent-facing message hints at the fix: query the masked column directly rather than through a view, a whole-row serializer, or an opaque function, so the engine can mask it at the source. See column masking for the mechanic and transforms.

Still stuck?

If a query is denied and you can’t tell why, dry-run it with midplane policy test — it prints the deciding rule and the exact agent-facing message against your policy file, with no database connection. For more, see troubleshooting.

Troubleshooting

Common denials, connection problems, and agent-wiring issues.

Configuration

Protocol & data

`table_access`

`multi_statement`

`dangerous_statement`

`parse_error`

Result masking

Still stuck?

Troubleshooting

​table_access

​multi_statement

​dangerous_statement

​parse_error

​Result masking

​Still stuck?

Troubleshooting

`table_access`

`multi_statement`

`dangerous_statement`

`parse_error`

Result masking

Still stuck?