Audit logging for MCP servers on MySQL

How can you prove every query an AI‑driven MCP server sends to MySQL without exposing credentials or slowing down development? audit logging gives you that proof.

Today many teams let their MCP (Model‑Control‑Plane) servers talk directly to a MySQL instance. The connection is usually configured with a static username and password stored in environment variables or secret managers, and the server uses the native MySQL client library to execute queries. Because the traffic flows straight from the MCP process to the database, there is no central point that can observe, record, or filter the statements. If a buggy prompt or a malicious model generates an unexpected DELETE, the operation happens silently. Auditors later have no reliable log of what was run, and forensic investigations become guesswork.

What organizations often need is audit logging – a reliable trail that shows which model issued each statement, when it ran, and what the response looked like. Adding a logger inside the MCP code is fragile: developers must remember to instrument every call, and the logger inherits the same credential exposure risks as the application itself. Even with careful instrumentation, the log lives on the same host that runs the model, so a compromised server can erase or alter the evidence.

The missing piece, then, is a place where every MySQL wire‑protocol exchange can be inspected, recorded, and optionally masked, without the MCP server ever seeing the underlying credentials. The solution must sit on the network path between identity and the database, enforce policies, and emit a complete audit trail.

Why audit logging matters for MCP‑driven MySQL access

Model‑controlled applications are powerful but unpredictable. A single prompt can cause the MCP server to generate a SELECT, an UPDATE, or a DROP statement based on the model’s interpretation of user intent. Without audit logging, security teams cannot answer basic questions:

• Which model version issued a particular data‑modifying command?
• Did a compliance‑sensitive column appear in the result set?
• Was a privileged operation performed outside of an approved workflow?

Regulatory frameworks often require evidence of who accessed what data and when. For AI‑augmented workloads, that evidence must include the model’s identity, not just a human user. Centralizing the log at a gateway also enables replay – security analysts can re‑run the captured session against a test database to verify impact.

How hoop.dev inserts audit logging into the MySQL data path

hoop.dev acts as a Layer 7 gateway that proxies the MySQL wire protocol. When an MCP server initiates a connection, it authenticates to hoop.dev via an OIDC token. hoop.dev validates the token, extracts group and role information, and then establishes a backend connection to the MySQL instance using a credential that only the gateway knows.

Because every packet travels through hoop.dev, the gateway can record the full query‑response cycle. It writes a structured audit entry that includes:

• Timestamp of the request
• Identity of the MCP server (derived from the OIDC token)
• The exact SQL statement
• Result metadata and any masked fields
• Outcome status (success, error, blocked)

The audit record is stored outside the MCP host, ensuring that even if the model’s runtime is compromised, the log remains intact. hoop.dev also offers inline masking, so sensitive columns (for example, credit‑card numbers) can be redacted before the response reaches the model, satisfying data‑privacy requirements while still preserving a complete audit trail.

Because the gateway sits at the protocol level, it does not require any code changes in the MCP server. Existing MySQL clients continue to work unchanged; the only difference is the network endpoint they point to – the hoop.dev gateway instead of the raw database host.

Getting started quickly

To try this pattern, follow the Getting started guide. Deploy the gateway with Docker Compose, register your MySQL connection, and configure OIDC authentication. The documentation walks you through enabling audit logging for MySQL, selecting which fields to mask, and viewing the generated audit records.

For deeper insight into the feature set, explore the Learn section, which explains how guardrails, just‑in‑time approvals, and session replay complement audit logging.

All of the implementation details – from the Docker Compose file to the exact API calls used by the gateway – live in the open‑source repository. Explore the repository on GitHub to see the code that makes the audit trail possible.

FAQ

Does hoop.dev store query results?

hoop.dev records the metadata of each response and can apply inline masking, but it does not retain full result sets unless you enable that option in the audit configuration. This keeps storage costs low while still providing evidence of what was returned.

Can I enforce approvals before a destructive query runs?

Yes. The gateway can be configured to pause any statement that matches a policy (for example, DROP, DELETE without a WHERE clause) and route it to a human approver. The approval decision is logged alongside the original request, giving a complete audit trail.

Is the audit log tamper‑proof?

The log is written by the gateway process, which runs in a separate network zone from the MCP server. While hoop.dev does not claim cryptographic immutability, the separation makes it extremely difficult for a compromised MCP host to alter the records without also compromising the gateway.