An agent updated 40,000 rows it should not have touched, and the only question that matters now is what exactly it ran and in what order. If your answer comes from the agent's own logs, you have a problem: the process you are investigating is the same one that wrote the record. Session recording solves this only when the recording lives somewhere the agent cannot reach.
This post configures session recording for AI agents on Postgres, with hoop.dev capturing every statement on the wire, outside the agent process, so the record survives the incident it describes.
The architectural requirement
A trustworthy session record cannot live inside the thing it audits. If the agent can write, edit, or suppress its own activity log, that log is testimony from the suspect. The record has to be captured at a boundary the agent does not control.
That boundary is the connection itself. Every Postgres statement an agent runs crosses the wire. Capture it there, and you have a complete record independent of what the agent chooses to report.
How hoop.dev does session recording on the Postgres connection
hoop.dev is an open-source Layer 7 access gateway. Its agent runs next to Postgres and speaks the native wire protocol, so it sees the actual statements, not an application's summary of them. Session recording captures each command, the resolved identity that issued it, and the results returned, tied to a single session. Because the capture happens at the gateway, the AI agent has no path to alter it.
This is command-level recording, not a coarse "agent connected at 14:02" line. You can replay the sequence of statements the way they hit the database.
Why command-level beats connection-level
Many systems can tell you an agent opened a connection and for how long. That is connection-level visibility, and during an incident it is almost useless. The question is never "did the agent connect"; it is "what did it run, and in what order." Command-level session recording answers that directly. You see the actual UPDATE, the WHERE clause that scoped it, and the statements around it, attributed to one identity in one session.
That depth is only possible because the capture happens where the wire protocol is parsed. A network tap sees encrypted bytes; an application log sees its own summary. The proxy that speaks Postgres sees the statements themselves.
Steps
- Deploy the hoop.dev gateway and run its agent beside Postgres. The agent connects outbound to the gateway.
- Register the Postgres connection with host, port, database, user, password, and SSL mode.
- Confirm recording is active for the connection. For Postgres, session recording is a native capability of the proxy.
- Route the AI agent through the hoop.dev endpoint so its statements pass the recording layer.
- Run a test query, then open the recorded session and confirm the statement and its identity attribution appear.
See the getting started guide for gateway and connection setup, and hoop.dev/learn for how recording fits the wider access model.
Pitfalls
- Do not rely on application logs as your session record. They live inside the blast radius and can be incomplete or rewritten.
- Do not assume recording implies redaction. Recording captures what happened; masking decides what sensitive data appears in results. Configure both if your sessions touch regulated columns.
- Do not give the agent a direct Postgres route alongside the proxied one. A bypass path produces unrecorded sessions and defeats the point.
FAQ
What granularity does session recording capture?
Command level. For Postgres, hoop.dev records the statements crossing the wire, attributed to the identity that ran them.
Can the AI agent delete its own recording?
No. The record is captured at the gateway, outside the agent process, so the agent has no path to alter it.
Does recording change how the agent connects?
No. The agent speaks Postgres to the hoop.dev endpoint as it would to the database. Recording is transparent to the client.
What can I do with a recorded session afterward?
You can replay the statements in order, filter by the identity that ran them, and use the record as the source of truth during an incident review or an access audit. Because it captures the commands as they hit the wire, it answers the precise question of what an agent executed rather than what it claimed to.
hoop.dev is open source, and where it fits your environment, a small team can self-host it without a license cost. Read how the recording pipeline works and run it yourself from the hoop.dev repository on GitHub.
