How it works
Behind that port, every query is read before it runs. Masked on the way back, refused if it is destructive.
Where it sits
A proxy runs next to your database, not in place of it. Every statement your agent sends goes through it first. Every response comes back through it. It reads both in flight, before either side sees the other.
We call that process the sidecar, because it attaches to one resource and travels with it.
What happens in between is one config file.
127.0.0.1:15432the proxy127.0.0.1:5432your real resourceThe migration
Changes
543215432Stays the same
The agent never knows it exists. No SDK, no prompt changes, no agent-side config.
What runs on every operation
Two layers check every operation. The first is deterministic: rules you wrote, checked in order, the same answer every time. The second is an agent. It reads the statement and scores it for intent and risk.
The operation runs. Nothing is added to the path and nothing waits on a person.
It never reaches the resource. The client reads the reason you wrote, as a real protocol error rather than a dropped connection.
The operation holds for one-off approval, with the exact statement attached.
A static rule cannot judge intent. A human cannot review at machine speed. So the second layer moves at the same speed as the agent it watches, with one job.
Protocols
Those are the protocols today. No code changes, no new credentials, no rerouting.
We build on wire protocols on purpose. Models change every few months. Frameworks change faster. Postgres is not going anywhere. A control that sits in the connection outlives every layer above it.
Anything that reads every query to your data should be code you can read too. Free and open source under MIT. One command to install. One file to configure.