Imagine every autonomous agent that needs to run queries against PostgreSQL does so with just-in-time access, no lingering credentials, and full visibility into what was executed. In that ideal world the moment an agent finishes its task, its permission disappears, and the organization retains a complete record of every statement.
In practice many teams still hand out static database usernames and passwords, embed them in CI pipelines, or store them in secret managers that are shared across dozens of services. Engineers point their scripts directly at the database host, bypassing any central control point. The result is a sprawling matrix of credentials, no per‑query audit trail, and no way to prevent a rogue or buggy agent from issuing destructive statements.
Even when an organization adopts a policy that agents should receive just-in-time access, the request still travels straight to PostgreSQL. The gateway that grants the temporary role never sees the actual traffic, so the system cannot log each query, mask personally identifiable information in result sets, or pause a risky command for human approval. The policy fixes the credential lifecycle but leaves the core enforcement gap wide open.
Why just-in-time access matters for Postgres
Just-in-time access reduces the attack surface by ensuring that credentials exist only for the duration of a task. However, without a data‑path enforcement layer, the organization loses three critical controls:
- Command‑level audit: No record of which statements were run, by whom, and when.
- Inline data masking: Sensitive columns such as SSNs or credit‑card numbers can be returned to an agent that should not see them.
- Guardrails and approvals: Dangerous statements like DROP DATABASE or mass deletes run unchecked.
These controls must sit where the traffic actually flows – between the identity that initiates the connection and the PostgreSQL server that executes the query.
Architectural pattern: an identity‑aware proxy in the data path
The solution is to place an identity‑aware proxy in front of the database. The proxy performs three distinct functions:
- Setup phase: It validates the caller’s OIDC or SAML token, determines the caller’s groups, and decides whether a just‑in‑time session can be created.
- Data‑path enforcement: Every wire‑protocol message passes through the proxy, where it can record the statement, apply masking rules, and enforce guardrails or approval workflows.
- Outcome delivery: The proxy forwards only the allowed traffic to PostgreSQL, keeping the database credentials hidden from the caller.
This pattern satisfies the missing enforcement outcomes while preserving the benefits of just‑in‑time credential issuance.
hoop.dev as the gateway for Postgres
hoop.dev implements exactly this pattern for PostgreSQL. It runs a Layer 7 gateway that sits between autonomous agents and the database. The gateway authenticates callers via OIDC/SAML, then creates a time‑boxed session that forwards traffic to the native PostgreSQL wire protocol.
Because hoop.dev is the data‑path component, it can:
- Record each query at command level, providing a complete audit trail.
- Mask sensitive fields in result rows before they reach the agent, protecting PII and PHI.
- Block or route dangerous statements to a human approver, preventing accidental data loss.
- Hold the database credentials itself, so agents never see the password or IAM token.
All of these outcomes exist only because hoop.dev sits in the data path; the surrounding identity system merely decides who may start a session.
Putting the pieces together
The deployment workflow follows a clear separation of concerns:
- Identity provisioning (Setup): Configure your organization’s OIDC provider (Okta, Azure AD, Google Workspace, etc.) so that hoop.dev can verify tokens and read group membership.
- Gateway deployment (Setup): Run the hoop.dev gateway near your PostgreSQL instance using the provided Docker Compose quick‑start or a Kubernetes manifest. The gateway holds the static DB user/password or an RDS IAM token.
- Policy definition (Setup): Define just‑in‑time policies that grant agents a scoped role for a limited time window. Policies can require approval for high‑risk statements.
- Runtime enforcement (Data path): When an agent initiates a connection, hoop.dev validates the token, checks the policy, creates the session, and then inspects every query. It records the statement, applies masking rules, and enforces guardrails before forwarding to PostgreSQL.
This architecture ensures that the only point where a query can be observed, altered, or blocked is inside hoop.dev. The database itself remains unchanged, and existing client tools (psql, JDBC, ORM libraries) continue to work without modification.
Benefits of the approach
- Reduced blast radius: Credentials exist only for the duration of a task, and any malicious command is stopped before it reaches the database.
- Full auditability: Every statement, who ran it, and when is stored outside the database, satisfying internal and external compliance needs.
- Data protection: Inline masking prevents accidental exposure of sensitive columns to automated agents.
- Operational simplicity: Teams keep using their familiar PostgreSQL clients; the gateway handles all security concerns.
For a step‑by‑step walkthrough, start with the getting started guide. The learn page dives deeper into masking, guardrails, and session replay features.
FAQ
Q: Do I need to change my application code to use hoop.dev?
A: No. Applications continue to point at a PostgreSQL endpoint, but the host address is the hoop.dev gateway instead of the raw database. The wire protocol remains unchanged.
Q: How does hoop.dev handle credential rotation?
A: The gateway stores the database credential centrally. When you rotate the password or IAM token, you update the gateway configuration; agents never need to know the new secret.
Q: Can I still run bulk data migrations?
A: Yes. Define a policy that grants a longer‑lived session or requires an explicit approval step. hoop.dev will still record every statement and enforce any masking rules you configure.
Ready to try it yourself? Explore the source and contribute on GitHub.
