When autonomous agents can prove a non-human identity to MySQL without ever handling a password, every query is traceable, approved, and safely masked.
In many organizations the reality is far from that. Engineers ship scripts that embed a single MySQL user and password, then copy the same secret to every CI runner, serverless function, and monitoring bot. The credential never expires, and no one can tell which automated process issued a particular SELECT or UPDATE. If a compromised container starts issuing destructive statements, the damage is immediate and the forensic trail is empty.
Non-human identity is the practice of assigning a distinct service account or federated token to each autonomous actor. It lets you apply least-privilege policies, rotate secrets automatically, and tie every request back to a concrete identity in your identity provider. The promise is clear: you stop treating bots as “just code” and start treating them as accountable principals.
Even with a proper service account, the request still travels straight to MySQL. The database sees a valid user, executes the statement, and returns data. At that point you have no visibility into which command was run, no chance to block a dangerous operation, and no way to mask sensitive columns before they reach the agent. The setup alone does not enforce the policies you need.
hoop.dev sits in the data path between the identity provider and MySQL, acting as an identity-aware proxy. The setup phase – OIDC or SAML authentication, provisioning of service accounts, and deployment of the hoop.dev agent inside the network – decides who may start a connection, but it does not enforce any guardrails on its own.
Once a request reaches hoop.dev, the gateway becomes the only place enforcement can happen. hoop.dev records each session, captures every query, and stores a replayable audit trail. It can mask credit‑card numbers, social security numbers, or any column you designate, doing so in real time before the data leaves the database. For statements that match a risk policy – for example, a DROP DATABASE or a mass UPDATE without a WHERE clause – hoop.dev can pause execution and route the request to a human approver. It can also block commands outright if they violate a pre‑approved policy set for that service account.
For MySQL specifically, hoop.dev proxies the native wire protocol, so existing clients (psql, mysql client, ORM libraries) work without modification. The gateway holds the database credentials, so the autonomous agent does not have access to the password. The agent presents its non-human identity token, hoop.dev validates it against the identity provider, maps the token to the appropriate MySQL role, and then forwards the request. All of the enforcement outcomes – session recording, inline masking, just‑in‑time approval, and command blocking – exist only because hoop.dev is positioned in the data path.
This architecture gives you three concrete benefits. First, you gain a complete, per‑agent audit log that satisfies internal compliance and external auditors. Second, you reduce blast radius by preventing rogue automated scripts from running destructive commands without oversight. Third, you protect sensitive data at the source, ensuring that even a compromised agent cannot exfiltrate unmasked values.
Why non-human identity matters for MySQL
Service accounts let you separate human and machine privileges. By issuing a unique token to each CI job, backup process, or monitoring daemon, you can grant exactly the SQL statements that job needs – SELECT on reporting tables, INSERT on audit logs, but never DELETE on production data. When that token is presented to hoop.dev, the gateway can verify the token’s audience, expiration, and group membership before allowing any traffic to reach MySQL.
How hoop.dev enforces policy in the data path
All enforcement happens inside the gateway. hoop.dev inspects the MySQL protocol stream, matches queries against configurable policies, and applies the appropriate action. If a policy says that the credit_card column must be redacted, hoop.dev replaces the raw value with a placeholder before sending the response to the agent. If a policy requires approval for any ALTER TABLE command, hoop.dev pauses the request, notifies the designated approver, and only forwards the command once approval is recorded. Every interaction is logged, and the logs are stored outside the MySQL instance, providing an audit trail.
Getting started with autonomous agents
Begin by configuring your identity provider to issue tokens for each service account. Deploy the hoop.dev gateway using the Docker Compose quick‑start, which automatically enables OIDC validation, masking, and guardrails. Register your MySQL instance as a connection in the hoop.dev UI, supplying the host, port, and a privileged credential that the gateway will use internally. Finally, map each service token to a MySQL role that reflects the least‑privilege set of statements the agent needs.
For step‑by‑step guidance, see the getting‑started documentation. The learn section provides deeper insight into policy definition, masking configuration, and approval workflows.
FAQ
- Do I need to change my existing MySQL clients? No. Because hoop.dev proxies the native wire protocol, all standard MySQL clients continue to work without code changes.
- What happens if an agent presents an expired token? hoop.dev rejects the connection before any traffic reaches MySQL, and the audit log records the failed attempt.
- Can I retroactively mask data that was already returned? Masking is applied in real time as data leaves MySQL, so only future responses are filtered. Historical data should be re‑processed if needed.
Ready to secure your autonomous MySQL workloads? Explore the open‑source repository and start building a zero‑trust data path today.
