When an AI coding agent talks to a MySQL database with a long‑lived credential, a single leak can expose every table, every row, and every secret stored inside. The cost of such a breach is not just data loss; it includes lost trust, regulatory fines, and the engineering effort required to rotate credentials across dozens of services.
Because AI agents are often spun up automatically, teams tend to grant them broad, static permissions to avoid friction, missing the benefits of just-in-time access.
Those permissions persist long after the original task finishes, giving an attacker a permanent foothold if the agent’s container is compromised.
What engineers really need is just-in-time access: a model where the agent receives a fresh, minimally‑privileged token only for the exact query it is about to run. In practice, however, the request still travels straight to the MySQL endpoint. No gateway inspects the traffic, no audit trail records the statement, and no inline mask hides sensitive columns. The database sees a raw connection from the agent, and any misstep is invisible to the security team.
hoop.dev places an identity‑aware proxy directly in the data path between the AI agent and MySQL. The gateway terminates the client connection, validates the user’s OIDC token, and then forwards the request to the database using a short‑lived credential that it generates on demand. Because the enforcement point is the gateway, hoop.dev can apply policy before any query reaches the server.
When an AI agent initiates a MySQL session, hoop.dev first checks the user’s group membership and any request‑specific tags. If the operation matches a policy that requires approval, such as a DROP TABLE or a bulk UPDATE, hoop.dev pauses the request and routes it to a human approver. Once approved, the gateway injects a fresh, least‑privilege MySQL user and streams the query to the backend.
Every interaction passes through hoop.dev, so the gateway can record the full session for later replay. It also masks sensitive fields in result sets, ensuring that credit‑card numbers or personal identifiers never leave the controlled environment in clear text. If a query contains a dangerous command, hoop.dev blocks it outright, preventing accidental data loss. All of these enforcement outcomes exist because hoop.dev sits in the data path; the MySQL server itself remains unchanged.
By routing traffic through hoop.dev, organizations gain a complete audit trail that satisfies internal and external compliance checks. The just-in-time credential never touches the agent’s code base, eliminating the risk of credential leakage. Inline masking reduces exposure of regulated data, and approval workflows add a human safeguard for high‑impact operations. Together these controls shrink the attack surface and make it possible to prove who accessed what, when, and why.
To get started, follow the getting‑started guide and explore the learn section for deeper coverage of masking, guardrails, and session replay. The open‑source repository contains all the manifests you need to deploy the gateway in a container or Kubernetes cluster.
Why just-in-time access matters for AI agents
AI agents execute code that is generated on the fly, often based on prompts that change every minute. Static credentials cannot adapt to that fluidity without exposing unnecessary privileges. Just-in-time access aligns the credential lifespan with the actual work, ensuring that even a compromised agent can only act for a few seconds before the token expires.
How hoop.dev enforces policy on the MySQL wire protocol
hoop.dev acts as a Layer 7 proxy for the MySQL wire protocol. It terminates the client connection, inspects each packet, and decides whether to forward, mask, or block it. The gateway holds the permanent MySQL user/password, while the agent never sees any secret. When a request is allowed, hoop.dev creates a temporary MySQL user that has only the minimal privileges required for the operation, and uses that user to communicate with the backend.
Key enforcement outcomes
- Session recording – hoop.dev stores a replayable log of every query and response.
- Inline data masking – sensitive columns are redacted before they leave the gateway.
- Command‑level approval – destructive statements trigger a just‑in‑time approval workflow.
- Automatic credential rotation – short‑lived MySQL users are generated per request, eliminating static secrets.
Frequently asked questions
Can I use hoop.dev with existing MySQL users?
Yes. hoop.dev can be configured to reuse an existing MySQL account for the gateway itself while still issuing temporary users for each request.
Does hoop.dev add latency to MySQL queries?
The additional hop introduces a small, predictable overhead, but the security benefits of auditability, masking, and just‑in‑time credentials typically outweigh the performance impact.
Is the gateway itself a single point of failure?
hoop.dev can be deployed in a highly available configuration behind a load balancer, ensuring that the data path remains resilient.
Explore the source code and contribute on GitHub.
