Just-in-time access vs standing access: which actually controls AI agent risk (on Postgres)

Why standing access is a blind spot

Just-in-time access replaces permanent secrets with short‑lived tokens, preventing the blind spot that standing access creates. Giving an AI agent unrestricted credentials to a production Postgres instance is a recipe for data loss. Most teams hand the model a static user name and password, store that secret in a CI pipeline, and let the agent run queries whenever it wants. The credential never expires, can be copied, and is often shared across multiple workloads. If the model is compromised, the attacker inherits the same perpetual foothold. Auditors cannot tell which statements the agent issued because the database logs only show a single user name. The result is a black box where risky reads or writes go unnoticed until a breach is discovered.

In practice, engineers treat the standing secret as a convenience flag. The model can spin up new containers, execute migrations, or back‑fill tables without asking a human. The cost of a missed approval is hidden behind the illusion that the agent is “just reading data”. This approach also prevents any granular revocation – removing the secret means every downstream job stops, creating a brittle pipeline.

The missing guardrail: just-in-time access

Just-in-time access flips the model. Instead of a permanent credential, the system issues a short‑lived token the moment the AI agent needs to talk to Postgres. The request is evaluated against a policy that knows who the agent is, what operation it intends, and whether a human must sign off. If the policy allows, the token is minted for a few minutes and the connection proceeds. If not, the request is blocked or routed to an approval queue.

Crucially, just-in-time access does not eliminate the need for identity. The setup still requires an OIDC or SAML provider, service accounts, and role definitions that decide which agents may request a token. Those pieces answer the question “who may ask”. What they do not provide is the enforcement point where the request is examined, approved, or denied. Without a data‑path gate, the request still travels directly to the database, bypassing any audit or masking. The policy remains unenforced, and the risk persists.

hoop.dev as the data‑path enforcement point

hoop.dev sits on the network between the AI agent and the Postgres server. It is the only place where the request can be inspected, approved, and recorded. The gateway receives the short‑lived token, validates it against the identity provider, and then applies just-in-time policies before forwarding the traffic.

Because hoop.dev is the data‑path, it can:

• Record each session so auditors see exactly which statements the agent executed.
• Mask sensitive columns in query results, preventing the model from seeing raw personal data.
• Require a human approver for destructive commands such as DROP or UPDATE on critical tables.
• Block any command that does not match the approved policy, ensuring the agent cannot drift into unauthorized actions.

All of these outcomes exist only because hoop.dev sits in the data path. If the gateway were removed, the standing credential would flow straight to Postgres and none of the above safeguards would apply.

Setting up hoop.dev starts with the usual identity configuration – OIDC client, service accounts, and least‑privilege roles that define which agents can request a token. Those pieces constitute the Setup layer; they decide who may start a request but they do not enforce any rule on their own. The gateway then becomes the enforcement layer, the single point where policy is applied. Finally, the enforcement outcomes – session logs, inline masking, just‑in‑time approval, and command blocking – are produced by hoop.dev.

For teams that already have a CI pipeline feeding AI models, the transition is straightforward. Deploy the hoop.dev gateway using the getting‑started guide, register the Postgres target, and configure a just‑in‑time policy that matches your risk appetite. The learn section provides deeper examples of policy syntax and masking rules.

FAQ

Does just-in-time access eliminate the need for service accounts? No. Service accounts still identify the AI workload and grant it the ability to request a short‑lived token. The enforcement of what it can do happens in the gateway.

Can hoop.dev mask data without changing the application code? Yes. Because the gateway operates at the protocol layer, it can rewrite query results on the fly, keeping the application unchanged.

What happens if an approval is delayed? The request remains pending in the gateway until a human approves or rejects it. No traffic reaches Postgres during that time, so the database is never exposed to an unauthorized operation.

Take the next step

Explore the source code, contribute improvements, and see the full feature set on GitHub: hoop.dev repository.