PII/PHI redaction for AI coding agents on MySQL

An AI coding assistant that writes queries against a production MySQL instance can accidentally return full patient names, social security numbers, or credit‑card details, exposing the need for pii/phi redaction when it tries to illustrate a result set. The assistant’s output is then consumed by developers, logged by CI pipelines, or even displayed in a chat window, creating a direct path for protected data to leave the controlled environment.

Regulators treat any exposure of personally identifiable information (PII) or protected health information (PHI) as a violation, and the reputational cost of a leak can dwarf the engineering effort required to prevent it. When an LLM‑driven tool is given unrestricted read access, the model may echo back any column it sees, regardless of the original intent of the request.

Most teams today hand the AI service a static MySQL username and password, store those secrets in a vault, and let the model connect directly. The connection bypasses any middle‑box, so there is no visibility into which tables are queried, no way to scrub sensitive columns, and no audit trail that shows who asked for what data. The result is a convenient shortcut that sacrifices governance.

Why a non‑human identity alone is not enough

Moving to a service account with read‑only privileges is a step forward. The account can be scoped to a single database or schema, and role‑based access control can limit which tables are reachable. However, the request still travels straight from the AI process to MySQL. The gateway that could enforce column‑level policies is missing, so the agent can still retrieve raw PII/PHI and return it unfiltered. In addition, there is no built‑in mechanism to require a human reviewer before a query that touches sensitive tables is executed.

Introducing hoop.dev as the enforcement point

hoop.dev provides a Layer 7 gateway that sits between the AI agent and the MySQL server. The gateway proxies the native MySQL wire protocol, inspects each statement, and applies configurable policies before the request reaches the database. Because the gateway is the only place the traffic passes, it becomes the sole location where masking, approval, and logging can be enforced.

How the data path works for MySQL

When an AI service wants to run a query, it authenticates to hoop.dev using an OIDC token issued by the organization’s identity provider. The token conveys the service’s identity and group membership. hoop.dev validates the token, maps the identity to a set of MySQL connection credentials that it holds internally, and then opens a proxied session to the target database.

The MySQL agent runs inside the customer’s network, close to the database, so the gateway never exposes raw credentials to the AI process. All traffic is inspected at the protocol layer, allowing hoop.dev to identify columns that contain PII/PHI and replace their values with redacted placeholders before the response is sent back.

Enforcement outcomes delivered by hoop.dev

• hoop.dev masks sensitive fields in query results, ensuring that PII/PHI never leaves the gateway.
• hoop.dev records each MySQL session, capturing the exact statements, timestamps, and the originating identity for later replay or audit.
• hoop.dev can require a human approver to authorize any statement that accesses a protected table, providing just‑in‑time oversight.
• hoop.dev blocks commands that match a deny list, preventing destructive operations from being issued by an automated agent.

These outcomes exist only because the gateway sits in the data path; removing hoop.dev would revert the system to the original direct connection with no masking or audit.

Getting started

To implement PII/PHI redaction for MySQL, begin with the getting started guide. The documentation walks you through deploying the gateway, configuring the MySQL connector, and defining column‑level redaction policies. All of the heavy lifting – the OIDC integration, the agent deployment, and the policy engine – is handled by hoop.dev, so you can focus on the data protection rules that matter to your organization.

For deeper technical details, the learn section explains how to model identities, set up just‑in‑time approvals, and query the audit logs that hoop.dev generates. The source code and example configurations are available in the public repository.

Explore the hoop.dev repository on GitHub to see the implementation, contribute improvements, or file an issue.

FAQ

Does hoop.dev store any MySQL credentials?

Yes, the gateway holds the database credentials internally. They are never exposed to the AI agent or any downstream client, and access to the credentials is governed by the same OIDC‑based policy that controls query execution.

Can I audit which AI service accessed which rows?

hoop.dev records every statement together with the authenticated identity, timestamps, and the redaction actions applied. The audit logs can be exported to SIEMs or queried directly for compliance reporting.

What happens if a new column containing PII is added?

Update the redaction policy in hoop.dev to include the new column name or pattern. The next query that returns that column will automatically have its values redacted without requiring a code change in the AI service.