Count the credentials in your agent fleet that can reach production Postgres right now, this second, with nobody watching. For most teams the honest answer is all of them, all the time. Standing access is the default, and it is the largest source of blast radius you have: every long-lived agent credential is a key that works at 3am whether or not any task needs it.
Just-in-time access flips that default. An AI agent gets a path to Postgres only when a task requires it, scoped to that window, and the grant expires on its own. This post shows how to configure just-in-time access for agents on Postgres with hoop.dev governing the connection.
The cost of standing access
A standing Postgres grant is convenient and quietly expensive. It widens the window an attacker can use a leaked agent token. It makes least privilege a one-time setup decision rather than a live property. And it gives your audit trail nothing to say about intent, because access was always on.
Just-in-time access means the grant is tied to a request and a clock. When the window closes, the path is gone and a new task must ask again.
What just-in-time access means for an agent on Postgres
The agent does not hold a credential that opens Postgres on demand. It requests access through hoop.dev, the open-source Layer 7 access gateway that proxies the Postgres connection through a network-resident agent. hoop.dev authenticates the request against your identity provider, applies policy, and can route a risky request for human approval before the connection opens. Access is granted for the session, not forever.
One model leaves the door open and logs who walked through. The other opens the door only when asked and closes it behind. Just-in-time access is the second.
Setup
- Install the hoop.dev gateway and place its agent next to Postgres. The agent dials out to the gateway, so Postgres needs no inbound exposure.
- Add the Postgres connection: host, port, database, user, password, SSL mode. hoop.dev uses this credential to reach the database; the agent never receives it.
- Attach a just-in-time policy to the connection. Define which identities can request access, for how long, and which operations require an approver.
- Point the AI agent at the hoop.dev endpoint. When it needs Postgres, the request flows through the policy chain before any connection is dispatched.
- Verify by requesting access, confirming the session opens, then confirming it is denied again after the window expires.
The getting started docs cover installing the gateway and registering the first connection, and hoop.dev/learn walks through the policy model behind approvals and grants.
What the agent experiences
From the agent's side, just-in-time access does not change the protocol. It still opens a Postgres connection to the hoop.dev endpoint and speaks SQL. What changes is the moment of the grant. If the policy auto-approves a read for the requesting identity, the session opens immediately. If the operation needs review, the request waits for an approver, and the connection opens only after the decision. When the window ends, the session closes and a fresh request governs the next task.
This keeps the access decision close to the work. Instead of a credential that quietly carries permanent reach, each task surfaces an explicit, recorded request that policy evaluates in the moment.
Pitfalls
- Do not set the window so long it becomes standing access by another name. A multi-day grant is not just in time.
- Do not skip approvals on writes. Read access can often auto-grant; destructive statements should route to a human.
- Remember the connection credential is still least-privilege at the database. Just-in-time access controls when, not how much; pair it with a scoped Postgres role.
- Do not bury the request behind a manual step the agent cannot trigger. The request flow should be part of how the agent reaches Postgres, not a side channel.
FAQ
Who approves a just-in-time request?
You define approvers in policy. hoop.dev can route a request to a person or group before the Postgres connection opens.
What happens when the window expires?
The grant ends and the next attempt is denied until a new request is approved. Nothing stays open by default.
Does this slow agents down?
Read paths can auto-grant inside policy. Only the operations you flag require a human, so routine work is not blocked.
hoop.dev is open source and self-hostable. Clone the hoop.dev GitHub repository to wire just-in-time access onto your own Postgres connection and watch a grant expire.
