Run \du on the role your agents use and you often find Superuser or a grant list that covers the whole schema. It started as "give it what it needs to not break," and it never got trimmed. That over-scoped role is the agent's blast radius: anything it can reach, a bug or a hijacked task can reach too. Least-privilege access for AI agents on Postgres is the discipline of closing that gap.
This post covers what least privilege means for agents specifically and how hoop.dev enforces it in front of Postgres.
What least privilege means for an agent
Least privilege for an agent on Postgres means it can touch exactly the tables and run exactly the operations its task requires, and nothing else. A reporting agent reads a few tables. A data-quality agent reads broadly but writes to one. The principle is the same one you apply to people; agents just tend to get exempted from it.
Two layers, not one
Least privilege for agents lives in two places, and you need both.
- The Postgres role on the connection, granted only the privileges the broadest legitimate use needs.
- The access policy at the gateway, scoping which identity can use the connection, for which operations, and when.
The database role is static and coarse. The gateway policy is per identity and dynamic. Relying on the role alone forces every agent down to one privilege set; the gateway lets you scope each agent independently above that floor.
How hoop.dev enforces least-privilege access on Postgres
hoop.dev is an open-source Layer 7 access gateway. Its agent proxies the Postgres connection at the wire level. hoop.dev authenticates the AI agent's identity, applies the policy scoped to that identity, and can route privileged operations for approval before they reach the database. The connection credential gives Postgres its floor; hoop.dev narrows each identity from there and records what each one did.
Why the gateway layer matters for scope
Postgres grants are coarse and shared. A single connection role applies identically to everyone who uses it, which forces you to grant the union of what every agent needs and then hope nothing abuses the surplus. The gateway breaks that tradeoff. Because authorization is decided per identity at the access layer, two agents on the same connection can have different reach: one limited to reads on a reporting schema, another allowed a single write that routes for approval. You no longer have to choose between a permissive shared role and a sprawl of database roles to maintain. The recorded sessions then show whether the scopes you set match what each identity actually does, so you can tighten them over time. The hoop.dev/learn material covers how policy attaches to identity.
Steps
- Create a Postgres role for the connection with the minimum grants the legitimate workload needs. Avoid superuser.
- Register the connection in hoop.dev with that role's credentials.
- Define per-identity policy: which agents can use the connection and which operations need approval.
- Route each agent through the hoop.dev endpoint and confirm an out-of-scope operation is denied.
Pitfalls
- A superuser connection role undermines everything above it. Start the floor low.
- Do not collapse all agents into one policy. Per-identity scoping is the point.
- Revisit grants as tasks change. Least privilege is a live property, not a one-time setup.
FAQ
Is the Postgres role enough on its own?
No. A single role applies to everyone who uses it. Gateway policy scopes each identity above that floor.
Can hoop.dev block a specific operation?
It can route operations for approval and deny those outside an identity's policy before they reach Postgres.
How is least privilege verified after setup?
Recorded sessions show what each identity actually ran, so you can confirm scopes match real use and tighten them.
Does adding the gateway mean I can loosen my Postgres grants?
No. Keep the connection role as tight as the workload allows; the gateway narrows from that floor, it does not raise it. The two layers reinforce each other, so a low database floor plus per-identity policy gives the smallest practical reach for every agent.
What about an agent that needs broad reads but narrow writes?
Scope it that way at the gateway: auto-grant the reads, route the writes for approval. The same connection can serve both within one identity's policy.
hoop.dev is open source. See how per-identity scoping sits in front of a Postgres connection in the hoop.dev GitHub repository, or follow the getting started guide.
