A token from an agent's config leaks into a public repo. With standing access, that token still opens production Postgres until someone notices and rotates it, which could be days. With just-in-time access for AI agents on Postgres, the same token grants nothing on its own, because access is something a task requests and the system grants for a window, not a property the credential carries forever.
The difference is the entire blast radius of a compromise. This post covers the just-in-time model for agents on Postgres and how hoop.dev enforces it on the connection.
Standing access is the liability
Long-lived agent credentials are convenient and dangerous. They work at any hour, for any task, whether or not work is happening. They turn one leaked secret into open-ended database access. And they tell your audit trail nothing about why a connection opened, because access was simply always there.
The just-in-time lifecycle
Just-in-time access means the agent has no standing path to Postgres. When a task needs the database, it requests access through hoop.dev, the open-source Layer 7 access gateway proxying the connection. The lifecycle is: request, authenticate against the identity provider, evaluate policy, optionally route to a human approver, open a scoped session, then expire. After expiry, the next task starts the cycle again.
Access exists only inside that window. There is nothing for a leaked credential to ride on between windows.
Where just-in-time access fits on the Postgres connection
hoop.dev's agent runs next to Postgres and speaks the native wire protocol. The AI agent connects to hoop.dev rather than the database directly. hoop.dev evaluates the just-in-time policy before dispatching the connection and uses the connection-configured credential to reach Postgres, so the agent never holds a database password that could grant standing access in the first place.
This is the structural reason just-in-time access works here rather than being advisory. Because the credential that opens Postgres lives on the gateway connection, not in the agent, there is no key for the agent to fall back on when policy says no. The grant is the only path, and the grant is temporary.
Auditability is the side benefit
Standing access leaves your audit trail mute about intent. Just-in-time access fixes that as a byproduct. Every request is a recorded event with an identity, a reason if you require one, an approval if policy demanded it, and a window. Months later you can answer not just what an agent did in Postgres but why it had access at all when it did it. That request history is often more useful in review than the query log itself, because it shows the decision, not only the action. For how requests and approvals are modeled, see hoop.dev/learn.
A concrete grant
An agent needs to reconcile yesterday's orders. It requests Postgres access for that job. Policy auto-grants read access for a 30-minute window; a write to the orders table would route to an on-call engineer. The agent runs its reconciliation, the window closes, and the path is gone. The recorded session shows the request, the grant, and every statement, attributed to that agent's identity.
Pitfalls
- An over-long window is standing access wearing a different label. Keep windows tight.
- Auto-granting writes defeats the point. Reserve human approval for operations that change or destroy data.
- Just-in-time controls timing, not scope. Keep the underlying Postgres role least-privilege as well.
FAQ
How short should the access window be?
As short as the task allows. A window measured in minutes for a discrete job is far safer than an open-ended grant.
Does the agent need a Postgres password?
No. The credential lives on the hoop.dev connection. The agent authenticates as its identity and access is granted just in time.
What if a task needs access again later?
It requests again. Each window is a fresh decision, which is what makes the model auditable.
How is this different from just rotating the agent's password often?
Rotation shortens how long a leaked credential is useful, but the credential still grants standing access for its lifetime, and the agent still holds it. Just-in-time access removes the standing credential entirely. There is no key the agent carries between tasks, so there is nothing to rotate and nothing to leak that opens the database on its own.
hoop.dev is open source and self-hostable. Set up a just-in-time policy on your own Postgres connection from the hoop.dev GitHub repository, or start with the getting started guide.
