For most developers, AI in database work has meant one thing so far: typing less. You describe what you need, a model drafts the SQL and you decide what to keep. The tool got smarter every year, but the shape of the job stayed the same. You were still the one who pressed Run.
Agentic AI changes the shape of the job. An agent can inspect a schema, execute a query, read the result and decide what to do next on its own. The question in front of database teams is no longer whether AI can write good SQL. It clearly can. The question is how much of the decision to run that SQL we are prepared to hand over, and who answers for the outcome when we do.
That makes this a design conversation about authority, not about models.
The control nobody designed
Look back at the assistant era and something stands out. The most effective safety mechanism in AI-assisted SQL was never a feature. It was a habit. A person read the output before it touched the database, and that single step absorbed most of the risk.
Because it was a habit, it is easy to lose without noticing. Give an agent execution rights and the step simply disappears. Nothing breaks on day one. The system just becomes faster and less supervised at the same time.
That is why "can the agent do this?" is the wrong first question. The better one is "what did the human review step used to protect us from, and where does that protection live now?"
Same SQL, different owner
The SQL an agent runs is often identical to what an assistant would have suggested. An agent that spots a slow query might create an index, rerun the workload and confirm the gain, exactly as a developer would.
The difference is not the statement. It is who owns the judgment behind it. A developer weighs a change against things that never appear in a query plan: which services depend on that table, what the write load looks like at peak, whether a deployment freeze is in effect. An agent sees what it has access to, and that is usually less than it seems.
So a technically reasonable decision can still be wrong for the environment. Because agents act in sequences, small misjudgments compound. A slow read is a nuisance. A loosely scoped update or an unexpected schema change is an incident.
Databases encode business decisions
This is where database work differs from most of what AI coding tools are optimized for. Application code expresses logic. Databases also hold obligations.
Consider the kind of cleanup an agent might reasonably propose:
DELETE FROM AuditLog
WHERE CreatedAt < DATEADD(year, -2, GETDATE());
The statement is valid. Whether it is acceptable depends on facts no schema records: a regulatory retention period, an application that still reads those rows, a requirement to archive before deleting, an operational need to run the change in batches.
Treating database development purely as a code-generation problem misses this. Many database operations are business decisions wearing technical clothing. A model can master the technical part and still have no way of knowing the business part. That is not a flaw a better prompt will fix. It is a boundary to design around.
Authority is an architecture concern
Agent permissions therefore belong in the same conversation as schema design and deployment strategy, not in a config file someone edits on a Friday afternoon.
A few principles follow:
- Separate seeing from doing. Most of an agent's value comes from reading: explaining plans, spotting inefficient indexes, reviewing dependencies, diagnosing errors. Broad visibility and broad execution rights are two different decisions and should be made separately.
- Agents are principals, not proxies. Letting an agent run under the developer who launched it is the most convenient setup and the least defensible one. An agent should have its own identity, scoped to its job, exactly as a service account would. OWASP calls the opposite pattern "excessive agency" and treats it as a core risk for LLM applications.
- Human approval is part of the system. For destructive DDL, production data changes, permission changes and large migrations, a review step is not friction slowing the agent down. It is the component that carries accountability.
A workflow that reflects this looks something like Observe → Analyze → Propose → Review → Execute → Validate → Record. The agent can do almost all of it, including testing a change in staging and measuring the result. What it does not do is promote a high-impact change to production on its own judgment.
Autonomy should be earned in stages
None of this argues for keeping agents permanently read-only. It argues for sequencing. Start with explanation and analysis. Let agents make changes in development and staging. Introduce production write access later, with clear limits on affected rows, transaction boundaries, rollback, monitoring and approval. Keep fully autonomous production changes rare.
Most organizations are still early on this curve. McKinsey's 2025 State of AI survey found that no more than 10% of respondents reported scaling AI agents in any given business function. Gartner, meanwhile, expects more than 40% of agentic AI projects to be canceled by the end of 2027, with inadequate risk controls among the reasons. The teams that scale agents successfully are likely to be the ones that built the controls first and granted the permissions second.
What this means for developers
If agents take on more of the repetitive work, the developer's role shifts rather than shrinks. The valuable skills move toward:
- reviewing AI-proposed changes with the same rigor as a teammate's pull request
- making implicit context explicit, so that retention rules, dependencies and constraints are written down somewhere an agent or a reviewer can find them
- defining the boundaries of agent authority deliberately instead of inheriting them by default
- owning the outcome of every high-impact change, regardless of who drafted it
The tools worth adopting are the ones that support this division of labor rather than blur it. dbForge AI Assistant is one example of that design. It works inside dbForge tools from database metadata rather than table data to generate, explain, optimize and troubleshoot SQL, and it returns the result to the developer to review and run.
The question worth asking
The most useful database agent will not be the one allowed to do the most. It will be the one whose authority the whole team understands: what it can see, what it can change, under which identity and who signs off.
So the conversation to have with your team is not "should we let AI run queries?" It is "which queries, under what constraints and with whose approval?" Teams that answer that clearly will get the productivity of agents without giving up the judgment that keeps databases trustworthy.
How is your team drawing that line today? Share where you have set the boundary in the comments.
For a deeper look at this topic, read "Agentic AI Meets Database Development: What Changes When AI Can Actually Execute Queries" by Victor Horlenko, Head of AI Innovations at Devart, published on Unite.AI.
Top comments (0)