Every query an autonomous agent runs against MySQL is captured, replayable, and tied to the agent’s identity, so you can answer “who did what” without hunting logs.
That visibility also lets you spot unexpected data pulls, verify that a CI job only performed its intended migrations, and provide auditors with concrete proof of compliance. When an incident occurs, you can replay the exact command stream, see the rows returned, and confirm whether a secret was exposed.
Why session recording matters for autonomous agents
Agents, whether they are CI pipelines, scheduled jobs, or AI‑driven assistants, operate without human oversight. Their speed and scale amplify any mistake. A stray UPDATE that runs on the wrong schema can cascade across dozens of downstream services. Without a reliable record, the root cause remains hidden, and remediation becomes guesswork.
Session recording solves three core problems:
- Accountability: each action is linked to a specific service account or token.
- Forensics: a complete, time‑ordered replay is available for post‑mortem analysis.
- Audit readiness: regulators and internal auditors can request a concrete trail instead of vague summaries.
Current practice and its gaps
Teams often let agents connect directly to MySQL using static credentials stored in configuration files or secret managers. The connection bypasses any central control point, so the database sees only a generic client identity. No component records the exact SQL statements, the result sets, or the duration of each command. If a job fails, you must rely on application logs that may be incomplete or rotated.
Because the traffic flows straight from the agent to the database, you cannot enforce runtime policies, mask sensitive columns, or require a human to approve risky statements. The database itself does not provide a built‑in replay feature, so the only evidence you have is whatever the agent chose to log.
The missing control point
What you need is a gateway that sits between the autonomous identity and the MySQL wire protocol. The gateway must be the sole path for every request, so it can inspect, record, and, if necessary, intervene. The identity system (OIDC or SAML) can still decide which agent is allowed to start a session, but the enforcement of session recording lives only in that data‑path component.
Without such a component, even a perfectly scoped token cannot guarantee that a session is captured. The enforcement outcome, recording each command and its result, depends on the gateway, not on the token or the MySQL server.
hoop.dev as the data‑path enforcement layer
hoop.dev provides the required Layer 7 gateway. It proxies the MySQL wire protocol, holds the database credential, and presents a single endpoint to agents. When an agent authenticates via OIDC, hoop.dev validates the token, extracts group membership, and then establishes a proxied session to MySQL.
During that session hoop.dev records every statement, the full response payload, timestamps, and the originating identity. The recorded session is stored in a secure audit store that can be replayed through the hoop.dev UI or API. Because the gateway is the only path, you can be certain that no query escapes recording.
How session recording works
- Agent initiates a connection to hoop.dev using its standard MySQL client.
- hoop.dev authenticates the agent’s OIDC token and maps it to a logical role.
- The gateway opens a backend connection to the MySQL instance using a service‑level credential that never leaves the gateway.
- Each client‑to‑server packet is logged, enriched with the agent’s identity, and written to the audit store.
- Administrators can replay the session, filter by statement type, or export the log for downstream analysis.
The same flow also supports just‑in‑time approvals for risky statements, but the core guarantee, session recording, exists even when no approval is required.
Getting started
To add session recording for your MySQL agents, follow the getting‑started guide. The guide walks you through deploying the gateway, configuring the MySQL connection, and enabling the recording feature. All of the heavy lifting is handled by hoop.dev; you only need to point your agents at the new endpoint.
For deeper technical details about how hoop.dev inspects the MySQL protocol and stores session data, see the learn section. It explains the policy model, the audit store architecture, and how to query recorded sessions.
FAQ
Do I need to change my existing MySQL client?
No. Agents continue to use the standard MySQL client libraries. The only change is the host and port, which now point to the hoop.dev gateway.
What happens if an agent loses its OIDC token mid‑session?
The gateway validates the token at session start. Once the session is established, the recorded stream continues until the connection closes, ensuring a complete audit trail even if the token expires.
Can I replay a session without exposing raw credentials?
Yes. The replay feature streams the captured statements and results without ever revealing the underlying MySQL password, because the gateway never discloses it to the client.
Explore the source code on GitHub to see how the recording pipeline is implemented and to contribute enhancements.
