The riskiest line in many AI agent deployments is a connection string to the production MySQL primary, sitting in an environment variable, with a user that can write. The agent uses it for one nightly job, and it holds it the other twenty-three hours too. Production access control for AI agents on MySQL is about closing that gap: turning a standing, always-on grant into access that is scoped to a task, recorded, and gone when the task ends.
Standing access and scoped access are not two settings of the same thing. One leaves a privileged door open and trusts the agent to behave. The other opens the door per task, watches what happens, and closes it. For a production database, the second is the only model that survives a bad day.
What production access control has to cover
For an agent reaching production MySQL, control means four things working together: a named identity for the agent, access that opens just in time, sensitive operations routed for human approval, and every session recorded outside the database. Drop any one and the model leaks. Identity without recording cannot be audited. Recording without scoped access is one endless stream. Approval without identity cannot say who asked.
The reason these belong together is that they are one boundary, not a checklist you assemble from separate tools. The agent should meet a single access surface, and that surface should enforce all four at once.
Where the boundary sits
hoop.dev is an open-source Layer 7 gateway that proxies the MySQL wire protocol through an agent inside your network. The AI agent connects to hoop.dev, which authenticates its identity, authorizes the session, opens production MySQL just in time, records every statement, and can hold a risky operation for approval before it runs. The architectural requirement for production is that the control plane sits outside the process the agent drives. A boundary the agent can reconfigure is not protecting production; it is asking the agent nicely.
Set up production access control step by step
- Register the production MySQL connection in hoop.dev with
HOST, PORT, USER, PASS, and DB. The gateway holds this credential. - Give the agent its own identity, separate from humans and other agents.
- Set a policy that opens access per task and routes writes or destructive statements for approval.
- Confirm session recording is on so each production action is attributable.
- Point the agent at the gateway endpoint, run a task, and verify the connection closed and the session was recorded under the agent's identity.
Verify production is actually scoped
Check MySQL's process list after a task. No lingering agent connection means access really closed. Then attempt a write the policy should hold and confirm it routes for approval instead of executing. If both pass, the boundary is doing its job.
Do this verification against production specifically, not just staging. Configurations drift, and the connection that matters most is the one pointed at the primary. A useful habit is to re-run the two negative tests, the lingering-connection check and the held-write check, on a schedule, so a policy that quietly loosened gets caught before an agent does something you cannot take back. On production the cost of a missed control is not a quarantined post; it is a row you cannot restore.
Pitfalls
- One credential for prod and everything else. Scope the connection to production with its own least-privilege user.
- Auto-approving writes. On production, default destructive operations to human approval.
- No identity on the agent. A shared login makes every other control weaker.
FAQ
Why not just use a MySQL user with limited grants?
Grants cover what an account can do but not when it has access, who is behind it, or whether the action was recorded. Production access control adds identity, just-in-time scoping, approval, and recording around the connection.
Does approval slow the agent down?
Only for the operations you mark sensitive. Routine reads run normally; a destructive write waits for a human, which is the point on production.
Does this work for RDS MySQL?
Yes. RDS connections can use per-user IAM auth on the web-app path, and the same scoping, recording, and approval apply.
See how session recording captures each production task and the broader model for governing agent access. Run the gateway against a staging MySQL instance first: hoop.dev on GitHub.
