Blog

The agent wasn't lying. It passed on what Postgres told it. Here is the run, the output, where the other 300 rows came from, and how they went back.

Twenty checks, grouped by what goes wrong. Most need no new tools, just SQL and a few decisions written down. Start with the first section; it finds most of the problems.

"The tool returned success" can mean three very different things. Naming the level of evidence behind each result is how you know which results to trust, and which to go and look at.

An MCP server is a process that holds your credentials and does what a model asks. Most of its security comes down to what it can reach, who can talk to it, and what reaches the model.

The platforms' own write-ups describe the mechanism: agent credentials that reached production, and guardrails that lived somewhere the agent didn't go.

Three layers, each tested on PostgreSQL 18.6 with the output below: what the agent may change, which rows, and for how long. Then the gap all three share when the agent writes its own SQL.

A backup restore throws away everyone's work since the backup. What you want is the rows the agent changed, before and after, and a safe way to put them back. Postgres already records both.

A log tells you what some process chose to write down. Evidence has to say who wrote it, whether it changed since, and whether it matches what the system really did.