A reviewer asks a simple thing: show me everything the billing agent did in Postgres last Tuesday, in order. If you can produce a replayable, per-statement record attributed to that agent, the conversation is short. If you can only produce an application log that summarizes some of it, the conversation becomes an investigation. Session recording for AI agents on Postgres is the difference between answering and guessing.
This post explains what a usable recording contains and how hoop.dev captures it on the Postgres connection.
What a usable record contains
A session recording worth having is per identity, per statement, and replayable. It says which agent connected, every SQL command it issued, in sequence, and what came back. A line that says "agent connected" is not a record; it is a timestamp. The unit that matters for Postgres is the statement.
The record must sit outside the agent
If the agent writes its own activity log, that log shares the agent's failure modes and trust boundary. A compromised or buggy agent produces a compromised or incomplete record. The capture has to happen somewhere the agent does not control, and the connection is exactly that place: every statement crosses it.
How hoop.dev captures the session recording
hoop.dev is an open-source Layer 7 access gateway. Its agent runs next to Postgres and parses the native wire protocol, so session recording captures the real statements, not an application's interpretation of them. Each session is tied to the identity hoop.dev resolved at authentication, and the capture lives at the gateway, outside the AI agent's reach. The recording is therefore independent of whatever the agent itself chooses to report.
Setup follows the same pattern as any hoop.dev connection. You deploy the gateway, run the network-resident agent next to Postgres, register the connection with its host, port, database, and credentials, and route the agent through the hoop.dev endpoint. The getting started guide covers that install. Recording is native to the Postgres proxy, so once the connection is in place the statements are captured.
A replay in practice
The billing agent opens a session, runs a sequence of selects and one update, and disconnects. Later you open that recorded session and step through the statements in order, each tagged with the agent's identity. You can see exactly which update ran and on what. No correlation across scattered logs, because the record was complete at capture time.
Contrast that with reconstructing the same event from a database statement log plus an application log plus a guess about which agent run was active. You end up correlating timestamps across systems and hoping nothing was dropped. A single per-session record collapses that work into one timeline, which is what makes session recording worth having before the incident rather than after.
Recording and the rest of the controls
Session recording is the evidence layer, and it gets stronger when it sits next to the other controls on the same connection. A recorded session that also carries the identity hoop.dev authenticated, the approval that gated it, and the masking applied to its results is a far more complete account than a raw statement dump. You can see who asked, who approved, what ran, and what data was redacted on the way out, all in one timeline. That is why recording belongs on the access boundary rather than bolted on separately: the context it needs already lives there.
Pitfalls
- Application logs are not a substitute. They live inside the blast radius and can omit what you most need.
- Recording captures activity, not sensitivity. If sessions touch regulated columns, configure masking so recordings and results handle that data deliberately.
- Leaving an unproxied Postgres route open produces blind sessions. Route agent access through the gateway so nothing escapes the record.
FAQ
Is session recording per statement or per connection?
Per statement. hoop.dev records the commands crossing the Postgres wire, attributed to the resolved identity.
Can a recording be tampered with by the agent?
No. It is captured at the gateway, outside the agent process.
Does recording require changing the agent's code?
No. The agent connects to the hoop.dev endpoint as a normal Postgres client; recording is transparent.
hoop.dev is open source. See how session recording is implemented and run it on your own Postgres connection from the hoop.dev repository on GitHub. The wider model is at hoop.dev/learn.
