All posts

Session recording for MCP servers on MySQL

Common misconception about MySQL session logs Many teams assume that the MySQL server or the client library automatically captures a complete, tamper‑proof record of every query issued by an MCP (Machine‑Control‑Plane) server, but that expectation of session recording is misplaced. In reality, native MySQL logs can be rotated, filtered, or even disabled, and they never include the context of who issued a command or whether an approval step was required. Relying on those logs leaves a blind spot

Free White Paper

SSH Session Recording + Single Sign-On (SSO): The Complete Guide

Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.

Free. No spam. Unsubscribe anytime.

Common misconception about MySQL session logs

Many teams assume that the MySQL server or the client library automatically captures a complete, tamper‑proof record of every query issued by an MCP (Machine‑Control‑Plane) server, but that expectation of session recording is misplaced. In reality, native MySQL logs can be rotated, filtered, or even disabled, and they never include the context of who issued a command or whether an approval step was required. Relying on those logs leaves a blind spot for compliance and incident response.

Another frequent belief is that an MCP server can embed its own audit hook without affecting existing tooling. Adding custom logging code forces developers to maintain separate agents, introduces version drift, and still cannot guarantee that privileged users cannot bypass the hook.

Why a gateway is the missing piece

To close the gap, you need a control point that sits between the identity that initiates the request and the MySQL instance that executes it. The gateway becomes the sole place where traffic can be inspected, approved, or recorded before it ever reaches the database. This approach satisfies two requirements at once: it centralises audit collection and it prevents any client from sidestepping the policy.

The prerequisite for this model is a solid identity foundation. Engineers, service accounts, or AI agents authenticate via OIDC or SAML, obtaining short‑lived tokens that convey group membership and role information. Those tokens are verified at the gateway, which then decides whether the request may proceed. This setup establishes who is asking for access, but it does not yet enforce any guardrails on the actual data path.

Introducing hoop.dev as the data‑path enforcement layer

hoop.dev is a Layer 7 gateway that proxies MySQL wire‑protocol traffic. When an MCP server connects, the request first passes through hoop.dev’s agent that lives inside the same network as the database. Because the gateway sits on the data path, it can apply policies that are impossible to enforce from the client side.

Continue reading? Get the full guide.

SSH Session Recording + Single Sign-On (SSO): Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

For session recording, hoop.dev records the full request and response stream for each MySQL connection. It stores the session data in a location separate from the MySQL process, providing a reliable audit trail. The gateway never exposes the underlying credentials to the client, and the recorded data is kept outside the database, ensuring the audit trail remains trustworthy.

Because the recording happens at the protocol layer, it works for any MySQL client – the MySQL CLI, JDBC drivers, or an MCP server using a native driver. No code changes are required on the server side, and the MCP server continues to use its existing connection strings.

Key enforcement outcomes delivered by hoop.dev

  • Complete session capture: Every query and result set is logged, providing a replayable audit trail.
  • Identity binding: Each log entry is tagged with the OIDC principal that initiated the request.
  • Separate storage: The gateway writes logs to a location that the MySQL instance does not access, keeping the audit data independent of the database.
  • Zero client impact: Existing MySQL applications connect through the gateway without modification.

How to get started

Begin by deploying the hoop.dev gateway in your environment. The official getting started guide walks you through a Docker Compose launch, OIDC configuration, and the registration of a MySQL connection. Once the gateway is running, register your MCP server as a client and grant it the appropriate group membership.

After the connection is defined, hoop.dev will automatically begin recording every MySQL session that passes through it. You can explore the recorded sessions via the web UI or export them for downstream analysis. Detailed information about the recording feature and other guardrails is available in the learn section of the documentation.

Next steps and community support

If you prefer to inspect the source or contribute enhancements, the project is open source on GitHub. Visit the repository to clone the code, raise issues, or submit pull requests: hoop.dev on GitHub.

By placing session recording at the gateway, hoop.dev gives you a trustworthy audit trail for every MySQL interaction performed by MCP servers. This single control surface replaces fragmented client‑side logging and ensures that compliance, forensics, and security teams have the evidence they need, exactly when they need it.

Open source

Save the open-source gateway for agent data access

Hoop is MIT-licensed infrastructure for controlling how AI agents reach production data. Star hoophq/hoop so you can inspect it, deploy it, or share it when your team starts governing agent access.

Star and save the repo →More posts