公司級 AI Agent 安全指南：權限、注入與稽核

公司裡最危險的 Agent，不一定是回答錯誤的那一個，而是回答錯誤後仍有權限採取行動的那一個。

一封 Email、一份網頁文件或一個 GitHub issue，都可能夾帶給 Agent 的隱藏指令。若 Agent 同時能讀取內部資料、呼叫工具、使用長效憑證並把結果送到外部，單一提示注入（prompt injection）就可能串成完整攻擊路徑。

公司級 Agent 的安全目標不是保證模型永不受騙，而是讓一次錯誤判斷無法自動跨越身分、資料、權限與交付邊界。

上一篇已建立身分、記憶、憑證與沙箱對齊的 scope。現在要從攻擊者角度檢查：這些邊界會在哪裡失效？

先畫資料流，不要先買安全功能

威脅模型的第一步不是列產品，而是畫出 Agent 的資料與權限流：

哪些內容會進入模型？
哪些內容來自不可信的外部來源？
模型可以選擇哪些工具？
工具背後使用誰的權限？
哪些動作能改變外部狀態？
結果會被保存或送到哪裡？

Loading diagram...

圖裡真正需要保護的不是一個模型 API，而是外部內容取得內部權限後形成的閉環。Agent 讀取的結果會再次進入 context，寫入的記憶又可能影響未來任務；攻擊因此能跨回合持續存在。

OWASP 的 Agentic AI Security Initiative 將這類系統視為新的威脅面；NIST 的生成式 AI 風險管理框架則以 Govern、Map、Measure、Manage 四項功能組織風險管理，而不是只在上線前做一次測試。

威脅一：提示注入把資料變成指令

直接提示注入（direct prompt injection）來自使用者直接輸入；間接提示注入（indirect prompt injection）則藏在 Agent 讀取的 Email、網頁、文件、程式碼或工具回傳中。後者對公司 Agent 更危險，因為系統原本就被設計成主動讀取大量外部內容。

典型攻擊不是直接說「偷走資料」，而是逐步改變 Agent 的判斷：要求忽略原任務、呼叫另一個工具、把內部內容編碼後送到某個網址，或將惡意指令寫入長期記憶。

防禦不能只靠 system prompt 宣告「不要遵守文件裡的指令」。至少要把內容和指令分開處理：

標記來源與信任等級。
不讓不可信內容自行擴張工具權限。
對敏感動作使用確定性政策，而不是模型自評。
在工具層限制目的地、參數與資料量。
高影響動作要求人類批准。

MCP 工具投毒與安全掃描呈現另一種相同問題：工具描述本身也可能成為不可信輸入。即使使用者沒有打開惡意文件，Agent 仍可能從工具的中繼資料（metadata）接收到操控指令。

威脅二：混淆代理人與權限提升

Agent 常成為混淆代理人（confused deputy）：它本身握有高權限，卻替低權限使用者完成原本做不到的事情。

例如，員工沒有財務系統權限，但共享 Agent 已登入管理員帳號。只要員工能說服 Agent 查詢特定資料，就等於繞過原系統的授權。問題不是模型「洩密」這麼簡單，而是平台把驗證聊天入口當成驗證後端動作。

每次工具呼叫都應重新計算有效權限：

有效權限 = 觸發者（actor）可做的事 ∩ 身分主體（principal）被授權的事 ∩ 當前任務允許的事

交集模型會比「Agent 有什麼就做什麼」保守。需要代表使用者的動作，優先使用短效委派；屬於團隊自動化的動作，使用獨立服務帳號並限制資源範圍。不要把創辦人或管理員的瀏覽器 session 當成全公司的通用 keychain。

威脅三：跨 Scope 資料外洩

資料外洩不一定離開公司。私人對話的內容出現在專案頻道、A 客戶資料出現在 B 客戶報告，同樣是安全事件。

常見原因包括：

向量檢索沒有 scope filter。
快取 key 未包含 tenant 或專案身分。
共享 workspace 遺留上一個任務的檔案。
錯誤訊息直接包含 secret 或完整文件。
回覆送回錯誤 thread 或 audience。
管理介面允許跨 scope 搜尋但沒有額外授權。

因此隔離測試不只要問「能不能讀」，還要測「能不能搜尋、推測、快取、摘要與交付」。最值得自動化的是負向測試：刻意要求低權限 scope 找出高權限資料，確認每一層都拒絕。

威脅四：持久化與供應鏈污染

Agent 可以安裝套件、建立 skill、修改啟動檔、寫入記憶及排程 cron。這些能力讓它能長時間工作，也讓一次攻擊可能在重啟後繼續存在。

持久化風險常藏在：

自動安裝且未鎖定版本的依賴
未經審查的 MCP server 或 skill
會在啟動時載入的工作區指令
被污染的長期記憶與 checkpoint
Agent 自行建立的背景排程
可寫入的 CI 或部署設定

控制方法包括建立允許清單、鎖定版本與雜湊、將基礎映像設為唯讀、掃描輸出產物，以及讓所有持久變更形成可審核的 diff。若你正在建立獨立測試環境，本站整理的開發者桌面 4 件套可作為工作區設備參考；這是聯盟連結，若透過連結購買，我們可能獲得少量分潤，價格不受影響。

安全模式不是三個標籤，而是政策組合

QM 目前提供 Strict、Auto 與 Dangerous 三種安全姿態。依公開程式碼，Strict 會讓絕大多數 harness 工具在執行前暫停等待人工批准；Auto 不逐次批准工具，而是篩檢有來源標記、受支援的外部文字；Dangerous 則關閉內容篩檢與工具批准，但身分驗證、授權、租戶邊界、撤銷、稽核與 hard denial 仍然適用。

這類模式對使用者很直覺，但公司不能只記住模式名稱；應拆成真正可執行的政策：

控制面	低風險預設	升級條件
檔案	僅 scope workspace	額外目錄逐次批准
網路	拒絕或允許清單	新目的地需核准
憑證	無或短效授權	依動作與資源核發
Shell	sandbox 內受限命令	高風險命令人工批准
外部寫入	草稿或 dry run	發信、付款、部署前確認
記憶	來源標記、有限保留	敏感內容禁止自動寫入

「自動批准」也不該代表全部自動。讀公開資料、整理草稿和執行已核准測試可以使用不同政策；付款、刪除、修改正式環境或對外發布則需要更高門檻。

QM 的 SECURITY.md 也明確列出目前限制：command policy 可以被混淆或轉成腳本繞過；browser runner 裡的部分動作不會重新經過 command policy 或逐次人工批准；egress 強制效果則取決於 sandbox backend，部署執行期的 egress enforcement 尚未建成。早期開源專案公開限制是好事，但不等於採用者可以把限制視為已解決。

Approval 必須顯示「將要發生什麼」

沒有上下文的「允許／拒絕」按鈕，只會製造 approval fatigue。有效的批准畫面至少要顯示：

Agent 代表誰及由誰觸發
即將呼叫的工具和目標資源
會送出的資料類型與大致數量
這次授權是單次、限時或永久
失敗與回滾方式
結果將交付給誰

能產生外部影響的工作，最好拆成計畫（plan）、預覽（preview）、執行（commit）三階段。Agent 先提出計畫，再產生可檢查的草稿或差異（diff），最後才使用一次性授權執行。這會降低自動化速度，卻讓批准變成真正的控制點。

撤銷能力要和授權能力同一天上線

如果平台能新增 connector、建立 cron、保存 session，卻無法快速撤銷，它就只完成一半。

公司至少需要能依使用者、scope、服務與事件批次撤銷：

API token 和 OAuth grant
瀏覽器 session
背景任務與 webhook
MCP server 或 skill
sandbox 網路權限
記憶讀寫與資料分享

員工離職、裝置遺失、connector 爆出漏洞或偵測到異常行為時，撤銷不應依賴逐台登入 Agent 主機。這正是控制層比一堆個人設定檔更重要的地方。

稽核日誌要能重建一次決策

只記錄「工具呼叫成功」不足以調查 Agent 事件。一筆可用的稽核事件（audit event）應能回答：

觸發者（actor）和身分主體（principal）是誰？
任務發生在哪個 scope？
哪些外部內容進入 context？
使用哪個模型、prompt、skill 與工具版本？
哪一條政策允許或拒絕動作？
使用什麼授權、參數與目標資源？
結果寫入哪裡，交付給誰？
哪位人員做了批准？

機密原文不一定要完整寫進日誌，可以保留內容雜湊、資料分類、參照位置與經過遮罩的摘要。稽核儲存區應和 Agent 工作負載分開，避免受感染的 Agent 同時修改自己的證據。

上線前的最小安全基線

公司級試點至少應滿足以下條件：

每個作用域（scope）都有明確身分主體（principal）與交付對象（audience）。
不可信內容無法自行提高工具權限。
高影響動作有 preview 與人工批准。
憑證按需、短效且可以集中撤銷。
Sandbox 限制檔案、程序、網路與資源。
記憶與檢索會執行作用域過濾（scope filter）。
Connector、skill 與依賴有版本及來源紀錄。
稽核日誌能串起輸入、政策、工具與輸出。
已演練跨 scope 讀取、惡意文件與撤銷情境。
有停用 Agent 且不中斷核心業務的方式。

安全不是把 Agent 變得完全不能做事，而是讓它只在被授權的範圍內做事，並在越界時留下足夠證據。

下一篇會比較 QM、OpenClaw 與 Hermes Agent。重點不是替三個專案排名，而是看清它們各自處理 Agent stack 的哪一層，以及哪種部署模型最符合你的信任邊界。

常見問題

公司級 AI Agent 最大的安全風險是什麼？

核心風險是 Agent 會把不可信內容轉成具有組織權限的行動。Prompt injection、過度授權、共用憑證與缺乏稽核會彼此放大，而不是各自獨立。

有沙箱就能防止提示注入嗎？

不能。Sandbox 能限制受感染 Agent 的影響範圍，但無法判斷內容是否可信；仍需搭配最小權限、資料標記、動作批准與輸出檢查。

Agent 稽核日誌至少要記錄哪些資料？

至少記錄觸發者、身分主體、作用域、輸入來源、模型與工具版本、授權決策、工具參數、結果摘要、交付對象、時間及關聯事件 ID。

可以讓所有員工共用同一個 Agent 嗎？

可以共用服務入口，但不應共用無差別的身分、記憶和高權限憑證。不同信任群組需要可執行的作用域或獨立執行環境邊界。