Why prompt firewalls fail to protect production databases from AI agents

The illusion of text-level guardrails

Over the past two years, the enterprise AI security market has invested heavily in prompt firewalls, LLM input classifiers, and content moderation filters. These systems intercept text prompts before they reach a language model, searching for harmful keywords, jailbreaks, or known injection signatures.

While input classifiers are useful for catching coarse conversational attacks, they fail completely when placed in front of an AI agent that executes real actions on databases, APIs, and file systems.

The reason is fundamental: text prompts do not equal database state transitions.

A prompt firewall reads the characters of a prompt. It cannot know what tables exist, what foreign keys link them, what database triggers will fire, or what rows a query will modify once executed against an active relational schema.⁴ When an agent transitions from answering questions to generating tool invocations, security must move from the linguistic perimeter to the data storage perimeter.

The 1-row versus 301-rows scenario

Consider a realistic scenario encountered in automated agent systems:

An AI customer support agent receives a user request to archive a deactivated workspace account. The agent generates a clean, syntactically valid SQL command:

Code A database command in SQL. The text around it says what it does.

DELETE FROM accounts WHERE account_id = 'acc_9812' AND status = 'inactive';

A prompt firewall evaluates this string:

• Does it contain jailbreak keywords? No.
• Is it valid SQL? Yes.
• Does it look like a standard single-record deletion? Yes.

The prompt firewall allows the tool call. The agent executes the statement. The agent reports back to the user: “Account acc_9812 was successfully removed.” In the agent’s internal log, it records that it deleted one row.

However, in PostgreSQL, the accounts table has foreign key relationships configured with ON DELETE CASCADE across projects, audit_events, billing_invoices, and user_memberships. When the database executed that single statement, PostgreSQL committed deletions across 301 rows across six critical tables.

The agent claimed one row. The database changed 301.

No prompt firewall in the world could have caught this, because the blast radius was defined by the database schema and relational constraints, not by the words in the prompt.

Three database realities prompts cannot see

Relational databases operate with execution semantics that text-based guardrails cannot perceive:

1. Cascade constraints and triggers

Foreign keys configured with ON DELETE CASCADE or ON UPDATE SET NULL, as well as AFTER UPDATE triggers that write to audit ledgers or recalculate financial totals, execute entirely within the database engine. What looks like a single-row write on the wire can trigger thousands of row updates under the hood.

2. Missing or flawed WHERE filters

A prompt may appear to target a single user, but an agent suffering from context compaction or logic errors may construct an unconstrained query:

Code A database command in SQL. The text around it says what it does.

UPDATE subscriptions SET status = 'cancelled' -- missing WHERE clause

To an LLM classifier, “cancelling a subscription” is an authorized business action. But executed against the production database, it wipes the subscription status of every paying customer in the company.

3. Transaction isolation and concurrent race conditions

When multiple agents or human users execute concurrent writes, read-after-write anomalies and race conditions can alter the outcome of a query. A prompt firewall has no visibility into transaction isolation levels (READ COMMITTED, REPEATABLE READ, or SERIALIZABLE). A query executed while another transaction holds an uncommitted lock can produce vastly different state outcomes than what the agent anticipated.

The three levels of verification

To provide genuine safety for AI agents touching databases and health records, Deedglass defines three rigorous levels of verification:³

1. Claimed: The agent reports that it executed a tool and returned a success payload. This is what traditional LLM frameworks record today: a pure claim, unverified against physical reality.
2. Checked: Deedglass calls back the target API or queries the resource by its primary key, reading back the fields to confirm that the server state actually matches what the agent claimed to change.
3. Verified from replication log: In PostgreSQL, Deedglass hooks directly into the database’s logical decoding messages (pgoutput), reading the exact commits from disk.¹ If an agent claims it modified 1 row, but the logical decoding stream shows 301 rows were deleted, Deedglass immediately catches the discrepancy (Doesn't match), halts execution, and can reverse the change.

The only safety primitive that holds

If you are deploying AI agents that have write access to databases, records, or external APIs, remember the core principle of system security: never trust an agent’s self-reported claims.

1. Enforce rules before the call: Intercept every tool invocation with Common Expression Language (CEL) policy rules.
2. Require human countersignatures on high-blast writes: Hold destructive queries, bulk modifications, and role grants until a designated person approves.
3. Verify at the commit level: Check what really changed against the database’s own transaction log, and seal every action into a tamper-evident audit record that can be verified offline.²

How cryptographic undo protects state

When an agent deviates from its declared intent, logging the failure is only half the battle. Organizations must be able to restore the affected state without undertaking hours of manual point-in-time database restores.

Because Deedglass captures before-and-after row images via PostgreSQL logical decoding during verified checks, it builds an exact inverse changeset for every executed transaction. If an agent unintentionally updates rows beyond its authorized scope, an authorized administrator can review the inverse changeset and countersign an immediate rollback.

The undo operation executes as a controlled transaction that is itself audited, verified, and sealed into a new signed record. This ensures that recovery is rapid, safe, and completely transparent to audit teams.

Trying the scenario in your browser

You can test this exact 1-row versus 301-rows scenario in your browser without installing anything.

Open the browser playground at /play to interact with an in-browser PostgreSQL instance running under WebAssembly. You can watch an agent trigger unintended cascade writes, observe the verification engine catch the discrepancy, and preview row-level undo in real time.

To evaluate what permissions your local development agents and coding assistants hold against your databases right now, run the free local scan:

Code Commands typed in a terminal. The text around it says what happens.

npx deedglass scan

The scan inspects local MCP configurations, credentials, and database roles without uploading data. You can inspect what the security score means to ensure your databases remain protected against unconstrained agent writes.

Written with AI assistance and checked against our claims register.