把伺服器上的實際作業交給 AI 編碼代理。讓它轉換結構描述、搭建驗證環境、執行測試——這樣的用法已逐漸變得實際可行。如此一來，自然會浮現這樣的不安：「萬一 AI 做出了不該做的操作怎麼辦？」

本系列正篇報告了將 Oracle 至 SQL Server 的遷移前處理，在不交付實際資料的前提下以 AI 代理（Claude Code）自動化的實踐。本篇要談的是其中發生的、原本不在計畫內的事件。作業途中，AI 代理端的安全機制（護欄）在執行前兩次攔下了 AI 自己的操作。

本篇旨在從「治理的觀點」深入剖析這兩起事件。這些事件發生時作業的技術幕後（在 SSH 非互動化、字元編碼、PowerShell/T-SQL 的「接縫」處所踩的 10 個坑），則分篇於技術番外篇「把 Windows 實機作業交給 AI 代理所踩的 10 個坑」。

這乍看像是「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. 三層統制 — 護欄是最後堡壘，而非地基 #

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載有 5 項雛形。本篇的定位，是在其上補上第 6 章的「即便守門人失靈也能察覺的事後審查」。

總結 #

AI 代理對自己的操作說「不行」的這兩次，單就其本身而言，是一段「便利的安全機制發揮了作用」的插曲。然而重要的是，那個安全機制之所以具有意義，是因為它與人類率先劃下的界線相一致；而且那條界線必須由我們自己來劃。

護欄能夠成為守門人。但前提是要有雇主（事前原則），以及巡查的機制（記錄與事後審查）。將作業交給 AI 的時代，其統制既不是「相信聰明的 AI」，也不是「因為危險所以不用」，而是以三層設計圍堵，並讓自己即使最後堡壘失靈也能察覺——這次的實踐告訴我們，盡在於此。