An engineering team hands a newly trained LLM‑driven automation script to a contractor, and the lack of session recording makes the risk invisible. The script connects to the production PostgreSQL instance using a shared service‑account token stored in a CI secret. The contractor’s token never expires, and the only visibility the team has is the database’s audit log.
When the script mis‑interprets a prompt, it issues a DELETE that wipes a month’s worth of orders. The audit log shows the DELETE statement and the service account that issued it, but it provides no view of the surrounding conversation, the exact prompt that triggered the command, or the sequence of queries that led to the data loss. The team scrambles to reconstruct what happened, only to discover that the log lacks the context needed to attribute intent.
This gap is not unique to one project. Organizations that let AI agents talk directly to databases often rely on native audit logs as the sole source of truth. Audit logs capture what was executed and who executed it, but they do not capture how the request was formed, why a particular query was generated, or the intermediate state of the session. For human operators, the missing context can be reconstructed from memory or external tickets; for autonomous agents, that context evaporates the moment the request leaves the model.
Why audit logs fall short for AI‑driven access
Audit logs are a valuable forensic artifact, yet they are a downstream record. They are written after the database has already processed the command, which means any destructive action has already taken effect. When an AI agent generates a series of queries based on a chain‑of‑thought prompt, the audit log only shows the final statements, not the reasoning steps that led there. This makes it impossible to distinguish a malicious intent from a harmless mistake, and it prevents automated remediation that depends on understanding the full interaction.
Furthermore, audit logs are typically stored inside the same environment they protect. If an attacker compromises the database host, they can also tamper with or delete the logs, erasing evidence of the breach. Without a separate, immutable record of the session, compliance teams struggle to prove that controls were in place, and security teams lose a critical tool for post‑incident analysis.
Adding identity checks is not enough
Many teams respond by tightening identity management: they move from static credentials to short‑lived tokens, enforce OIDC authentication, and assign least‑privilege roles to each AI service account. This setup step certainly narrows who can start a connection, but it does not address the core problem that the request reaches PostgreSQL unobserved.
Even with perfect identity verification, the request still travels directly to the database. The gateway that could enforce additional guardrails, such as blocking dangerous commands, requiring human approval for schema changes, or masking sensitive result fields, does not exist in the data path. Consequently, the system still lacks a way to capture the full conversation, to replay it for audit, or to intervene in real time.
Putting a gateway in the data path
The missing piece is an identity‑aware proxy that sits between the AI agent and PostgreSQL. By placing enforcement in the data path, the proxy can observe every packet, apply policy checks, and record the entire exchange before it ever touches the target database. This architectural choice ensures that no matter how sophisticated the identity setup is, the enforcement outcomes are guaranteed to happen because they are tied to the network hop that carries the traffic.
When the proxy sits in the data path, it can:
- Capture every query and every response, creating a replayable session.
- Apply inline masking to hide credit‑card numbers or personal identifiers before they reach downstream logs.
- Require just‑in‑time approval for high‑risk statements such as DROP TABLE or DELETE FROM without a WHERE clause.
- Block commands that match a denylist, preventing accidental or malicious data loss.
All of these outcomes exist only because the gateway is the sole place where the traffic can be inspected and altered.
How hoop.dev delivers session recording and control
hoop.dev implements exactly this data‑path gateway for PostgreSQL and dozens of other targets. It authenticates users and AI agents via OIDC or SAML, reads group membership, and then proxies the connection through a network‑resident agent. Because the proxy sits between the requester and the database, hoop.dev records each request and response, producing a complete session recording that can be replayed for forensic analysis.
When a query arrives, hoop.dev evaluates the policy attached to the caller’s identity. If the statement matches a rule that requires approval, the request is paused and a notification is sent to the designated approver. Only after explicit consent does hoop.dev forward the query to PostgreSQL. If the statement contains a pattern that is deemed unsafe, such as a bulk delete without a filter, hoop.dev blocks it outright and logs the event.
In addition to blocking and approval, hoop.dev can mask sensitive columns in result sets. For example, a SELECT that returns Social Security Numbers can be rewritten on the fly so that the downstream audit log never sees the raw values. This masking happens before any data leaves the gateway, ensuring that downstream storage complies with privacy policies.
All of these capabilities are available without exposing credentials to the caller. The gateway holds the database password or IAM role, and the caller never sees it, which eliminates credential sprawl and reduces the attack surface.
What you get when you adopt hoop.dev
By inserting hoop.dev into the PostgreSQL data path, teams gain a trustworthy evidence trail that goes beyond traditional audit logs. The session recording provides:
- Full visibility into the prompt‑to‑query transformation performed by AI agents.
- Replay capability for post‑mortem investigations, enabling you to step through each interaction.
- Compliance‑ready artifacts that show who approved which high‑risk statement and when.
- Real‑time protection against accidental data loss through command blocking and just‑in‑time approvals.
- Privacy safeguards via inline masking, ensuring that sensitive fields never appear in downstream logs.
Getting started is straightforward. Follow the getting‑started guide to deploy the gateway, register your PostgreSQL instance, and configure OIDC authentication. The learn section contains deeper explanations of runtime governance, policy authoring, and session replay.
Visit the open‑source repository on GitHub to explore the code, contribute improvements, or raise issues: hoop.dev on GitHub.
FAQ
Does session recording replace native PostgreSQL audit logs?
No. hoop.dev complements native logs by providing a complete, replayable view of the entire interaction, while the database’s own logs still capture low‑level events. Together they give a richer picture than either alone.
Can I use hoop.dev with existing OIDC providers?
Yes. hoop.dev works as an OIDC relying party, so you can integrate it with any compliant IdP such as Okta, Azure AD, or Google Workspace. The identity check happens before the request reaches the data path.
Is the session data stored securely?
hoop.dev stores recordings in a location you control, separate from the database host. Because the gateway is the only component that can write to that storage, you can apply your own encryption and retention policies to meet organizational requirements.
