Database Query Blocklist

A second, narrower safety net. If you ever allow the agent to run raw database reads, the query blocklist stops queries that touch sensitive columns — like password hashes — from returning that data.

The database query blocklist protects against a specific, advanced scenario: an administrator deliberately enabling raw database reads for the agent. By default the agent cannot run raw SQL at all, so on most sites this feature simply sits in the background and never comes into play.

When this matters (and when it doesn’t)

Out of the box, the agent works through Maxi’s structured abilities — and those already have precise, field-level data masking (see GDPR Data Masking). Raw database access is off.

An administrator can turn on read-only database queries by setting a constant in wp-config.php (MAXI_AI_WP_CLI_ALLOW_DB_READS). This is occasionally useful for ad-hoc reporting that no structured ability covers. But raw SQL bypasses the structured masking — so the blocklist exists as the safety layer for exactly that case.

If you’ve never enabled raw database reads, you don’t need to do anything here. The blocklist only acts on raw db query reads, which are disabled by default.

What it does

When raw database reads are enabled, every query is checked against the blocklist twice over:

• Before it runs — if the SQL text itself mentions a blocklisted term (for example, a query selecting the user_pass column), it’s rejected outright.
• After it runs — if the results happen to contain a blocklisted term (for example, a broad SELECT * that pulls a sensitive column along for the ride), the response is rejected before the agent sees it.

Both rejections are recorded in the audit log, so attempts to read protected data leave a trail.

The default protected terms

When raw database reads are first enabled, the blocklist is seeded with the most sensitive WordPress columns:

These are the credentials you’d least want any agent — or the AI provider behind it — to read.

Customizing the list

You can adjust the protected terms by asking your agent, with the same three actions as the masking list:

• List the current blocklist.
• Add terms (for example, a custom table column holding sensitive data).
• Remove terms.

“What’s on the database query blocklist?”
“Add ‘api_secret’ to the query blocklist.”

Managing the blocklist requires an administrator, and every change is recorded in the audit log. One thing to know: if you clear a default term, Maxi respects that choice and won’t silently re-add it — your configuration stands.

In summary: The database query blocklist is a safety net for the advanced case where an administrator has enabled raw database reads. It checks every query both before and after execution and rejects anything touching protected columns — seeded with user_pass, user_activation_key, and session_tokens. It does nothing unless raw reads are enabled (they’re off by default), it’s admin-managed, and every block and change is audit-logged. For normal use, Maxi’s structured abilities and data masking already handle data safety; this is the belt-and-braces layer for raw SQL.