Two databases, two agents, two very different mornings after an incident. In the first, the agent had a standing MySQL login and ran whatever it wanted; the only trace is a general query log on a box the agent could also reach. In the second, every statement the agent ran was captured outside the database, tied to a named identity, scoped to one task. Session recording for AI agents on MySQL is what separates those two mornings.
The contrast is the whole point. Standing access gives an agent an always-open door and a log that lives next to the door. Scoped, recorded access gives the agent a connection that opens per task, with session recording that lives outside the client and outside the database the agent can touch. One leaves you guessing. The other gives you the statement, the identity, and the time.
What session recording has to capture
For a MySQL agent, a useful record is at the SQL command level: the exact statements run, in order, attributed to the identity that ran them, with the session boundaries marked. A connection-level log that only says "agent connected at 03:14" is not enough. You need to replay what the agent did inside that connection.
The record also has to survive the thing it is recording. If the agent can reach the log, the log is evidence the agent can edit. The recording must sit somewhere the agent's session cannot rewrite.
Where the recording boundary sits
hoop.dev proxies the MySQL wire protocol through a network-resident agent. Because every query passes through the gateway, hoop.dev records each session at the statement level, tied to the identity that opened it, and stores it outside the client process. The agent connects, runs SQL, and the gateway captures the stream on the way through. The agent never holds the recording and cannot turn it off, because the recording is a property of the connection, not a setting in the agent.
This is also why scoped beats standing here. When access opens per task, each recording is a clean unit: one task, one session, one replayable transcript. When access is always on, the recording is one endless stream you have to slice by hand.
Set up session recording step by step
- Register the MySQL connection with
HOST, PORT, USER, PASS, and DB in hoop.dev. - Give the agent a distinct identity so its sessions are attributable rather than blended into a shared user.
- Recording runs natively on the MySQL proxy. Confirm it is enabled on the connection.
- Point the agent's client at the hoop.dev endpoint.
- Run a multi-statement task, then open the recorded session and confirm every statement appears in order with the agent's identity attached.
Pitfalls
- Relying on MySQL's own logs. The general query log is global, noisy, and reachable by anything with enough privilege, including the agent. It is not session-scoped evidence.
- Recording without identity. A transcript with no named identity tells you what happened but not who. Bind every session to the agent.
- Standing connections. Pair recording with just-in-time access so each recording maps to one task.
There is a practical payoff to recording at the statement level outside the client. When an agent does something surprising, you do not debate what it might have run. You open the session and read the statements in order, with the identity and timestamps already attached. That turns an incident review from a reconstruction into a replay, and it gives you the raw material an auditor or a teammate can check without taking your word for it.
FAQ
What level of detail does session recording capture?
The SQL statements run during the session, in order, with the identity and session boundaries. You can replay what the agent did, not just that it connected.
Can the agent tamper with the recording?
No. The recording lives in the gateway, outside the agent's session, so the agent cannot edit or delete it.
Does recording slow MySQL down?
Recording happens in the proxy path as statements pass through, so the database itself is doing its normal work; the capture is on the connection, not a trigger inside MySQL.
See how just-in-time access scopes each recorded session and the broader model for governing agent access. Stand the gateway up against a test MySQL database: hoop.dev on GitHub.
