Ask the question an auditor asks: which agent ran this DELETE, when, and under what task? If your answer is "let me grep the MySQL general log and cross-reference connection times," you do not have audit logging. You have a pile of lines you hope to reconstruct later. Audit logging for AI agents on MySQL means the answer is a single attributed record, not an investigation.
The difference comes down to standing access versus scoped access. With a standing MySQL user shared across tasks, the log is a flat stream with no identity and no task boundaries. With scoped, per-task access through a gateway, every command is already tied to the agent that ran it and the session it belonged to. Same database, completely different evidence.
What audit logging for an agent has to contain
A usable record for a MySQL agent has four parts: the identity that acted, the exact command, the time, and the outcome. MySQL's built-in logs give you statements and times but not a stable per-agent identity, because the agent usually connects as a shared database user. They also live on infrastructure the agent can often reach, which makes them weak evidence.
The record has to accumulate continuously and live outside the database the agent connects to. An audit log you assemble after an incident is a reconstruction, not a record.
Where the audit boundary sits
hoop.dev proxies the MySQL wire protocol through a network-resident agent, so every statement crosses the gateway. That is where audit logging happens: each command is captured at the SQL level, attributed to the identity that opened the session, and written outside the client. hoop.dev can also emit each session as a structured event through its webhooks plugin, so the record lands in your monitoring stack as it happens.
The architectural requirement is that the log lives where the agent cannot rewrite it. If the audit record sits inside the same database or process the agent drives, the agent can alter it. Putting capture in the gateway keeps the record independent of the thing it describes.
Set up audit logging step by step
- Register the MySQL connection in hoop.dev with
HOST, PORT, USER, PASS, and DB. - Give the agent its own gateway identity so its commands are attributable, not blended into a shared MySQL user.
- Confirm session capture is on for the connection.
- Point a webhook at your event sink (for example a Datadog intake) so each session becomes a record in your stack.
- Run a task, then confirm the command, identity, time, and outcome appear as one attributed record.
Pitfalls
- Trusting the general query log as an audit trail. It has no per-agent identity and lives where the agent can reach it.
- Logging connections, not commands. "Agent connected" is not "agent ran this UPDATE on this table."
- Shared identities. If every agent uses the same database user, no log can tell them apart. Give each one a named identity.
It helps to picture the record you want before you build it. One line should read, in effect: this agent ran this statement against this table at this time, and it succeeded. That line should exist whether or not anyone was watching, and it should be impossible for the agent to erase. When audit logging is captured in the gateway and streamed to your event sink, that line is there by default for every command, not assembled later from fragments scattered across the database host.
FAQ
Why not just enable MySQL's audit plugin?
It captures statements but attributes them to the database user, which is usually shared, and the records live on the same infrastructure the agent can reach. Gateway audit logging adds the named identity and keeps the record independent.
Can I send the records to my SIEM?
Yes. hoop.dev emits each session as a structured event through webhooks, so you can route it to Datadog, a SIEM, or any event sink for retention and alerting.
Does this apply to RDS MySQL?
Yes. The wire-protocol path is the same, and RDS connections can use per-user IAM auth on the web-app path to strengthen the identity behind each record.
For the controls that make each log entry clean, see just-in-time access per task and the wider approach to agent access governance. Run it yourself: hoop.dev on GitHub.
