When AI Agents Execute SQL: A Framework for Controlled Autonomy

For the last few years, AI help with databases has followed a comfortable routine. You describe a requirement, the model writes the SQL, you read it, fix what looks off and decide whether to run it.

That routine has protected one important boundary. AI could propose an action, but a person decided whether it ever reached the database.

Agentic AI is erasing that boundary. Agents can now inspect schemas, run queries, interpret results and choose their next step without stopping to ask. In McKinsey's 2025 State of AI survey, 23% of respondents said their organizations were already scaling an agentic AI system somewhere in the enterprise, and a further 39% were experimenting with agents.

So database teams face a practical design question. It is not whether AI can execute SQL. It can. The question is what changes when an assistant stops suggesting code and starts acting on the database, and how tightly that autonomy should be controlled.

Suggestion vs. action: one index tells the story

An agent notices a slow query, checks the schema, decides an index would help, creates it and reruns the workload. The statement itself is ordinary:

CREATE INDEX IX_Orders_CustomerId
ON Orders(CustomerId);

Any AI assistant could have suggested that line. What differs is who makes the final call. With an assistant, the developer reviews, tests and decides. With an agent that holds execution rights, the system decides and moves on.

When the agent is right, everything gets faster. But agents rarely have the full picture. They can miss application dependencies, business rules, workload patterns and maintenance windows that are obvious to the people who run the system. The result is a decision that looks technically sound and is still wrong for that environment.

The risk grows as actions chain together. A bad SELECT just runs slowly. A bad UPDATE can lock a large table or touch far more rows than intended. An index that helps one query can add overhead to many others. A schema change can break something the agent never knew depended on it.

Agents can make good database decisions. Once they act on them, teams need to be explicit about how far that authority extends, what context the agent sees, where a human steps in and who stays accountable. Gartner expects more than 40% of agentic AI projects to be canceled by the end of 2027, partly because of inadequate risk controls. My takeaway for database teams is simple: grant execution rights after the controls are in place, not before.

What you can safely delegate

Query analysis is the clearest example of work that is safe to hand over. An agent can read query statistics, pull execution plans, inspect indexes and table structures and recommend fixes without changing a single row.

Suppose it sees this query scanning a large Orders table again and again:

SELECT OrderId, OrderDate, Total
FROM Orders
WHERE CustomerId = @CustomerId
ORDER BY OrderDate DESC;

It can explain the scan, recommend an index and generate the DDL. It does not need permission to run CREATE INDEX to be useful. The same applies to:

• explaining execution plans
• finding missing or unnecessary indexes
• flagging SELECT * queries and non-sargable predicates
• reviewing joins and filter pushdown
• reviewing schemas and dependencies
• troubleshooting SQL errors
• optimizing SQL scripts

Give the agent enough access to understand the problem, not automatic access to change the database. Visibility and execution rights are separate decisions.

Where a human still has to decide

Now imagine the agent finds an AuditLog table with hundreds of millions of rows and concludes that old records should go:

DELETE FROM AuditLog
WHERE CreatedAt < DATEADD(year, -2, GETDATE());

The SQL is valid. The decision could be a disaster. Regulation may require seven years of retention. An application may still rely on those records. The deletion may need to run in batches to keep the transaction log in check, or the data may need to be archived first. None of that necessarily lives in the schema.

This is where treating database work as pure code generation falls short: databases hold technical structures, but the decisions around them are often business decisions carried out through technical operations. The same caution applies to:

• DROP and destructive ALTER statements
• production UPDATE and DELETE operations
• large data migrations
• role and permission changes
• constraint modifications
• changes that affect replication or availability
• deploying stored procedures that contain business logic

A technically correct action is not automatically an appropriate one. For high-impact operations, human approval is not a limitation on agentic AI. It is part of the architecture.

Least privilege applies to agents too

One shortcut to avoid is letting an agent reuse a developer's credentials. It is easy, and it hands the agent everything that developer can do.

The safer path is the one we already use for people and services. Microsoft's SQL Server security guidance recommends granting only the permissions a task requires. A performance-analysis agent might need:

CONNECT
SELECT
VIEW DATABASE STATE
VIEW DEFINITION

It almost certainly does not need CONTROL on the database, db_owner or sysadmin.

Different agents can also carry different identities. A reporting agent might get SELECT on a few schemas. A migration agent might work only in development or staging. A production agent might hold narrowly scoped permissions and still need approval before it executes anything. OWASP's guidance on AI agents points the same way: least privilege, limited tools and approval for dangerous operations.

Put simply, give the agent the permissions its job needs, not the permissions of the person who started it.

Design the human into the workflow

A sounder model for agentic database work is a controlled workflow:

Observe → Analyze → Propose → Review → Execute → Validate → Record

Picture an agent investigating a slow API endpoint. It finds the SQL, checks the plan, spots a likely missing index, tests a migration in staging and prepares the production change.

Then it stops. A developer or DBA checks dependencies and business impact and approves the change before it reaches production. The agent does the repetitive work. The human keeps final responsibility.

Transaction controls add another layer. PostgreSQL savepoints, for instance, let you roll back part of a transaction without losing everything before it. That helps with tightly bound automated changes, but rollback is never a substitute for proper permissions and approval.

This is also the design principle behind dbForge AI Assistant. It uses database metadata as context to generate and explain SQL, troubleshoot errors, flag inefficient indexes and prepare optimization scripts, while keeping the resulting SQL in front of the developer for review.

Controlled autonomy is the real goal

Agentic AI does not force a choice between "AI only suggests" and "AI runs the database." There is a lot of room in between.

Start with lower-risk work such as explaining SQL, reviewing schemas and read-only checks. Expand into development and staging over time. Add write access much later, with clear limits on affected rows, transactions, rollback, monitoring and approvals. Fully autonomous changes in production should stay rare.

McKinsey found that while 88% of organizations used AI in 2025, only 7% said it had been fully scaled across the organization. Capability is not the bottleneck. Dependability is.

Database development is heading the same way. The most useful agent will not be the one allowed to do the most. It will be the one whose authority is clearly understood and controlled. The question is no longer whether AI can execute database tasks, but which ones we should trust it with and under what constraints.

A version of this article was first published on Unite.AI.