Non-human identity for AI coding agents on MySQL

When a nightly build runs an AI‑generated migration script against a production MySQL instance, the process uses a non-human identity that relies on a static username and password stored in the CI pipeline. The credential is shared across dozens of jobs, and no one can tell which migration actually touched which table.

This pattern is common in organizations that treat AI coding agents like any other service account. The agents get a static database user, the secret lives in a vault or CI secret store, and the connection goes straight to MySQL. The result is credential sprawl, invisible activity, and no way to enforce data‑privacy rules on the responses that the AI receives.

Why non-human identity alone is not enough

Introducing a dedicated service account for each AI agent – the essence of non-human identity – solves the secret‑sharing problem. Each agent now has its own OIDC or SAML token, and the identity provider can enforce least‑privilege scopes. However, the connection still terminates directly at the database. The gateway that would inspect queries, mask sensitive columns, or require an approval before a destructive command runs is missing. Without a data‑path enforcement point, you cannot record the session, replay it for audit, or apply inline masking to protect PII that the AI might inadvertently read.

hoop.dev as the data‑path gateway for MySQL

hoop.dev provides the missing layer. It is a Layer 7 gateway that proxies the MySQL wire protocol. The architecture places hoop.dev between the AI agent and the database, so every packet traverses the gateway before reaching MySQL. The gateway holds the actual database credentials; the agent never sees them. Authentication to hoop.dev is performed with the agent’s non-human identity token, which hoop.dev validates against the configured OIDC or SAML provider.

Because hoop.dev sits in the data path, it can enforce all runtime guardrails:

• Just‑in‑time access. hoop.dev checks the token, evaluates the policy for the requested database, and grants a short‑lived connection only for the duration of the AI job.
• Approval workflows. If a query matches a risky pattern – for example, a DROP DATABASE command – hoop.dev can pause the request and route it to a human approver before forwarding it to MySQL.
• Inline data masking. Responses that contain regulated fields are rewritten on the fly, ensuring the AI never receives raw PII.
• Session recording and replay. hoop.dev captures the full query‑response stream, creating a record that can be reviewed later.

Each of those enforcement outcomes is possible only because hoop.dev is the gateway that all traffic must pass through. The setup that creates the non-human identity – the service account, the OIDC client, the role bindings – decides who is making the request, but it does not enforce policy. The gateway is the sole place where policy can be applied, and hoop.dev is the component that does it.

Architectural steps to protect AI agents on MySQL

1. Deploy the hoop.dev gateway. Use the official Docker Compose quick‑start or the Kubernetes manifest to run the gateway inside the same network as the MySQL server. The deployment includes an agent that resides near the database and a control plane that manages policies.

2. Register the MySQL target. In the hoop.dev console you define a connection that includes the host, port, and the database credentials that the gateway will use. The credentials are stored only inside the gateway.

3. Configure non-human identity. Create a service account in your identity provider for each AI coding agent. Issue OIDC tokens that encode the agent’s role and allowed scopes. hoop.dev is configured as a relying party, so it can verify those tokens on every connection attempt.

4. Define guardrail policies. Using the hoop.dev policy language you specify which statements require approval, which columns must be masked, and the maximum session duration. Policies are evaluated in real time as the AI agent sends MySQL commands.

5. Run the AI job. The agent connects with its OIDC token via the standard MySQL client library. The request is intercepted by hoop.dev, which applies the policies, records the session, and forwards the allowed statements to MySQL.

All of the above is described in detail in the getting‑started guide. For deeper guidance see the hoop.dev learn portal. The open‑source repository on GitHub contains the full deployment manifests and example policy snippets you can adapt for your environment.

FAQ

How does non-human identity differ from a shared credential?

Non-human identity gives each AI agent a distinct token that can be revoked independently, while a shared credential is a single secret that, once compromised, grants unlimited access to every consumer of that secret.

Can hoop.dev mask data that the AI agent never requested?

Yes. hoop.dev inspects the response stream from MySQL and can rewrite any column that matches a masking rule before the data reaches the agent, ensuring that PII never leaves the gateway in clear text.

Is it possible to add guardrails to an existing MySQL deployment?

Because hoop.dev is a proxy, you can insert it into the network path of any MySQL instance without changing the database itself. Once the gateway is in place, you can enable recording, masking, and approval policies for all existing workloads.

Explore the full open‑source implementation on GitHub and start securing your AI‑driven MySQL workloads today.