Just-in-time access for MCP servers on MySQL

Do you want your MySQL‑backed MCP servers to grant access only at the moment a request arrives? Just-in-time access provides that capability by issuing temporary privileges that expire as soon as the operation completes.

Most teams today bake a static username and password into the MCP server configuration or rely on a long‑lived IAM credential that never changes. The credential is checked into source control, shared across environments, and used by every instance of the service. When a developer or an automated job needs to run a query, the request flows directly to MySQL with no intervening gate. The database sees a single identity that has unrestricted read and write rights, and there is no record of who issued which statement, what data was returned, or whether the operation should have been approved.

This approach violates the principle of least privilege and makes it impossible to answer audit questions such as “who read the credit‑card column at 02:15 UTC?” or “did anyone run a DROP TABLE on the production schema?” The lack of a real access boundary also means that a compromised MCP server can immediately exfiltrate data without triggering any alert.

What organizations really need is just‑in‑time access: a mechanism that grants a database connection only for the duration of a specific request, evaluates the request against policy, and then revokes the privilege immediately afterward. The ideal solution would sit between the MCP server and MySQL, inspect each wire‑level command, and enforce policies such as approval workflows, column masking, or command blocking. However, even with that requirement in place the request still reaches MySQL directly, and without a dedicated gateway there is no place to enforce the policy, no audit trail, and no way to mask sensitive fields.

Implementing just-in-time access for MySQL

hoop.dev fulfills the missing piece by acting as a Layer 7, identity‑aware proxy that sits on the network path between the MCP server and the MySQL instance. The gateway verifies the caller’s OIDC or SAML token, extracts group membership, and then applies a policy that can:

• grant a temporary session for the specific request,
• require a human approver for high‑risk statements such as DDL or data‑export commands,
• mask columns that contain personally identifiable information before they are sent back to the client, and
• record the full query and response for replay and audit.

Because hoop.dev speaks the native MySQL wire protocol, the MCP server continues to use its ordinary MySQL client library. The only change is that the connection endpoint points at the gateway instead of the database host. The gateway holds the actual database credential; the MCP server does not have visibility into the password or IAM key. When a request arrives, hoop.dev checks the caller’s identity, consults the policy, and either allows the statement, routes it to an approval queue, or blocks it outright. After the statement finishes, the temporary grant is revoked, ensuring the privilege exists for no longer than the request itself.

Deploying the gateway follows the standard getting‑started guide. A Docker Compose file starts the gateway and a side‑car agent that lives inside the same network segment as MySQL. The administrator registers the MySQL target, supplies the static database user that the gateway will use, and defines a just‑in‑time policy that ties specific MCP service accounts to allowed query patterns. Once the configuration is in place, every MySQL interaction from the MCP server is forced through hoop.dev, turning the gateway into the sole enforcement point.

Why the data path matters

Setup steps such as creating OIDC clients, assigning IAM roles, or provisioning service accounts decide who can attempt a connection, but they do not enforce what the caller may do once the connection is open. That enforcement must happen where the traffic passes, and hoop.dev is the only component that sits on that path. Because hoop.dev is the active gatekeeper, it is the entity that:

• records each session for later replay,
• applies inline masking to protect sensitive columns,
• blocks dangerous commands before they reach MySQL, and
• initiates just‑in‑time approval workflows when policy requires human oversight.

Without hoop.dev, even a perfectly scoped OIDC token would still allow the MCP server to issue unrestricted queries directly to the database, leaving the organization without the audit evidence required for compliance frameworks.

Getting started and next steps

To try this pattern yourself, follow the documentation in the learn section. It walks you through deploying the gateway, registering a MySQL connection, and defining a just‑in‑time policy that matches your security requirements. All of the heavy lifting, session recording, masking, approval routing, is handled by hoop.dev out of the box.

When the proof of concept is working, you can extend the policy to cover additional MCP services, tighten column‑level masking rules, or integrate with your existing ticketing system for approval workflows. Because hoop.dev is open source and MIT licensed, you retain full control over the deployment topology and can audit the code yourself.

FAQ

What is the difference between just‑in‑time access and rotating credentials?
Rotating credentials changes the secret on a schedule, but the credential remains valid for the entire rotation window. just‑in‑time access grants a privilege only for the exact request, and the gateway can enforce additional checks such as approvals or masking before the query reaches MySQL.

Will routing MySQL traffic through a gateway add noticeable latency?
The proxy operates at the wire‑protocol level and adds only a few milliseconds of overhead, which is negligible for most database workloads.

Can existing MySQL client libraries be used without modification?
Yes. Because hoop.dev implements the native MySQL protocol, any standard client can connect to the gateway endpoint exactly as it would to the database.

Ready to secure your MCP‑MySQL connections with just‑in‑time access? Explore the open‑source repository on GitHub and start building a zero‑trust data path today.