SSMS Copilot：資料庫指示繞過唯讀檢查，讓 db_owner 取得 sysadmin 權限

使用獨立 SQL 連線，由伺服器權限嚴格限制僅能執行任務所需的查詢動作，明確拒絕變更角色成員、危險預存程序及模擬高權限身分，並以該連線實際測試確認各項操作皆遭資料庫引擎拒絕。指引 G001 的單一用途工具與後端唯讀角色正適用於此，但需配合 SQL Server 的權限模型實作。攻擊者若具備 db_owner 權限，便能直接修改或刪除憲章，導致系統退回原連線權限，因此單靠 agentExecuteAsUser 不能取代真正的低權限登入。備份驗證操作亦應限縮為單一用途且參數受限的介面，並以缺乏任意 SQL 執行權限、權限變更與對外連線能力的專用帳號執行。在未修改的 SSMS 原生環境中，目前可立即落實的做法是改採低權限連線或停用 Copilot；若要替換內建工具則需等待廠商更新。防守方應分別測試備份與資料讀取工具，確認所有未授權操作皆確實遭到阻擋。

完整盤點企業內部實際執行的 SSMS 執行檔，依微軟發布的漏洞紀錄找出受影響版本，並全面部署 22.8.2 或更新的受支援版本，接著確認實際執行中的版本並進行動態 SQL 繞過的負向測試。僅下載安裝程式不代表全企業端點已完成修補。對於暫時無法升級的主機，應透過集中管理控制項停用 Copilot，直到風險完全排除，且這項補償性控制本身亦須能獨立讀回驗證。

日常使用 SSMS 的登入帳號，不應該同時持有 sysadmin；只要那條連線能授予伺服器角色，中繼資料裡的指示就能借它把攻擊者加進 sysadmin。會用 Copilot 的管理員平常應該用低權限登入，需要伺服器層級權限時，改透過 PAM 或 just-in-time 角色指派，開一個有時限、有申請理由、且不開啟 Copilot agent 模式的獨立工作階段。另外要定期重新確認哪些帳號握有 sysadmin 與 db_owner。這項控制管的是人的身分與權限；Copilot 工具連線本身的邊界由 AID-H-017.002 負責。

CONSTITUTION.md 與 AGENTS.md 這兩種延伸屬性，應該當成受治理的 agent 指示來源來管，而不是順手寫的說明文件。先建立一份清單，列出哪些資料庫與物件被允許放 Copilot 指示、擁有者是誰、信任層級為何、核准的內容是什麼，再定期雙向比對實際存在的延伸屬性；沒列在清單上或內容被改過的指示，就是一筆要處理的發現。同時配合權限審查，只讓指定擁有者持有能寫入這些屬性的 ALTER 或 db_owner 權限。這能縮小能植入指示的人選、讓多出來的指示現形；不過它擋不住一個合法 db_owner 自己寫入，所以真正決定結果的仍是 AID-H-017.002 的執行邊界。

Copilot 存在資料庫裡的設定一被改動，就要有人知道。定期把實際生效的 CONSTITUTION.md 與 AGENTS.md 延伸屬性和核准版本比對，並用 SQL Server Audit 或 DDL 觸發程序記錄每一次針對這些屬性的 sp_addextendedproperty、sp_updateextendedproperty 呼叫，連同執行者、時間與新內容一起留存；這樣植入的指示會在下一位管理員開啟 Copilot 之前就先變成一筆偵測發現。上游公開的作法範例是 GitOps 與 Kubernetes 環境，這裡需要改寫成 SQL Server 的實作。這是偵測而不是預防，只有在受害者連線執行之前有人處理這筆發現，它才真的幫得上忙。