The moment an AI agent gets production Postgres access, it joins the short list of things that can take your application down or leak your customer data. A dev-database agent that runs amok costs you an afternoon. A production agent that does the same costs you an incident. Production access control for AI agents on Postgres is what separates those two outcomes, and it is more than a firewall rule.
This post lays out what production access control requires for agents on Postgres and why hoop.dev treats it as one control surface rather than a pile of separate tools.
Production raises the stakes on every control
In production, the questions get sharper. Who is this agent, exactly? Should it be able to reach the database at this moment, or only when a task needs it? What did it run, and can I prove it later? Did sensitive data leave the connection in cleartext? In a dev environment you can be sloppy with these. In production each one is an incident waiting for a wrong answer.
What production access control means for an agent
It means four properties hold at once on the path to Postgres:
- The agent is a named identity, not a shared role.
- Access is granted just in time and scoped, not standing.
- Every statement is recorded outside the agent, attributed to the identity.
- Sensitive columns are redacted in results before the agent sees them.
The mistake is treating these as four projects you wire together yourself. They are properties of one boundary: the connection.
One control surface, not four integrations
hoop.dev is an open-source Layer 7 access gateway, and production access control is what it is, not a feature you bolt on. Its network-resident agent proxies the Postgres connection at the wire level. On that single connection it authenticates the agent's identity, enforces just-in-time and approval policy, records each session at the command level outside the agent, and redacts sensitive fields inline through a configured DLP provider. Identity, timing, audit, and masking are one integrated surface because they all sit on the connection every query crosses.
hoop.dev governs the connection in front of Postgres; it does not replace the database's own authentication. The controls are added on that boundary.
Why one boundary closes the gaps
When identity, timing, audit, and masking are separate tools, the danger lives in the seams between them. An agent might be a named identity in one system but reach the database through a path the recorder never sees. A grant might expire in one tool while a credential in another still opens the door. Putting all four properties on the single connection every query crosses removes those seams, because there is one path and it carries every control at once. The hoop.dev/learn material walks through how these properties compose on a connection.
Steps to put it in place
- Deploy the hoop.dev gateway and run its agent next to production Postgres. The agent dials out, so the database exposes no inbound port.
- Register the Postgres connection with a least-privilege role's credentials.
- Connect your identity provider so each agent authenticates as a named identity.
- Attach just-in-time and approval policy, confirm recording is active, and configure a DLP provider for masking on regulated columns.
- Route agents through the hoop.dev endpoint and verify an out-of-window or out-of-scope request is denied.
Pitfalls
- Do not leave a direct Postgres route open beside the proxied one. A bypass path voids every control above.
- Do not stop at identity. Production access control is the full set of properties holding together, not just authentication.
- Do not over-scope the connection role. The gateway narrows from the floor; a high floor undermines it.
FAQ
Does production access control replace Postgres roles?
No. It governs the connection in front of the database. Postgres still authenticates its credential; hoop.dev adds identity, timing, audit, and masking on top.
The controls all act on the same connection. Combining them on one boundary removes the gaps that appear between separately wired tools.
Can I start with just one control?
Yes. You can enable identity and recording first, then add just-in-time policy and masking. They live on the same connection.
hoop.dev is open source. See how the full production access control surface sits on a Postgres connection in the hoop.dev GitHub repository, or start with the getting started guide.
