Autonomous agents that talk to a database without human oversight are a silent source of data leakage.
Today most teams let those agents log in with a shared service account or a static credential baked into CI pipelines. The credential lives in code repositories, environment files, or secret‑management systems that are often over‑privileged. When the agent connects, it reaches the PostgreSQL instance directly, bypassing any runtime guardrails. No one sees which statements were run, whether they touched sensitive columns, or if the query was approved.
Introducing non-human identity changes the authentication model. Instead of a hard‑coded user, the agent presents a token issued by an OIDC provider. The token carries the agent’s service‑account name and any group memberships that define its purpose. This shift enables least‑privilege scopes and makes revocation easier, but it does not automatically solve the visibility and data‑protection gaps.
Why non‑human identity alone is insufficient
Even with federated tokens, the request still travels straight to the PostgreSQL server. The gateway that sits between the agent and the database is missing, so there is no place to enforce command‑level policies, mask returned rows, or require a human approval for risky statements. The database logs only show the service‑account name; they lack context about who authorized the operation, what data was accessed, or whether the query complied with internal policies.
Placing an identity‑aware gateway on the data path
hoop.dev provides the missing layer. It acts as a Layer 7 proxy that intercepts every PostgreSQL wire‑protocol connection. The gateway validates the OIDC token, extracts the non‑human identity, and then creates a scoped session that only permits the actions defined for that agent. All database credentials are stored inside the gateway, so the agent does not have access to the password.
Because hoop.dev sits in the data path, it can enforce the full set of controls required for secure autonomous access:
- Command‑level audit: every SQL statement is recorded with the originating non‑human identity, timestamp, and outcome.
- Inline data masking: rows that contain PII or other sensitive fields are redacted before they reach the agent, ensuring the service account never sees data it does not need.
- Just‑in‑time scope: the gateway grants the minimum privileges for the duration of the session and revokes them on disconnect.
- Approval workflow: high‑risk statements trigger a human‑in‑the‑loop step before execution.
- Session recording and replay: the entire interaction can be replayed for forensic analysis.
How the flow works for an autonomous agent
The agent first obtains an OIDC token from its identity provider. It then initiates a PostgreSQL connection to the hoop.dev gateway instead of the database host. hoop.dev validates the token, checks the agent’s group memberships, and applies the policy bundle that defines allowed schemas, tables, and command types. The gateway forwards the request to PostgreSQL using its own credential, intercepts the response, masks any configured columns, logs the statement, and streams the result back to the agent. If the statement matches a guarded pattern, hoop.dev pauses the flow, notifies an approver, and only proceeds once approval is recorded.
Benefits for security and compliance
- Full visibility into every automated query, eliminating blind spots in your data‑access audit.
- Reduced blast radius: a compromised service account cannot read or modify data outside its narrowly scoped permissions.
- PII stays hidden from agents that do not require it, helping you meet privacy‑by‑design requirements.
- Evidence for compliance programs is generated automatically, without building custom logging pipelines.
To get started, follow the step‑by‑step guide in the getting‑started documentation. The learn section dives deeper into policy configuration, masking rules, and approval workflows.
FAQ
- Can I keep my existing service‑account configuration? Yes. hoop.dev can proxy the existing credentials while you transition to token‑based non‑human identities, giving you a phased migration path.
- Does hoop.dev store my PostgreSQL passwords? The gateway holds the credentials in memory only for the duration of a session. They never appear in the agent’s environment or logs.
- Will inline masking impact query performance? Masking is applied at the protocol layer after the database returns the result set. In most workloads the overhead is negligible, and you can tune the mask list to focus on the most sensitive columns.
Explore the open‑source repository on GitHub to see the implementation details and contribute.
