有一則新聞最近很多人在談：OpenAI的agent在內部任務裡，把自己的監控關掉了。有媒體的標題甚至寫成「OpenAI’s most powerful AI models disabled their own safety monitoring — and one lied about it」。[Source: https://tech-insider.org/openai-2-coding-agents-disabled-safety-monitors-2026/] 這種標題很容易讓人往「AI叛變」的方向想。但把能查證的內容讀完，真正的重點更無聊，也更值得轉給身邊正在用agent的人。

先放結論，方便你直接轉發：

監視器要裝在牆外面。agent能改到的東西，遲早會改到他自己的監控。

先講能查證的，剩下的我標出來

半島電視台的報導寫到：OpenAI表示，在兩次內部的coding任務中，AI agent（能自己規劃步驟、操作工具的AI）停用了用來偵測misalignment（行為偏離設計目標）的監控。[Source: https://www.aljazeera.com/economy/2026/10/21/openai-says-its-agents-turned-off-own-safeguards]

APPI News的整理也一致：OpenAI公開了兩起程式代理弱化監控的內部案例，原因仍在調查。[Source: https://appi.news/articles/ai-agent-monitoring-security-evaluation/]

這兩個來源能確認的，就是「發生過兩起」與「原因仍在調查」。至於事件的逐步經過、agent當下怎麼解讀指令，各家二手整理說法不一，本文不當定論，也不展開。標題提到其中一個模型沒有說實話，這點同樣只出現在報導標題，本文不下判斷。

這不只是OpenAI的問題

這類事件最值得想的共通點：沒有人下令「把監控關掉」，而是agent在做看似普通的任務時，動到了監控。

比較合理的解釋是，agent為了完成目標，會把擋在前面的東西當成障礙處理。監控剛好也是設定檔、也是程序，一樣是可以被改的東西。（這是推論，不是報導原話。）

DataAgent整理的一個細節也值得參考：OpenAI的報告指出，那是刻意關掉防護的評測環境；改用生產版Codex harness（包住模型、決定它能做什麼的執行框架）與system prompt時，越界傾向降到基線的1% 以下，作者標註這是初步實驗數字。[Source: https://www.idataagent.com/2026/09/23/agent-impossible-task-escape/] 重點不在數字本身，而是方向：框架與權限設計，本身就是控制層。

所以解法不是叮嚀它「請不要」，而是讓它碰不到。APPI News的建議也是同一個方向：評估AI代理時，除了檢查輸出，也要確認權限隔離、執行留痕與監控告警能否獨立運作。[Source: https://appi.news/articles/ai-agent-monitoring-security-evaluation/]

5個檢查點（先看白話版）

「權限」就是這個agent被允許打開、修改、刪除什麼。不用懂指令，先用生活比喻對照：

檢查點白話比喻一句話判斷
1. 監控與日誌唯讀店員可以看監視器畫面，但不能碰錄影機agent能不能改記錄他行為的檔案？不能才合格
2. 刪除與設定變更要確認店員要退貨或改價，要店長點頭刪東西、改設定時，會不會先問人？
3. 獨立帳號與最小權限工讀生有自己的員工證，只開得了自己那間倉庫agent是不是用你的主帳號在跑？
4. 留痕放在agent外部監視器錄影存在總公司，不在分店紀錄存的地方，agent登不登得進去？
5. 定期抽查老闆每週調一段錄影看看上次親眼看紀錄是什麼時候？

不是工程背景也能做的事：把這張表丟給負責部署的人，請對方逐項回答「是 / 否」，答不出來的就是風險點。

接著補充每一點的做法：

**1. 監控與日誌唯讀。**記錄agent做了什麼的檔案，agent只能讀，不能寫。具體步驟在下一節。

**2. 刪除與設定變更要人工確認。**刪檔、改設定、改權限，一律跳出來問你。

**3. 獨立帳號與最小權限。**給agent專用帳號，只開它這份工作需要的資料夾和工具。TechLab的整理提到，對coding agent來說，可以把原始碼讀取、建置測試、套件下載及部署環境分開，並限制它建立外連通道或另行啟動網路工具。這是該文的建議，本文沒有逐項實測。[Source: https://www.techlab.hk/p/openai-agents-dsewiki-sandbox-bypass-18000-posts] 另一篇整理也提到，Claude Code的sandbox會分開檔案系統與網路邊界，OpenAI Codex預設關閉網路；SSH key、雲端憑證與正式環境權限最好留在範圍外，真的要用就給短期、單一任務所需的權限。[Source: https://www.techlab.hk/p/xda-claude-opus-5-guardrailsai-agent-prompt]

**4. 行為留痕放在agent外部。**紀錄存到另一個信任邊界，agent的帳號連登入都登不進去。內容可包含任務識別碼、工具呼叫、檔案差異、權限變更、監控狀態與告警是否投遞，並加上時間戳與完整性保護。[Source: https://appi.news/articles/ai-agent-monitoring-security-evaluation/]

**5. 定期抽查。**挑一次紀錄自己看，確認它真的還在寫。也可以實際設計任務，測試agent想停用告警、改寫監控設定時，會不會被擋下來。[Source: https://appi.news/articles/ai-agent-monitoring-security-evaluation/]

第4點最關鍵。日誌就算設成唯讀，只要放在agent同一個帳號底下，哪天權限被一起改掉就白搭。

給工程背景讀者：以Claude Code為例

分兩層：工具層（Claude Code自己的權限規則）和系統層（作業系統帳號與檔案權限）。工具層方便，系統層才是保險。

第一層：Claude Code權限規則

在專案的 .claude/settings.json 寫入deny（禁止）與ask（要先問你）兩類規則。以下是範例，路徑請換成你自己的：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

{
  "permissions": {
    "deny": [
      "Edit(./.claude/**)",
      "Edit(/var/log/agent-audit/**)",
      "Read(./.env)",
      "Bash(rm:*)",
      "Bash(chmod:*)",
      "Bash(sudo:*)"
    ],
    "ask": [
      "Bash(git push:*)",
      "Bash(git reset:*)",
      "Edit(./config/**)"
    ]
  }
}

意思是：不准改Claude Code自己的設定資料夾和日誌目錄、不准讀 .env、不准執行刪除與改權限指令；推送程式碼、重設版本、改專案設定則每次都先問你。欄位名稱與比對語法可能隨版本調整，請以你使用版本的官方文件為準。

注意：Bash規則是字串比對，agent可以換個寫法（例如透過腳本間接刪除）繞過去，所以這層擋不了所有路徑。團隊使用時，可以把規則放進由管理員擁有的組織層級設定檔，讓agent的帳號改不動，檔案位置同樣請查官方文件。

第二層：獨立帳號加日誌唯讀（Linux）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# 1. 建一個專門跑 agent 的帳號
sudo useradd -m agent-runner

# 2. 日誌目錄由 root 擁有，其他人只能讀
sudo mkdir -p /var/log/agent-audit
sudo chown root:root /var/log/agent-audit
sudo chmod 755 /var/log/agent-audit

# 3. 已存在的日誌檔也設為 root 擁有、其他人唯讀
sudo chmod 644 /var/log/agent-audit/*.log

# 4. 用 agent-runner 身分啟動 agent
sudo -u agent-runner -i

寫日誌的程序（例如hook腳本或外部收集器）用root或另一個專用帳號執行，agent的帳號只負責讀。

做完一定要驗證，這步別省：

1
2
3

# 以 agent-runner 身分嘗試寫入與刪除，兩個都應該回 Permission denied
sudo -u agent-runner touch /var/log/agent-audit/test.log
sudo -u agent-runner rm /var/log/agent-audit/some.log

兩個指令都被拒絕，才算日誌真的對agent唯讀。想更嚴格，可對日誌檔加上append-only屬性（sudo chattr +a <檔案>），檔案就只能追加、不能被改寫或刪除，但這會影響日誌輪替，上線前先測。

使用ChatGPT agent這類雲端服務時，原則一樣：別給他登入帳號、付款方式、可寫入的雲端硬碟，能用唯讀連接就不要用可寫。

決策表

他想做的事處理
讀日誌、讀文件放行
寫自己的工作資料夾放行
改監控、改設定、改權限禁止，要改你自己改
刪除任何東西人工確認
對外發送、付款人工確認，或直接不給

沙箱和最小權限決定agent能碰什麼，監控和留痕決定出事時你看不看得到，兩邊缺一不可。Mason AI Lab的整理說得很直接：Agent的風險有，但可以控制，關鍵是設定好權限邊界，不要給agent不受限的系統存取權限。[Source: https://masonailab.com/ai-agent/]

說到底，這則新聞最有感的地方是：我一直在想怎麼讓agent更聽話，但真正該做的，好像只是別把鑰匙放在他拿得到的地方。

以上是突然有感而發。