Agents will touch your database. Decide how they are allowed to.
Coding assistants, internal copilots and automation scripts are being handed database access every week, and almost never the narrow kind. A token is pasted in to unblock a task and never rotated. A role is granted for one afternoon and kept for a year. A tool is pointed at the wrong environment. The agent is not malicious it is fast, capable and certain, and it has no idea which table your business runs on.
How access gets wider than anyone intended
None of these are careless. They are what happens when useful tools meet credentials that were never scoped for them.
Permissions granted in a hurry
Someone widens a role so an agent can finish a task on Friday. The task ends, the access does not. Nobody is reviewing which non-human identity still holds write on production.
A credential in a config file
Agents run where developers run: a laptop, a runner, a container image. A connection string that reaches production from any of those is a connection string the organisation no longer controls.
The wrong environment
The command was right and the target was not. Without a gate, the difference between staging and production is one value in a config the agent read three steps ago.
Confident and wrong
A model produces a migration that looks reasonable and drops a column three services still read. It will not hesitate, and the database has no way to ask whether anyone meant it.
Keep the speed. Put a person on the last step.
Blocking agents is not the answer, and it does not hold: the work moves to whoever still has a direct login. The answer is that reaching a protected environment stops being something anyone human or agent can do alone.
You choose which environments need approval and how many. Production waits until those approvals exist, and each one is a decision recorded against the person who made it, with the time and the change it applies to. An agent can prepare the change and argue for it. It does not get to decide that it is safe.
Roles are granted per environment, not across the estate, and production defaults to read-only. The same identity can be free to work on DEV and unable to write a row on production, which is the shape you want long before an agent is in the picture.
Risk analysis runs against the change and your application repositories before the approval, so the person deciding sees the destructive statements and the code that still names those objects. Approval stops being a rubber stamp on SQL nobody read.
Every action lands in a hash-chained ledger: what ran, on which environment, who was behind it, and when. "The agent did it" becomes a record with a person's name attached rather than the end of the investigation.
It does not matter which tool your team picked
Coding assistants
An assistant that writes a migration hands it to the same path as a person: reviewed, risk-analysed, approved, promoted with a rollback ready.
Internal copilots
A support copilot that needs to read customer data reads it through Explorer, under the roles of the person asking, with every query attributed.
Automation you already run
Scripts and pipelines drive the same objects through the API. Anything that changes state needs an explicit confirmation, so nothing promotes because a job guessed the next step.