This reflects Supabase's MCP server as of July 2026. Supabase lets AI agents write security policies straight to your database. Their safety checkpoint sorts every change by how dangerous it is, then asks the human to confirm. It never asks whether the change is right. Here's where that gap opens, and how I'd close it using a pattern they already trust.
The surface: where agents write to the database
Supabase says it plainly in their own hiring post. AI coding agents now write migrations and security policies on their platform through the MCP server. And when an agent has the wrong context (their words), the result is a broken schema or a misconfigured policy.
So they have named the failure themselves. What I want to look at is the checkpoint that's supposed to catch it, and whether it actually does.
What they built, and what it checks
Supabase already has a good instinct here. Their MCP server sorts every operation into 3 layers:
-
Read-only is always allowed.
-
Write needs the user to turn on write mode.
-
Destructive, needs write mode plus a two-step confirmation before it runs.
That's a real safety system. But look at what it's measuring. Every layer is sorting by danger:
-
Will this delete something?
-
Will this break the structure?
-
The two-step confirmation asks the human one question: are you sure you want to run something this dangerous?
It never asks whether the thing is correct.
Where it collapses
Here's the gap. A misconfigured security policy is not destructive. It's a write operation that looks completely normal, reads like it's working, and passes straight through. The human is never stopped, because nothing about it trips the danger layer.
But a misconfigured policy is the kind that exposes data. It decides who can read what, and when it's wrong, every user can see every other user's records. That is the exact failure Supabase admits happens. And it slips through precisely because their checkpoint is built to catch deletions, not exposures.
The human confirmed the operation was safe to run. But nobody confirmed it was correct.
The fix, using their own pattern
They don't need a new concept. They already trust layered confirmation. The move is to add a layer for verification, the same way they already have layers for danger.
The method I would use is grounding, because I have built it. In my own multi-agent system, the specialists cannot deviate from the real workflow code. They are locked to the source of truth, so their answers are correct by construction, not by hope. When one doesn't know, it says so instead of guessing, and a daily digest surfaces every gap it could not close so a human can step in when needed or flagged.
Applied here, an agent-written policy would be checked against a grounded source of truth, the real schema and the intended access rules, before it goes live. Not a human just going with it and clicking approve. A check that shows whether the policy actually does what the developer thinks it does.
To be fair, they do have a check. It's called advisors, and it can catch a bad policy. But it sits on the side and is a separate thing the developer has to remember to run, and you can't count on people to remember. It's not built into the confirmation step, the spot where the human is already stopped and paying attention. So the danger check is baked into the confirmation step, and the correctness-check is only optional. That's the gap. Not that they can't verify, but that verifying isn't where the human already is.
Where this gets hard, honestly
The grounding idea has a real cost, and I want to name it rather than pretend it doesn’t matter.
Grounding needs a source of truth to check against, and building it, is the heavy lift. The agent needs explicit instructions that forbid guessing or bluffing. It needs a way to say I don't know instead of inventing an answer. And it needs an escalation path when it can't resolve something, the way my system emails me a digest of what it couldn't answer so a human can take it from there.
This is not just a toggle or a switch, it's real design work, and I know that because I did it. It's the difference between saying add a correctness check and knowing what one actually takes to build. And getting it right is a safety standard, not a nice-to-have.
One gap, three surfaces
The same pattern shows up on their other two surfaces: interfaces and infrastructure. On interfaces, agents drive the CLI and SDK, and the same danger-not-correctness gap applies. On infrastructure, agents set things up on their own, and no one sees the cost or what could go wrong before it happens.
So all in all, one gap shown on three different surfaces.