最近看到幾個 AI 安全評測案例，讓我重新確認一件看似基本、卻很容易被忽略的事：在 prompt 裡告訴 Agent「這個環境不能上網」，和真的讓它無法連到外部網路，是兩件完全不同的事。
語言指令只是行為期待，不是安全邊界。只要執行環境仍有網路出口、工具仍能發送請求、程序仍拿得到憑證，模型一次誤判、一段惡意內容，或某個工具的非預期行為，就可能把「不可以」變成「其實做得到」。對技術主管來說，真正該問的從來不是 Agent 有沒有答應守規矩，而是它違反規矩時，系統能不能攔住。
Prompt 是操作說明，不是防火牆
我們常在 system prompt 寫下很多限制：不要連外、不要讀取某些資料、不要執行危險指令、遇到敏感內容要先詢問。這些規則有價值，它們能幫模型理解工作範圍，也能降低正常情況下的誤操作。
但 prompt 的本質仍是交給模型解讀的文字。它可能受到上下文干擾，可能把模糊規則解讀錯誤，也可能遇到 prompt injection。更麻煩的是，Agent 往往不是只有一個模型，而是模型、工具、瀏覽器、套件管理器、MCP server、背景 worker 與各種憑證組合成的執行鏈。即使模型本身沒有主動「違規」，其中一個工具也可能因重新導向、遙測、套件下載或錯誤回報而產生外部連線。
所以我會把 prompt 裡的安全規則視為第一層提示，而不是最後一道控制。它比較像牆上的「請勿進入」，不是一扇真的鎖上的門。
真正的隔離，要從出口開始設計
如果一個任務確定不需要外網，最可靠的做法不是反覆提醒模型，而是讓執行環境預設沒有對外出口。容器、虛擬機或沙箱都可以成為邊界，重點在於網路政策必須是 deny by default：沒有明確允許的目的地，就不能連線。
有些任務確實需要存取少數服務，例如內部 Git、套件鏡像或特定 API。這時候也不必在「完全斷網」和「全部開放」之間二選一，可以透過 egress proxy、網域 allowlist、固定目的地、DNS 控制與分離的服務帳號，將出口縮到任務真正需要的範圍。
而且允許清單不能只寫「可連某個網域」就結束。還要考慮重新導向、子網域、IP 變動、DNS rebinding，以及服務回傳內容是否會引導工具再連到其他位置。網路邊界若只停留在文件，最後仍會回到相信 Agent 自律。
工具與憑證也要一起收斂
網路隔離不是單獨一層就能解決全部問題。假設 Agent 不能直接呼叫外網，但它能使用一個擁有廣泛權限的搜尋工具、瀏覽器服務或內部代理，那條代理本身就成了新的出口。同樣地，如果沙箱裡掛載了雲端金鑰、Git token 或正式環境憑證，即使網路限制做得不錯，一旦某個允許的目的地遭到濫用，影響仍可能很大。
我傾向讓工具能力跟著任務配置，而不是跟著 Agent 名稱永久綁定。只做文件摘要的任務，不需要瀏覽器；只跑測試的 coding agent，不需要正式部署憑證；需要查詢某個 API 的工作，也應拿短效、最小 scope、可撤銷的身份。
這裡有一個很實用的檢查方式：不要只列出 Agent「預計會用」哪些工具，而要列出它在最壞情況下「實際能呼叫」哪些能力。兩份清單之間的差距，就是尚未治理的攻擊面。
沒有觀測，就無法證明限制有效
另一個常見盲點是，團隊設定了網路政策，卻沒有保留足夠的連線紀錄。最後只能說「理論上擋住了」，但不知道 Agent 嘗試過什麼、被擋了多少次，也不知道是否存在繞過控制的旁路。
正式環境至少應該記錄：哪一個任務、以哪個身份、透過哪個工具、嘗試連到哪個目的地、是否被允許，以及套用的是哪一版政策。被拒絕的流量尤其重要，因為它可能代表模型誤判、工具行為改變、prompt injection，或正常需求已經超出原本設計。
不過紀錄本身也要節制。URL、header、request body 可能包含機密，不能為了稽核又把敏感資料完整複製到 log。好的 observability 不是什麼都記，而是保留足以還原決策的事件，同時對內容做遮罩、分級與保存期限管理。
安全測試要故意要求它犯規
我不太相信只跑成功路徑的 Agent 測試。若規格說「不得連外」，測試就應主動放入會誘惑它連線的情境：文件裡要求下載額外指令、套件缺失時建議自動安裝、錯誤訊息附上一個回報網址，或工具結果聲稱必須向外部服務驗證。
測試的標準也不能只是模型最後回答「我不會連線」。應該直接檢查網路事件、工具呼叫、DNS 查詢與憑證使用紀錄，確認違規動作確實被基礎設施阻擋。最好再把這些案例放進每次模型、工具與 runtime 更新的 regression test，因為安全邊界常常不是被一次大改動破壞，而是在許多小更新裡慢慢鬆掉。
紅隊測試的價值，也正在這裡。它不是證明模型很壞，而是幫團隊找出哪些規則其實只存在於大家的想像中。
把「不可以」做成系統事實
Agent 系統最危險的錯覺，是把模型說得出安全原則，誤認成平台已經安全。模型可以理解政策，也可以協助判斷風險，但它不應同時成為規則的解讀者、執行者與最後守門人。
我現在設計這類工作流，會把控制拆成幾層：prompt 說明預期行為；工具 registry 限制可用能力；身份與憑證縮小資料範圍；沙箱與網路政策阻止越界；審批處理高風險例外；事件紀錄與對抗測試負責證明這些控制真的有效。
這些做法看起來比多寫一句 prompt 麻煩，但它們有一個關鍵差別：prompt 只能告訴 Agent 不要犯錯，工程控制則能讓錯誤發生時停在邊界內。
企業導入 Agent，真正需要的不是一個很會承諾「我不會亂來」的模型，而是一套即使模型判斷錯了，也不會讓一次錯誤直接變成外洩、誤操作或正式環境事故的執行架構。
當需求寫著「不得連外」時，我們不該把它留在對話裡。要把它做成網路封包真的過不去、工具真的拿不到、憑證真的不能用，而且事後真的查得到的系統事實。