When an AI coding agent runs unrestricted queries against a production database, a single stray statement can corrupt data, expose sensitive fields, or erase the evidence needed to understand what happened, and without session recording the fallout is invisible. The cost of that blind spot is not just technical debt, it can become a compliance breach or a costly outage.
Current practice leaves the database exposed
Many teams hand a static credential to an AI agent so it can talk directly to PostgreSQL. The agent authenticates with the same username and password that a human engineer uses, and every query flows straight to the database engine. There is no central point that can watch the traffic, no way to replay a session, and no guarantee that sensitive columns are hidden from the model’s output. In that state, the organization relies on the hope that the agent behaves, but there is no audit trail to prove it.
Adding identity without a control plane is only half the solution
Moving the authentication step to an OIDC provider, so the agent receives a token instead of a password, adds a layer of identity verification. The token tells the gateway who is making the request, and policies can limit which roles the agent may assume. However, the request still travels straight to PostgreSQL. The database sees the raw SQL, and nothing in the path records the command or masks returned values. The setup defines who can start a connection, but it does not enforce what that connection may do.
hoop.dev places the enforcement where it matters
hoop.dev acts as a Layer 7 gateway that sits between the AI agent and the PostgreSQL server. The gateway is the only place the traffic can be inspected, altered, or logged. When the agent presents its OIDC token, hoop.dev validates the token, extracts group membership, and then establishes a proxied session to the database using a credential that the agent never sees.
Because the proxy is in the data path, hoop.dev can apply session recording to every statement that passes through. Each query is captured at the command level, timestamped, and retained for audit purposes. The recorded session can be replayed later, allowing engineers to see exactly what the AI asked the database to do, which rows were returned, and how long each operation took. This evidence is indispensable for forensic investigations, compliance audits, and debugging AI‑generated code.
In addition to recording, hoop.dev can mask columns that contain personally identifiable information, block dangerous statements such as dropping an entire database, and require a human approver before executing high‑risk queries. All of these guardrails are possible only because the gateway sits in the path; the database itself remains unchanged and oblivious to the policy enforcement.
How the architecture fits together
- Setup: An OIDC provider (Okta, Azure AD, etc.) issues tokens to the AI agent. The organization defines which groups may request access to the Postgres resource.
- Data path: hoop.dev runs as a Docker Compose service or in Kubernetes, with a network‑resident agent deployed near the PostgreSQL instance. The agent holds the database credential; the AI never sees it.
- Enforcement outcomes: When the AI sends a query, hoop.dev records the statement, applies any configured masking rules, checks the command against guardrails, and either forwards it to PostgreSQL or blocks it. The full session is stored for later replay.
Because hoop.dev is the sole point where the request is inspected, removing it would instantly eliminate session recording, masking, and approval workflows. The identity configuration alone cannot provide those guarantees.
Getting started
To put this architecture into production, start with the getting‑started guide. It walks you through deploying the gateway, registering a PostgreSQL connection, and configuring OIDC authentication for your AI agents. Additional feature details are available in the learn section. The open‑source repository at github.com/hoophq/hoop contains the full source, example compose files, and Helm charts for Kubernetes deployments.
FAQ
Does hoop.dev store the actual data returned by queries?
hoop.dev records the SQL statements and metadata such as timestamps and user identity. Returned rows are streamed to the client after any masking rules are applied, but the raw data is not persisted unless you configure a separate audit sink.
Can I enable session recording for only a subset of agents?
Yes. Policies are attached to groups or roles defined in your identity provider. You can grant recording, masking, or approval requirements to specific AI agents while leaving other agents with lighter controls.
Will the proxy add noticeable latency?
The gateway operates at the wire‑protocol level and adds only minimal processing overhead for logging and guardrails. In most environments the impact on query latency is measured in milliseconds, which is acceptable for most production workloads.
By placing the enforcement point in the data path, hoop.dev gives you reliable session recording for AI‑driven PostgreSQL access, turning a blind spot into a searchable audit trail.
