# The Database Note That Copilot Read SQL Copilot's instruction metadata got me thinking about who can leave notes for an agent, and whose permissions it has when it acts on them. Published: 2026-10-09 A note attached to a database table sounds useful. Explain the columns, mention a few awkward naming conventions, and save the next person some time. Give that note to an agent and it takes on another role. It can influence what the agent does next, including actions performed using somebody else's database connection. That is the detail that stayed with me after reading Johann Rehberger's SQL Copilot research. I can see why a team would want instructions close to the data. I would also want to know who can edit them before giving the agent a connection with much more authority. ## A few details from the research Rehberger describes Copilot in SQL Server Management Studio using the connected user's database privileges. Its read-only classifier could be bypassed through indirect stored-procedure execution; another backup-verification tool also accepted arbitrary SQL. He demonstrated outbound data transfer using `xp_dirtree`. The instruction channel was database metadata: extended properties named `AGENTS.md` and `CONSTITUTION.md`, which Copilot incorporated into context. Object-level `ALTER` permission could allow someone to attach an `AGENTS.md` property. His final demonstration used a database owner planting a constitution, a more privileged victim's Copilot session, and the execution bypass to add the attacker to sysadmin. Those are distinct observations. The final privilege-escalation chain should not be described as demonstrated from object-level `ALTER` alone. His September 30 account associates the research with CVE-2026-65669 and reports Microsoft's critical rating. I could not independently retrieve Microsoft's affected-version details, so I would use the vendor advisory to select remediation rather than infer a fixed build from this article. [Read the research and demonstrations](https://embracethered.com/blog/posts/2026/from-select-to-sysadmin-sql-copilot-bluehat-asia/). ## The instructions are close to the data There is an appealing design idea here. Database guidance can travel with the objects it describes instead of sitting in a document someone has to remember to find. An agent can learn that a column is deprecated, that a timestamp has an unusual meaning, or that a particular relationship needs care. The difficulty is that permission to describe an object and permission to direct a privileged session are different responsibilities. A person may reasonably be allowed to maintain a table's documentation without being allowed to change server-wide access. Once the agent reads that documentation as instructions, the two responsibilities become connected. I would want the design review to make that connection explicit. For an agent with access to a data store, I would sketch three parts on the same page: where its guidance comes from, who can change that guidance, and the identity used for each tool call. That sketch can reveal a relationship that neither the database permission review nor the agent prompt review catches on its own. This feels like a useful continuation of [the Azure DevOps MCP case](/blog/detecting-the-confused-deputy-in-azure-devops-mcp/). A pull-request comment was one entry point. A supported, persistent instruction store creates another, and it may be less conspicuous because the feature is supposed to influence the agent. ## I would start with the connection If I were helping a team introduce a database assistant, I would ask to see the identity it actually uses for execution. The answer should be visible in a database session or audit record, rather than inferred from the assistant's description of its mode. A dedicated account with narrowly granted access makes the intended limits easier to inspect. It still needs a permission review. Read access can expose sensitive data, and procedure execution can have effects that are easy to overlook when looking only at table permissions. Microsoft's current documentation describes a dedicated execution context in SSMS 22.7 and later, along with controls to disable Agent mode and govern MCP servers. The execution context is specified through `CONSTITUTION.md`. That makes the permissions around configuration worth reviewing too. These are documented administrative options, not an independently verified patch prescription for this CVE. [Microsoft's administrative controls](https://learn.microsoft.com/en-us/ssms/github-copilot/admin-controls). I would test the account's effective permissions directly, including inherited roles, procedure grants, access to other databases, and outbound network behavior relevant to the workload. Then I would test the same limits through the assistant. Both views are useful: one describes the database authority, and the other exercises the integration that uses it. ## A harmless note makes a useful first test A small experiment can establish whether the instruction channel is active without starting with destructive SQL. In a disposable database, I would give one test user the intended metadata-editing permission and another the intended assistant execution context. I would attach a harmless instruction asking for a distinctive phrase, then observe whether it appears when the assistant examines the object. That result would show influence over the response. It would not prove influence over a privileged action. For that next question, I would use a harmless operation against a synthetic object that the execution account should be unable to modify, and keep the database-side record of the attempted operation and denial. I would also check whether a metadata editor can alter execution-context settings, whether guidance is cached, and how a corrected or removed instruction reaches an existing session. These are proposed tests. I have not run them against SQL Copilot. The practical value is in finding out which user can influence which session, and whether the underlying permissions still hold when that session receives unwanted instructions. ## What I would want in the logs Instruction changes deserve enough history to investigate later: object, property name, writer identity, time, and a version or digest. Whether the text itself should be retained depends on its sensitivity and the logging policy. I would then try to connect that record with the agent session, execution identity, actual SQL operations, and relevant network activity. A suspicious phrase in metadata is a reason to look. A role change or unexpected outbound connection provides different evidence about what happened. Dynamic SQL by itself would be a noisy alert. Many applications use it legitimately. My proposed detection would need context such as a recent instruction-property change, an assistant session, and an operation outside its usual purpose. I would validate the available log fields and timing before treating that as a deployable rule. This is similar to the provenance problem in [Telemetry Is an Instruction Channel](/blog/telemetry-is-an-instruction-channel/). An investigation gets much harder if the system records only the final tool call and loses the material that influenced it. ## Keeping the useful part I would still like an assistant to understand the quirks of a database. Good documentation saves time, and keeping it near the schema can make it easier to maintain. What I would change is the review around that feature. Instruction authorship, execution configuration, and effective database permissions belong in the same conversation. The person maintaining table notes should know whether those notes can influence a more privileged session, and the person enabling the assistant should be able to see who can change them. That is the question I would take into the next agent design review: who gets to leave it a note, and whose access is available when it reads it?