Your audit log says the agent connected to the database at 03:14 and disconnected at 03:31. It does not say what happened in those seventeen minutes. When you are reconstructing how a regulated table ended up in a model's context window, the gap between those two facts is the entire investigation. This is the difference between session recording and audit logs alone, and it decides whether you can answer the question that matters after something goes wrong.
Both produce evidence. They produce different evidence, at different resolution, and choosing between them is really a choice about what you will need to know later.
What audit logs alone capture
An audit log is a stream of discrete events: an authentication, a connection opened, a permission granted, a session closed. Each entry is a fact with a timestamp. Logs are compact, easy to query, easy to alert on, and for many questions they are exactly enough. Who has been connecting to this system this week? Which identities were granted access to that dataset? Did anyone authenticate from an unexpected place? Logs answer all of these well.
What logs do not capture is the content of the work. A connection event tells you an agent opened a session. It does not tell you the queries it ran, the rows that came back, or the command that changed the schema. The log is the table of contents. It is not the chapter.
What session recording captures
Session recording captures the activity inside the session: the actual commands an agent issued, in order, tied to the identity that issued them and the connection they ran against. For an interactive or agent-driven session, that is the difference between knowing a session occurred and knowing what the session did.
The trade is volume and handling. A recording is heavier than a log line, and because it can contain sensitive output, the masking and retention around it have to be deliberate. You do not record everything at full fidelity forever without thinking about where it lives and who can read it.
Deciding between them
Audit logs alone are enough when you need to monitor access patterns, alert on anomalies, and prove that an access-control policy is in force. If the question you will ask later is "who could reach this, and when," logs answer it.
You need session recording when the question you will ask later is "what exactly did this identity do." That is the question after an incident, the question an auditor asks about privileged access to regulated data, and the only question that matters when an autonomous agent does something nobody expected. Logs tell you a door opened. Recording tells you what walked through it and what it touched.
For AI agents the decision tilts hard toward recording, because an agent's behavior is not predictable from its configuration. You cannot infer what it did from what it was allowed to do. You have to capture the actual commands, which means logs alone leave you blind exactly where agents are riskiest.
The requirement that makes either one trustworthy
Here is the constraint that outranks the choice. Whatever you capture, log or recording, it cannot live inside the process you are trying to hold accountable. If the agent, or anything the agent can influence, can write, edit, or suppress its own record, the record is not evidence. It is a story the subject gets to revise.
So the requirement is that the capture happens on the connection, at the boundary the agent passes through, not inside the agent or its runtime. The record must be produced by something the agent cannot reconfigure.
hoop.dev is built to that constraint. It is an open-source Layer 7 access gateway that proxies the connection between an identity and the infrastructure behind it. Because every command passes through the gateway at the protocol level, the gateway is where both kinds of evidence are produced. It writes the structured access events you would expect in an audit log, and it performs session recording of the commands that ran, both tied to the authenticated identity and the specific connection, both generated outside the agent's reach. The agent never holds the pen.
That single placement is why you do not have to pick one in practice. The gateway emits the event stream for monitoring and alerting and captures the full session for investigation, and it can mask sensitive output before it lands in the recording. The model and its retention and masking options are covered in the getting started guide.
FAQ
Do audit logs make session recording unnecessary?
Only if you will never need to know what happened inside a session. Logs prove access occurred. Session recording proves what the access did. For privileged or agent-driven work, you usually need both.
Is session recording too heavy to run on every connection?
It is heavier than logging, which is why masking and retention matter. Capturing at the gateway lets you record the sessions that matter, redact sensitive output, and set retention per connection instead of recording everything forever.
Why not let the agent log its own actions?
Because a record the subject can edit or omit is not evidence. Capturing on the connection, outside the agent, is what makes the recording trustworthy.
hoop.dev is open source. See how the session recording and audit event plugins sit in the connection path on GitHub, then run a session through the gateway and replay what it captured.
