Many assume that protecting personal health information with pii/phi redaction is a matter of configuring the application that talks to MySQL, but the reality is that data travels in clear text across the network before any custom code sees it.
That misconception leads teams to rely on shared database credentials, static service accounts, and direct socket connections from MCP servers. The result is a pipeline where every query and response is visible to anyone who can sniff the traffic or compromise the server, and no central record shows who read or altered a protected field.
In practice, engineers often grant a service account full read/write rights to a MySQL instance, embed the password in deployment manifests, and let the MCP server issue queries without any visibility. The database returns rows containing names, social security numbers, or medical identifiers straight to the caller. No audit log captures the exact query, no inline filter removes the sensitive columns, and no approval step blocks a bulk export.
Why the current setup still leaves pii/phi exposed
Even when an organization adopts non‑human identities, token‑based authentication, and least‑privilege roles, the request still reaches MySQL directly. The gateway that authenticates the token does not sit on the data path, so it cannot inspect or transform the MySQL wire protocol. Consequently, the system lacks three critical controls: real‑time redaction of protected fields, a reliable record of every query, and the ability to require a human approval before a dangerous SELECT or UPDATE runs.
How hoop.dev provides pii/phi redaction for MySQL
hoop.dev acts as a Layer 7 gateway that sits between the MCP server and the MySQL endpoint. Identity is verified once via OIDC or SAML; the gateway reads group membership and decides whether the request may start. The actual MySQL credentials are stored inside the gateway, never exposed to the client.
When the MCP server opens a connection, the traffic is routed through hoop.dev. Because the gateway intercepts the native MySQL protocol, it can apply inline masking rules to any column that matches a configured pii/phi pattern. The masking happens before the response leaves the gateway, so the downstream client never sees raw protected data.
At the same time, hoop.dev records each session, capturing the exact statement, the identity that issued it, and the masked result. If a query matches a high‑risk pattern, such as exporting an entire table, hoop.dev can pause the request and trigger a just‑in‑time approval workflow. Only after an authorized reviewer approves does the gateway forward the statement to MySQL.
All of these enforcement outcomes, inline redaction, session recording, and conditional approval, exist because hoop.dev resides in the data path. Without that placement, the same identity and credential setup would still allow unrestricted access.
Architectural benefits of the gateway approach
- Consistent policy enforcement across every MySQL client, whether it is a human operator or an automated MCP server.
- Reduced blast radius: even if a service account is compromised, the attacker cannot retrieve unmasked pii/phi without passing through the gateway.
- Audit‑ready evidence: each session is logged with identity, timestamp, and masked payload, satisfying regulatory expectations for data‑access trails.
- Just‑in‑time access: privileges are granted for the duration of a single session, eliminating long‑lived credentials.
Getting started
Follow the getting‑started guide to deploy the gateway, register your MySQL target, and define masking rules for pii/phi fields. The documentation walks through the required OIDC configuration, the agent placement near your database, and how to enable session recording.
For deeper details on configuring inline masking and approval policies, see the learn section. All configuration examples are provided in the repository.
FAQ
Does hoop.dev modify the underlying MySQL schema?
No. The gateway only transforms the data in transit. The database schema remains unchanged, and applications that bypass the gateway see the original data.
Can I apply different masking rules per user group?
Yes. Masking policies are attached to identity attributes read from the OIDC token, allowing granular control based on department, role, or compliance requirement.
What happens to the original data if a query is blocked?
The gateway stops the statement before it reaches MySQL, logs the attempt, and optionally notifies a reviewer. No data is altered or exposed.
Explore the full source code, contribute improvements, and see the latest releases on GitHub.
