Non-human identity for AI agents on MySQL

Picture the end-state first. Every AI agent that touches your MySQL database is a named principal with its own access policy, its own recorded sessions, and its own scope. No agent shares a login with another agent or with a human. When something runs a query, you know exactly which agent it was, because the identity is attached at the connection, not guessed from an IP. That is what non-human identity for AI agents on MySQL looks like when it is done right.

Most deployments start far from that. The agent reads a MySQL username and password from an environment variable, the same pair a human service uses, and that shared credential becomes the agent's whole identity. Non-human identity is the work of replacing that shared secret with a distinct, governed principal for each agent.

The end-state in concrete terms

• Each agent authenticates as itself, separate from humans and from other agents.
• Access is scoped to what the agent's task needs, not the full grant of a shared user.
• Every session is attributed to that identity, so audit and recording are meaningful.
• The agent never holds the raw MySQL credential, so rotating or revoking it does not require touching agent code.

Why a shared MySQL user fails as identity

A MySQL user is a database object, not an identity system. When several agents share one, the database cannot tell them apart, access is the union of everything any of them needs, and revoking one agent means rotating a secret that breaks the others. The identity has to live above the database user, on the connection, where it can map many distinct principals onto the access MySQL understands.

How to reach the end-state

hoop.dev is an open-source Layer 7 gateway that proxies the MySQL wire protocol. It authenticates each connecting identity through your OIDC or SAML provider and authorizes the session before it opens MySQL. The agent presents its own identity to hoop.dev; hoop.dev reaches MySQL with the connection-configured credential as the session principal. The agent's identity stays distinct end to end, while the database still sees a credential it understands.

1. Register the MySQL connection in hoop.dev with HOST, PORT, USER, PASS, and DB. This credential lives in the gateway.
2. Create a distinct identity for the agent rather than handing it the shared database password.
3. Bind an access policy to that identity: which connections it may use and which operations need approval.
4. Point the agent at the hoop.dev endpoint so it authenticates as itself.
5. Verify that recorded sessions show the agent's identity, not a generic MySQL user.

Pitfalls on the way there

• Re-using a human's credential for an agent. It muddies every audit record and makes least privilege impossible.
• Treating an API key as identity. A bare key with no policy or attribution is a secret, not a principal.
• Skipping revocation design. A real identity can be revoked at the gateway without breaking other agents.

The reason non-human identity is worth the effort shows up in every other control. Recording is only useful if it names who acted. Least privilege only means something if access is scoped to a principal rather than a shared secret. Approval workflows need to know whose request they are holding. All of them assume each agent is a distinct, durable identity. Get that foundation right and the rest of the controls have something solid to attach to. Skip it, and they all blur back into one anonymous database user.

FAQ

Does the agent get its own MySQL user?

It gets its own identity at the gateway. hoop.dev maps that identity to the connection-configured MySQL credential, so you manage principals in one place instead of minting a database user per agent.

How does revocation work?

Revoke the agent's identity in the gateway. Because the agent never held the database password, no rotation or code change is needed to cut it off.

Does RDS change this?

RDS MySQL connections can use per-user IAM auth on the web-app path, which strengthens the link between the gateway identity and the database session.

To go deeper, see least-privilege access for the same agent and the wider model for agent access. Run the gateway yourself: hoop.dev on GitHub.