Many assume that a machine‑to‑machine client can simply reuse a human‑generated password to talk to MySQL, and that this is safe. In reality, relying on shared passwords defeats the purpose of non-human identity, creates shared secrets, hides who actually issued each query, and gives no way to stop a rogue command before it reaches the database.
In most teams that run MCP (Machine‑Control‑Plane) servers against a MySQL instance, the connection is configured once with a static username and password. The same credential is baked into every server image, duplicated across environments, and rotated only when an incident forces a change. Engineers rarely see which server issued a particular SELECT or UPDATE, and there is no gate that can demand approval for a dangerous ALTER statement. The result is a blind spot: the identity of the caller is a human‑originated secret, the audit trail is incomplete, and the risk of lateral movement is high.
Why non-human identity matters for MySQL and MCP servers
Non-human identity means that a service, script, or automated agent authenticates with a token or a dedicated service account rather than a shared password. The token can be short‑lived, scoped to a specific role, and issued by an identity provider that knows the exact workload that requested it. This approach eliminates password sprawl, ties every request to a verifiable workload, and enables policies that depend on the caller’s identity.
Even with non-human identity in place, the request still travels directly from the MCP server to MySQL. The database sees only a generic MySQL user, the connection bypasses any policy engine, and there is no automatic recording of the session, no inline masking of sensitive columns, and no just‑in‑time approval step for privileged statements. The setup solves the credential problem but leaves the enforcement gap wide open.
Placing the gateway in the data path
hoop.dev acts as a Layer 7 gateway that sits between the MCP server and the MySQL endpoint. The server presents an OIDC or SAML token to the gateway. hoop.dev validates the token against the configured identity provider, extracts the workload’s group membership, and maps that information to a MySQL role that the gateway itself uses to talk to the database. The actual MySQL password never leaves the gateway, so the server never sees a secret.
Because the gateway is the only point where traffic passes, hoop.dev can enforce every control you need. hoop.dev records each session, preserving a replayable audit log that shows exactly which MCP instance issued which query. hoop.dev masks sensitive fields in result sets, ensuring that downstream logs or screens never expose credit‑card numbers or personal identifiers. When a query matches a risky pattern, such as DROP DATABASE or ALTER USER, hoop.dev requires a just‑in‑time approval from an authorized human before forwarding the command. If the command is disallowed, hoop.dev blocks it outright, protecting the database from accidental or malicious damage.
Getting started
The first step is to deploy the gateway in the same network segment as your MySQL cluster. 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, you point your MCP servers at the hoop.dev endpoint instead of the raw MySQL host. The learn section contains deeper explanations of masking policies, approval workflows, and session replay.
For the full source code, configuration examples, and contribution guidelines, explore the repository on GitHub: Explore the source code on GitHub.
FAQ
- Can I still use existing MySQL users? Yes. hoop.dev can map each non-human token to an existing MySQL role, so you do not need to recreate every user. The gateway simply acts as a proxy that presents the mapped credentials.
- Does hoop.dev store passwords? No. The gateway holds the MySQL credential in memory only for the duration of a session and never writes it to disk. All authentication to the gateway itself is performed with OIDC tokens, eliminating password exposure.
- What impact does the gateway have on latency? Because hoop.dev operates at the protocol layer, the added round‑trip is minimal, typically a few milliseconds. The security benefits of audit, masking, and approval far outweigh the slight latency increase.
