An AI‑driven code‑assistant is granted a service account that can talk directly to a production Postgres instance. The agent receives a static password, opens a connection, and starts issuing SELECT and INSERT statements as part of an automated refactor. When the assistant misinterprets a schema change, it may write malformed data or delete rows, and no one sees what happened because the connection bypasses any logging layer.
Teams recognize that they need session recording for these agents. They want a replayable audit trail that shows every statement the AI sent, the exact response it received, and the context of the request. The ideal solution would also let them mask sensitive columns so that downstream reviewers never see raw PII. However, simply adding a credential manager or an OIDC token does not capture the traffic; the request still reaches the database directly, leaving the query history invisible.
In practice, the environment already has a strong identity foundation. Engineers and CI pipelines authenticate via OIDC providers, service accounts are scoped to the minimal set of roles, and the database itself enforces TLS. This setup decides who may start a connection, but it does not enforce any runtime guardrails or produce an immutable log of what the AI actually does.
Why session recording matters for AI coding agents
AI agents operate at speed and scale that far exceeds manual review. A single mis‑generated query can affect thousands of rows before a human notices. Without a reliable record, post‑mortem investigations become guesswork, compliance evidence is missing, and the organization cannot prove that the AI behaved within policy. Session recording provides three concrete benefits:
- Full command‑level visibility into every SQL statement the agent issues.
- Replay capability that lets auditors step through the exact sequence of actions.
- Integration with masking policies so that sensitive result sets are redacted before storage.
Architectural requirement: the gateway must sit in the data path
The enforcement point has to be the only place the traffic can pass. Identity checks happen upstream, but the actual inspection, masking, and logging must occur where the data flows. Placing a proxy between the AI service and Postgres satisfies this requirement because the proxy becomes the sole conduit for all queries and responses.
In this model, the gateway holds the database credential, so the AI does not obtain the password. The AI presents its OIDC token, the gateway validates the token, and then establishes a backend connection on its behalf. Because the gateway controls the wire‑protocol session, it can record every statement, apply inline masking, and enforce guardrails before the database sees anything suspicious.
Introducing hoop.dev as the data‑path enforcement layer
hoop.dev implements exactly this architecture. It acts as a Layer 7 proxy for Postgres, terminating TLS, authenticating the caller via OIDC, and then proxying the native wire protocol to the database. While the connection is active, hoop.dev records each query, stores the full request‑response pair, and can redact configured columns in real time. Because the proxy is the only path to the database, any attempt to bypass logging is impossible without breaking the network topology.
hoop.dev also supports just‑in‑time scopes, so the AI agent receives only the permissions required for the specific job. When a query matches a risky pattern, hoop.dev can block it or route it for human approval before execution. All of these outcomes, session recording, inline masking, command blocking, are enforced because hoop.dev sits in the data path.
How the solution fits into your existing setup
The existing identity foundation remains unchanged. Your OIDC provider continues to issue tokens, and your service accounts retain their least‑privilege roles. You simply point the AI client at the hoop.dev endpoint instead of the raw Postgres host. The gateway’s agent runs inside the same network segment as the database, ensuring low latency and no extra network hops.
From a deployment perspective, hoop.dev can be launched with a Docker Compose file for quick trials or installed on Kubernetes for production workloads. The official getting‑started guide walks you through the steps to register a Postgres target, configure OIDC, and enable session recording. The learn section provides deeper explanations of masking policies and approval workflows.
Enforcement outcomes you gain
- Session recording: hoop.dev records each SQL statement and its result, providing a complete audit trail.
- Inline data masking: configurable columns are redacted before the response is stored, protecting PII.
- Just‑in‑time access: the AI receives only the permissions needed for the current task.
- Command‑level guardrails: dangerous statements can be blocked or sent for manual approval.
FAQ
Does hoop.dev require changes to my existing Postgres client code?
No. The AI agent continues to use the standard PostgreSQL client library. You only change the connection endpoint to point at the hoop.dev proxy.
Can I disable session recording for low‑risk queries?
Recording is applied at the gateway level, so you can configure policies that exclude certain harmless statements, but the default is to capture everything for full visibility.
Is the recorded data stored securely?
hoop.dev writes session logs to a storage backend of your choice. The gateway never exposes raw credentials, and you can combine it with your organization’s existing encryption‑at‑rest strategy.
Get started
To see the full implementation details, clone the open‑source repository and follow the quick‑start steps. Explore the repo on GitHub and begin recording AI‑driven sessions against Postgres today.
