An AI coding assistant spins up a temporary MySQL client to fetch schema information for a feature branch. The engineer trusts the assistant, but there is no visibility into which tables are queried, whether sensitive rows are returned, or if the agent accidentally runs a destructive statement. When the assistant finishes, the team is left with a mystery: what exactly happened on the database?
That uncertainty is the core of the session recording problem for AI‑driven workloads. An autonomous agent can issue hundreds of statements in seconds, and without a reliable replay log you cannot answer basic questions such as: Did the agent read customer PII? Did it issue a DELETE without a WHERE clause? Did it trigger a cascade that impacted downstream services? The lack of a trustworthy audit trail makes forensic analysis, compliance reporting, and even simple debugging a guessing game.
Why recording must sit on the data path
Recording a MySQL session is not a matter of configuring the client or the database engine. The database itself cannot distinguish whether a query originated from a human, a CI job, or an AI agent, and it cannot enforce policy without being in the request flow. The only place where every byte of the MySQL wire protocol can be observed, altered, or persisted is the gateway that sits between the identity layer and the target database.
Authentication and identity (OIDC or SAML tokens, service‑account roles) decide *who* may start a connection, but they do not provide the enforcement point. The gateway, positioned in the data path, is the sole component that can reliably capture the full request‑response exchange, apply masking if needed, and store the interaction for later replay. Without that gateway, any “recording” would be fragmented, optional, or dependent on the client’s willingness to log its own activity.
Introducing hoop.dev as the MySQL gateway
hoop.dev fulfills the architectural requirement of a Layer 7 proxy that sits in the MySQL data path. When an AI coding agent requests a MySQL connection, it authenticates to hoop.dev via an OIDC token. hoop.dev validates the token, extracts group membership, and then establishes a proxied session to the MySQL server using a credential that only the gateway knows.
From that point onward, hoop.dev acts as the conduit for every MySQL packet. It records each session in a log, preserving the exact query text, timestamps, and response payloads. Because the recording happens inside the gateway, the AI agent never sees the underlying credential, and the organization gains a trustworthy replayable audit trail. The recorded sessions can be streamed to a secure storage backend, indexed, and later replayed through hoop.dev’s built‑in viewer for forensic analysis.
Beyond raw logging, hoop.dev can apply inline masking to hide sensitive columns in query results, ensuring that even if a replay is examined, PII remains protected. The same gateway also enforces just‑in‑time approvals for risky statements, but the focus here is the session recording capability that turns an opaque AI interaction into a verifiable record.
How the architecture fits together
- Setup layer: Identity providers (Okta, Azure AD, Google Workspace) issue OIDC tokens for users and service accounts. Tokens are presented to hoop.dev, which uses them to decide whether a connection request is allowed.
- Data path: hoop.dev runs a network‑resident agent near the MySQL instance. All client traffic is routed through this agent, giving hoop.dev full visibility into the MySQL wire protocol.
- Enforcement outcome: hoop.dev records each session, stores the log, and makes it available for replay. Because the recording is performed by hoop.dev, the audit evidence exists even if the AI agent is compromised or misbehaves.
This separation ensures that the session‑recording guarantee is not an artifact of a particular client or a database‑side feature, but a property of the gateway that cannot be bypassed without losing connectivity.
Getting started with hoop.dev for MySQL
Deploy the gateway using the Docker Compose quick‑start, which provisions the agent, the OIDC verifier, and the MySQL proxy in a single stack. Register the MySQL target in hoop.dev’s configuration, supplying the host, port, and a dedicated database user that the gateway will use. Once the gateway is running, any AI coding agent that authenticates with a valid OIDC token can connect through hoop.dev’s MySQL endpoint. All interactions will be automatically recorded.
For detailed deployment steps, see the getting‑started guide. The learn section provides deeper insight into session‑recording policies, storage options, and replay tooling.
FAQ
- Can I retrieve a recorded session? Yes. hoop.dev stores each session in a searchable log store. You can query by time range, user, or MySQL instance, and replay the exact request‑response flow through the web UI.
- Does hoop.dev keep database credentials? The gateway holds the credential needed to talk to MySQL, but it never exposes it to the client or the AI agent. The secret remains inside the network‑resident agent.
- What is the performance impact? Because hoop.dev proxies at the wire‑protocol level, the overhead is minimal and comparable to a typical TLS termination proxy. High‑throughput workloads can be scaled by adding more agent replicas.
By placing session recording at the gateway, organizations gain a reliable, replayable audit trail for every AI‑driven MySQL interaction, turning opaque automation into a transparent, controllable process.
Explore the source code and contribute on GitHub.
