SQL Copilot shows why an approval prompt cannot limit database access

The short version

A database assistant can promise to behave carefully while using an account that can change far more than the task requires. Those are two different controls. One concerns the assistant's choices. The other concerns what the database will allow.

In his September 30 research thread, Johann Rehberger examines the read-only restrictions of SQL Copilot in SQL Server Management Studio, or SSMS. His technical writeup reports that Microsoft patched the issue. This is a disclosed research demonstration, not evidence here of an attack against a business.

We recommend reviewing the account behind any database assistant before expanding a pilot. Asking a person to approve a query can help catch a mistake. It cannot replace a database rule that refuses an action the account should never perform.

The idea in plain terms

Think of an assistant helping an analyst answer a sales question. It reads descriptions, writes a query and asks whether to run it. The analyst may see an ordinary business request. The software still needs to answer a separate question: whose access rights will that query use?

Least privilege means granting only the rights needed for the task. For a sales report, that might mean reading approved tables without changing customer records. This is a design choice enforced by the database, rather than an instruction asking the model to show restraint.

Rehberger's writeup describes two linked weaknesses: bypassing a read-only classifier and using database metadata to steer a more privileged user's assistant. Metadata is information stored about database objects. In the demonstration, attacker-controlled instructions in that information were consumed during a later session. The reported outcome was an increase in the attacker's privileges.

This is indirect prompt injection: instructions arrive through material the assistant reads, rather than through the user's request. We reviewed the research text, not an independently reproduced exploit. We omit its payloads and do not infer that every current installation remains vulnerable.

The general engineering question is still useful after a patch: when the assistant encounters hostile or mistaken material, which actions remain impossible because its account lacks permission?

Where it came from

The current Microsoft execution-context guide, updated September 28, states that Copilot normally executes with the connected user's permissions. It says the Agent mode approval system confirms intent but does not form a security boundary. SQL Server's permission checks provide that boundary.

The guide also describes a dedicated execution identity set through agentExecuteAsUser in a database's CONSTITUTION.md. That setting chooses the account used for queries. The required permission to act as that account must be granted explicitly; without it, the feature fails rather than silently using the connected user's broader rights.

These are documented product behaviors, not results from our own test. For a team, the next step is to confirm them in its installed version and configuration. We could not read the Microsoft security advisory's detailed version table during this review. We therefore give no claimed first-fixed version. Follow the vendor's update guidance and verify the deployed build with your administrator.

How it connects to other work

Microsoft's administrative-controls guide, also updated September 28, documents options to disable Copilot, disable Agent mode, and configure a dedicated execution account. Availability depends on the installed SSMS version. These options give teams several ways to stage access rather than making one all-or-nothing rollout decision.

Our proposed review separates three questions. First, what information can influence the assistant? Second, what identity executes its proposed action? Third, what does the database allow that identity to do? A good answer to one question does not settle the others.

For example, a team might restrict which documents the assistant reads yet still connect it with an administrator account. Another might use a narrow account but let it query sensitive payroll data. In each hypothetical case, a different control needs attention. A prompt warning alone does not explain the full design.

We recommend recording those answers in the same change review. Name the owner of the instruction metadata. Name the execution account. List its permitted objects and operations. State what happens if configuration is absent or invalid. Then check the answers against observed behavior in a test database.

That record also helps after an update. A release can change a default, while an old assumption survives in a runbook. Reviewing the actual identity and effective rights makes the rollout decision depend on current behavior. It also gives an incident responder a concrete place to start, rather than only a chat transcript.

Open questions

Does a dedicated account have hidden routes to broader access? Review the operations it can invoke, not just its visible table permissions. Ask a database specialist to check inherited rights and callable routines. This is our defensive recommendation; we have not inspected any reader's environment.

Who can change the stored instructions? Treat that ownership as part of the access review. A harmless naming convention and a change to execution settings should not receive the same casual review merely because both appear in a Markdown field.

How will you prove the restriction works? In a disposable test database, compare an allowed report query with a prohibited change. Record whether the database rejects the prohibited operation. Do not use the absence of a bad suggestion as proof that enforcement exists.

The patch addresses the reported case. It does not establish that every possible agent workflow is safe, and this article does not claim it does. The narrower goal is a review that shows where authority is granted and where unwanted actions are denied.

What this means for your work

For business and technology leaders

A reporting pilot may need a separate account and a database review before it reaches production. For example, sales staff should not have to open an assistant with broad admin rights just to get a weekly report. We recommend asking the pilot owner to show which data it can read and which changes it cannot make. This week, make that evidence part of the rollout decision. Budget for the review as well as the assistant license.

For full-stack developers

Check the identity at the point where your tool runs a query. In a sales dashboard, a read-only report should use rights that deny record changes even if the assistant asks for one. We recommend adding one test in a disposable database that attempts a prohibited change through the same execution path. Assert that the database rejects it, and record the effective account. That proves a specific restriction under the tested settings, not safety for every request.

Sources

• SQL Copilot read-only restrictions — Johann Rehberger, X research thread, September 30, 2026; captured in the bounded intake.
• Research writeup — Johann Rehberger, primary research blog, September 30, 2026; researcher reports Microsoft patched the demonstrated issue.
• Execution context — Microsoft Learn, official documentation, updated September 28, 2026.
• Admin controls — Microsoft Learn, official documentation, updated September 28, 2026.