--- title: AI 代理對自己的操作說了「不行」——AI 護欄與三層治理，DB 遷移中被攔下兩次的實錄 description: 將伺服器實際作業交給 AI 代理後，安全機制（護欄）在執行前兩次攔下危險操作。它是守門人，還是統制的極限？以實例談事前原則×承認關卡×護欄的三層治理與稽核日誌運用。 url: "https://bestnetllc.co.jp/zh-hant/docs/ai-agent-guardrails-three-layer-governance-tw/" updated: "2026-06-27" category: Tech Blog --- # AI 代理對自己的操作說了「不行」——AI 護欄與三層治理，DB 遷移中被攔下兩次的實錄 BESTNET TECH BLOG AI 代理對自己的操作說了「不行」 AI 護欄與三層治理 ― DB 遷移中被攔下兩次的實錄 作者: Hideyuki Chinda / BESTNET LLC2026-06-13系列 治理番外篇 把伺服器上的實際作業交給 AI 編碼代理。讓它轉換結構描述、搭建驗證環境、執行測試——這樣的用法已逐漸變得實際可行。如此一來，自然會浮現這樣的不安：「萬一 AI 做出了不該做的操作怎麼辦？」 本系列正篇報告了將 Oracle 至 SQL Server 的遷移前處理，在不交付實際資料的前提下以 AI 代理（Claude Code）自動化的實踐。本篇要談的是其中發生的、原本不在計畫內的事件。**作業途中，AI 代理端的安全機制（護欄）在執行前兩次攔下了 AI 自己的操作**。 本篇旨在從「治理的觀點」深入剖析這兩起事件。這些事件發生時作業的技術幕後（在 SSH 非互動化、字元編碼、PowerShell/T-SQL 的「接縫」處所踩的 10 個坑），則分篇於[技術番外篇「把 Windows 實機作業交給 AI 代理所踩的 10 個坑」](https://bestnetllc.co.jp/zh-hant/docs/ai-agent-windows-sqlserver-pitfalls-tw/)。 這乍看像是「AI 不聽話」的麻煩。然而回頭來看，這是對思考治理深具啟發的事件。我會盡量誠實地從正反兩面書寫。先聲明在前：此處作動的，是特定 AI 代理實作所具備的安全判斷，並不保證在其他工具、模型或版本上同樣的操作也會被攔下（這種非確定性將於第 4 章詳述）。 > 本篇所談的作業對象，是未對網際網路公開的自家驗證專用環境。不含正式系統或客戶環境。 --- ## 1. 兩次，被攔了下來 推進作業的是 AI 代理。人類（我們）則退居承認方針並進行審查的一方。那個 AI 為了優先效率而打算採取的手段，兩次都在執行前被彈了回來。 ### 案例 1：削弱安全設定的執行方式 為了調查環境，AI 試圖以**暫時削弱執行原則的方式**（相當於 PowerShell 的 `-ExecutionPolicy Bypass`）來執行調查指令稿。即便目的是讀取，這仍是繞過保護機制的操作。 此時護欄將其作為「削弱安全的操作」加以拒絕。AI 並未去尋找規避手段，而是察覺到**原本就沒有削弱的必要**。在目標環境的預設設定（`RemoteSigned`）下指令稿即可執行，並無觸碰原則的理由。結果，AI 切換到更安全的方法後繼續前進。 ### 案例 2：將認證資訊寫入檔案 在產品安裝的自動化中，AI 起初試圖以混合模式驗證（使用 `sa` 帳戶的方式）安裝 SQL Server，並打算把該 `sa` 的密碼直接寫入指令稿檔案後傳送。 此時護欄同樣將其作為「認證資訊外洩」加以拒絕。這正是與作業開始前人類所訂原則「不可將憑證永久保存於程式碼、檔案中」正面牴觸的操作。AI 轉換方針，放棄混合模式，改採僅使用 Windows 整合驗證的組態（不建立 `sa`，也不建立其密碼）。結果，達成了在成果物、指令稿、紀錄中任何一處都不殘留機密資訊的組態。 兩起事件的共通點在於：都是在執行前被攔下，而且在被攔下之後，組態都朝更安全的方向前進。 --- ## 2. 為何能稱之為「守門人」 值得注意的是，這兩次攔阻**都與人類在開頭所固定的原則相一致**。 案例 2 正是「不將憑證永久保存」這條明文原則本身。案例 1 也是「不隨意削弱保護機制」這條雖未特意寫下、卻一直作為前提的界線。 換言之，護欄並非作為妨礙作業的障礙物，而是作為**人類所訂設計原則的「守門人」**而運作。而且不只是單純地攔阻，更因為被攔下，組態才得以倒向安全側。最初並未選擇的、更為堅固的設計——「一開始就不建立機密資訊」——結果上反而抵達了。 --- ## 3. 另一種讀法 — 同一事件也是「AI 提出了高風險建議」的佐證 若就此打住，這會變成一篇對 AI 護欄歌功頌德的文章。我誠實地把它翻過來看。 被攔下兩次，意味著即便事先讓 AI 讀入了原則，AI 仍兩次嘗試了違反原則的操作。 這不該視為個別的設定失誤，而應理解為現階段 AI 委派所內在的性質。AI 代理（不論模型）都可能為了優先效率而提出違反原則的手段。正因如此，才要在第 1 層（事前原則）劃下界線，並在第 3 層（護欄）為漏網之魚預作準備——這次正如該設計，違規的嘗試在執行前被偵測到了。話雖如此，若沒有護欄，或在別的模型、別的版本上判斷不同，那個操作或許就會照樣執行了。 這兩面性，若只看其中一面便會誤判。 - 只看樂觀面：「有安全機制，把事情交給 AI 就沒問題」→ 對護欄的漏接毫無防備 - 只看悲觀面：「AI 會嘗試危險操作，不能用」→ 放手了只要妥善圍堵便有用的工具 成熟的看法，是**同時持有兩者**。AI 可能為了優先效率而提出高風險的手段，所以需要圍堵。作為那道圍堵的最後一層，護欄有效，但也不能僅依賴它。 --- ## 4. 所以「單一依賴」行不通 — 判斷取決於模型 關鍵在於，**護欄的判斷是非確定性的，並取決於模型與版本**這一點。這次被攔下的操作，若設定或版本不同，或許就會放行；反之，不危險的操作也可能被過度攔阻。 這在資安世界是理所當然的原則——**切勿將統制託付給單一防禦層**。護欄是「有了會讓人安心的最後堡壘」，而非「有了它其他就不需要」的地基。 那麼該依賴什麼？從這次的實踐可以導出的，是把護欄置於**第 3 層**的三層結構。 --- ## 5. 三層統制 — 護欄是最後堡壘，而非地基 ![AI 委派的三層統制模型（第 1 層 事前原則、第 2 層 人類的承認關卡、第 3 層 護欄）](https://bestnetllc.co.jp/wp-content/uploads/2026/06/fig2_three_layer_governance-1.png) AI 委派的三層統制模型（第 1 層 事前原則、第 2 層 人類的承認關卡、第 3 層 護欄） 1. **第 1 層：事前原則** — 將「可交付／不可交付的資訊」「可做／不可做的操作」，在作業開始前作為對 AI 的最初指示加以固定。這次的「不將憑證永久保存」即屬此層。**統制的地基，不是廠商的安全機制，而是我們自己率先劃下的界線**。 2. **第 2 層：人類的承認關卡** — 在前提瓦解的局面或設計判斷上，AI 僅止於提示選項，由人類決定。這次當環境與當初設想出現出入時，也是 AI 提出選項，由人類裁決方針。 3. **第 3 層：護欄** — 在執行前攔下穿越第 1、2 層的危險操作的最後堡壘。這次正是此層作動了兩次。 順序很重要。**只要第 1 層與第 2 層由我們自己設計好，第 3 層便能作為「保險」運作**。反之，若只指望第 3 層，當它失靈的瞬間便什麼都不剩。 --- ## 6. 最難的是「護欄未作動時」 說「不依賴第 3 層」很容易，但實務的要害正在於此。**有攔下來時很好懂；問題在於沒攔下來時，要如何察覺**。 這次的作業中，我們將 AI 的操作、判斷、安全機制的作動，全部依時間順序記錄於工作日誌。這份日誌可直接成為 AI 運用的稽核軌跡。粒度的概念大致為「〔時刻〕〔操作類別：執行／承認／攔阻〕〔對象：執行原則變更〕〔結果：護欄拒絕〕」即已足夠，如此便能事後依觀點逐一掃描。重點在於，不是「瀏覽」日誌，而是訂定觀點進行事後審查。我認為人類至少應檢查以下 3 個觀點。 - **認證**：有無涉及認證資訊的生成、保存、傳遞的操作 - **權限**：有無觸及權限提升或保護機制變更（執行原則、防火牆、存取控制） - **外部傳送**：有無將資料傳往非預期目的地的操作 若日誌中存在符合這 3 個觀點之一的操作，人類務必確認其執行結果是否違反原則；若有偏離，則一路執行至矯正與防止再發（追記原則）。護欄唯有與這套「由人類事後偵測並處置」的體制成套，才能作為統制而完整。若要把作業交給 AI，前提便是同時備妥不放任不管的機制，亦即記錄，以及訂定觀點的事後審查。 --- ## 7. 落實到 AI 運用方針（AI 治理） 若要把至此所述落實到自家的 AI 運用準則，關鍵不僅是條列原則，更要連「放在何處、由誰、何時查看」都一併定下。 - **放置位置**：第 1 層的事前原則別擱在文件櫃裡，而要作為對 AI 的「最初系統提示／專案規約」貼在作業的開頭。供盤點用的準則，與執行時生效的規約是兩回事 - **承認關卡**：設計判斷、前提變更僅止於 AI 提示選項，並事先定義由人類裁決的局面 - **記錄**：將 AI 的操作、判斷、安全機制的作動／不作動列為記錄對象 - **審查人與頻率**：在各作業工作階段結束時，由非承辦的 1 人以「認證、權限、外部傳送」3 個觀點確認工作日誌，並把有無相關操作留下記錄 - **隔離與最小權限**：切斷作業環境通往正式、客戶系統的路徑，賦予 AI 的權限降到最小 - **非確定性的前提**：以護欄行為會隨模型／版本而變的前提來設計（不單一依賴） 落實為條文文體的「AI 運用準則條文範例」，已於[正篇的附錄 B](https://bestnetllc.co.jp/zh-hant/docs/oracle19c-sqlserver2022-ai-preprocessing-tw/)載有 5 項雛形。本篇的定位，是在其上補上第 6 章的「即便守門人失靈也能察覺的事後審查」。 --- ## 總結 AI 代理對自己的操作說「不行」的這兩次，單就其本身而言，是一段「便利的安全機制發揮了作用」的插曲。然而重要的是，那個安全機制之所以具有意義，是因為它與人類率先劃下的界線相一致；而且**那條界線必須由我們自己來劃**。 護欄能夠成為守門人。但前提是要有雇主（事前原則），以及巡查的機制（記錄與事後審查）。將作業交給 AI 的時代，其統制既不是「相信聰明的 AI」，也不是「因為危險所以不用」，而是**以三層設計圍堵，並讓自己即使最後堡壘失靈也能察覺**——這次的實踐告訴我們，盡在於此。 BESTNET 合同公司就 AI 代理用於業務時的統制設計（資訊的界線劃分、承認流程、稽核日誌運用）提供諮詢。歡迎從「不完全仰賴安全機制的圍堵方式」開始，與我們一同設計。