PostgreSQL logical replication vs agent proxies: WAL witness

As engineering organizations grant autonomous AI agents tool access to production systems, securing the boundary between natural language reasoning and relational storage has become urgent. Many teams deploy pre-call proxy gateways, API wrappers, or prompt inspection firewalls. These intermediaries inspect outgoing JSON-RPC messages, match regular expressions against tool arguments, and decide whether a query is permitted to leave the agent environment.

While pre-call inspection catches rudimentary prompt injections, it suffers from a fundamental architectural limitation: it operates entirely before database execution occurs. A network gateway sitting on a Unix socket or HTTP connection observes only the text sent by the client. It cannot observe what PostgreSQL actually commits to persistent disk.

When an autonomous agent executes a query, secondary database effects routinely cause reality to diverge from the agent reported plan. Database triggers fire recursively, cascading foreign key constraints delete related entities, and multi-statement transactions execute hidden state changes. Datadog Security Labs demonstrated this disconnect dramatically in their analysis of the official PostgreSQL Model Context Protocol server¹. By prepending a COMMIT statement, an injected query escaped a transaction wrapped in read-only syntax and dropped entire database schemas without the client reporting an error.

Closing this verification gap requires moving beyond pre-call network proxies. True database write safety demands an authoritative post-execution witness rooted in PostgreSQL native Write-Ahead Log (WAL) replication stream.

The illusion of pre-call network gateways

Pre-call proxies operate under an implicit assumption: that examining the text of a SQL query allows a security layer to predict its full impact. In relational database engines, this assumption is demonstrably false.

Consider an agent tasked with archiving inactive user sessions:

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

UPDATE users SET status = 'archived' WHERE last_login < '2025-01-01';

A pre-call proxy examines the SQL abstract syntax tree (AST). It observes an UPDATE command targeting the users table with a WHERE predicate. Because the command does not contain DROP, ALTER, or TRUNCATE, the proxy marks the operation as low risk and forwards it to the PostgreSQL instance.

However, the proxy cannot determine:

1. The exact row count affected by the WHERE predicate against current table state.
2. Whether an existing AFTER UPDATE trigger mutates rows in the billing, audit, or subscriptions tables.
3. Whether foreign key cascade rules propagate changes to child records across separate schemas.
4. Whether connection session settings alter timezone or collation semantics, expanding the matched set unexpectedly.

The agent reports to the orchestrator: “I updated 1 user record.” In reality, the query matched 4,800 records and triggered cascading ledger adjustments across 12 tables. The pre-call gateway has completed its lifecycle and logged success, blind to the operational incident now unfolding in storage.

How database mutations diverge from agent claims

In our interactive test environment at watch an agent get caught, you can observe this exact failure mode in real time. An agent tool call requests an update to a single order record. The agent claims 1 row modified. Yet an unindexed trigger on the database table updates 301 rows across the schema.

This divergence between agent claims and storage reality falls into three primary categories:

1. Trigger fan-out and cascading mutations

Enterprise schemas rely heavily on triggers for auditing, denormalization, and ledger integrity. When an agent issues a simple UPDATE on a parent record, database triggers can spawn tens or hundreds of secondary INSERT and UPDATE operations. Because these statements originate from inside the database engine, they never transit the external network connection where API proxies reside.

2. Multi-statement injection and transaction boundary escapes

As documented by Datadog Security Labs¹, reference MCP implementations that attempt to enforce safety by running queries inside a transaction wrapper can be bypassed. An injected payload can terminate the active transaction block with an explicit COMMIT, execute arbitrary Data Definition Language (DDL) commands, and leave the client wrapper unaware of the scope of destruction.

3. Concurrency conflicts and lock escalation

In high-throughput environments, an agent UPDATE with an imprecise predicate may trigger table-level locks or conflict with concurrent transactions. The agent may interpret a timeout as a failure and issue a retry, compounding corruption by inserting duplicate records or overwriting concurrent human modifications.

The WAL replication stream under the hood

To obtain an unbending record of what transpired, the verification layer must attach directly to the PostgreSQL storage engine. PostgreSQL maintains durability through Write-Ahead Logging (WAL). Every tuple insertion, update, and deletion is recorded sequentially in the WAL before changes are written to table data pages.

Through PostgreSQL logical decoding infrastructure¹, external systems can stream these committed changes in real time. By establishing a logical replication connection using the pgoutput or test_decoding plugin, an observer receives decoded tuple changes grouped cleanly by transaction commit timestamp:

BEGIN LSN: 0/16B2D40
table public.users: UPDATE: id[integer]:104 status[text]:'archived' updated_at[timestamp]:'2026-11-04 10:15:00'
table public.audit_logs: INSERT: id[integer]:9812 event[text]:'status_change' user_id[integer]:104
COMMIT LSN: 0/16B31F8

Notice the critical distinction: the logical replication stream does not contain abstract SQL strings or client intentions. It contains physical row before-images and after-images. Every column value, old state, and new state is represented concretely as committed by the storage engine.

If table replication identity is configured as FULL (ALTER TABLE users REPLICA IDENTITY FULL;), PostgreSQL logs the complete previous state of every modified row. This architectural capability transforms the database log into an authoritative witness of agent execution.

Comparing claimed intent with disk reality

Deedglass implements this architecture via a lightweight Go engine utilizing native replication protocol drivers (pglogrepl). When an agent issues a database tool call, Deedglass does not simply forward the command and hope for the best. It establishes a deterministic verification loop:

First, the agent issues its tool call through the local gate. Deedglass records the agent identifier, tool arguments, and stated intent.

Second, the command executes against PostgreSQL within an isolated session tag.

Third, Deedglass reads the logical replication slot stream associated with the transaction LSN. It decodes the committed changes, tallying the exact number of modified rows across every table.

Fourth, Deedglass compares the physical row modifications against what the agent claimed:

• Claimed: The agent stated it would update 1 row.
• Checked: The WAL witness observed 1 row modified in the target table, and zero unexpected trigger mutations. Result: Matches.
• Divergence Detected: The agent stated it updated 1 row, but the WAL witness observed 301 row modifications across 3 tables. Result: Divergence flagged immediately.

If your application keeps its data in your own PostgreSQL instance, with logical decoding enabled, Deedglass checks each agent write it runs against the database change log and can undo the rows after a human operator countersigns².

Furthermore, every verified action, authorization decision, and observed tuple delta is sealed into a tamper-evident record signed with dual cryptographic keys³. These cryptographic seals can be verified offline by independent auditors without requiring access to the running database or Deedglass daemon.

Sovereign local execution without cloud leakage

Enterprise engineering teams handling proprietary source code, patient healthcare records, or regulated financial data cannot tolerate security tools that exfiltrate sensitive database contents to third-party cloud analytics.

Many commercial agent firewall services operate as hosted SaaS proxies. Every SQL query, table name, customer identifier, and query result is routed across the public internet to third-party servers for inspection. This architecture introduces severe data sovereignty risks under GDPR, HIPAA, and regional data protection frameworks.

Deedglass is engineered with an uncompromising sovereign design philosophy. Deedglass runs on your own servers with your own PostgreSQL and sends nothing to external servers by default⁴. If you deploy Deedglass in your private virtual cloud, on-premises data center, or sovereign cloud region, your database records, execution history, and WAL decoding streams stay entirely within your security boundary.

The entire witness engine compiles into a single, static binary with zero external runtime dependencies. It connects to PostgreSQL over local loopback or private virtual private cloud (VPC) peering, maintaining microsecond-level latency while delivering absolute data isolation.

Practical implementation and scanning

Transitioning from vulnerable pre-call proxies to an authoritative WAL witness requires three straightforward configuration steps in PostgreSQL:

1. Enable logical replication in postgresql.conf

Set the write-ahead log level to logical to permit replication slot decoding:

Code What the screen or file shows, copied as is.

wal_level = logical
max_replication_slots = 4
max_wal_senders = 4

2. Configure replica identity for critical tables

To ensure before-images are captured for automated row recovery, set replica identity to FULL on tables subject to agent tool execution:

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

ALTER TABLE accounts REPLICA IDENTITY FULL;
ALTER TABLE orders REPLICA IDENTITY FULL;
ALTER TABLE clinical_notes REPLICA IDENTITY FULL;

3. Audit your current agent configurations

Before connecting agents to production databases, measure your current configuration risk exposure. Run our automated configuration scanner directly in your terminal:

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

npx deedglass scan

The scanner inspects your MCP server configurations, tool definitions, and agent permissions, outputting an objective letter grade from A to F based on blast radius containment. You can read the detailed scoring rubric and evaluation criteria at what the scan grade means.

By pairing pre-call rule enforcement with post-execution Write-Ahead Log verification, engineering teams can safely unlock the full productivity of autonomous AI coding agents without gambling database integrity on conversational promises.

Written with AI assistance and checked against our claims register.