AI Agent Scope 怎麼設計？記憶、憑證與沙箱隔離
Scope 不只是對話分組，而是公司 Agent 的最小信任邊界。本文拆解身分主體、記憶、憑證授權、持久沙箱與交付對象，說明如何讓個人與共享 Agent 不再混用權限。
目錄+
把兩個 Slack 頻道分成兩段對話，不等於你已經隔離兩個 Agent。
只要它們仍共用同一份長期記憶、同一個工作目錄、同一組登入憑證或同一個背景程序，一個頻道裡的指令就可能影響另一個頻道。Conversation ID 解決的是訊息歸檔，scope 解決的才是信任邊界。
一個完整的 AI Agent scope，應該同時對齊身分主體（principal）、記憶、憑證授權、持久沙箱與交付對象。
上一篇談過公司級 Agent 和個人助手的六個分界。這一篇往下拆架構：scope 到底要包住哪些東西，才能成為公司真正可用的隔離單位。
Conversation ID 不是安全邊界
多數聊天系統都有 channel ID、thread ID 或 conversation ID。它們可以讓模型只看到目前對話，也能把回覆送回正確視窗，但通常不會自動處理以下問題：
- 兩段對話是否讀到同一份長期記憶。
- Agent 是否在同一個檔案系統執行。
- 兩個頻道是否共用登入後的瀏覽器狀態。
- 背景排程究竟屬於個人、專案還是整間公司。
- 某位成員離開後，過去授權是否仍能被使用。
- 輸出包含機密內容時，哪些人仍能看到結果。
因此，scope 不能只是資料庫裡的一個 conversation_id 欄位。它必須一路約束到執行與交付階段。
QM 的公開設計正好呈現這個方向：每位使用者與每個 room 都有自己的記憶、檔案、憑證檢視（keychain view）、權限、排程、Web App 和持久沙箱（durable sandbox）。這些元件不是恰好放在一起，而是在回答同一個問題：Agent 此刻代表哪一個信任單位？
第一層：先定義 Principal，再建立 Scope
Principal 是能被辨識、被授權，並能記錄責任歸屬的身分主體。它可能是：
- 一位員工
- 一個專案團隊
- 一個部門
- 一個服務帳號
- 一條經批准的自動化工作流
個人 scope 可以直接綁定員工身分；共享 scope 則不應假裝自己是某位成員。它更適合擁有獨立的專案身分與權限集合，再記錄是哪位成員觸發了這次行動。
這裡需要同時保存兩種資訊：actor 是誰發出指令，principal 是 Agent 正在代表誰。兩者可能相同，也可能不同。
例如，工程師在客服專案頻道要求 Agent 查詢退款紀錄。Actor 是工程師，principal 可能是客服專案；系統仍要檢查工程師能否代表該專案執行這個動作。少了其中一層，個人權限可能被錯誤帶入共享環境，或共享 Agent 可能成為繞過個人權限的入口。
第二層：記憶要有所有權，也要有寫入政策
Agent 記憶常被當成檢索技術問題：用 Markdown、向量資料庫還是知識圖譜？進入組織後，更早要回答的是「這段內容屬於誰」。
一段記憶至少需要這些欄位：
- 所屬 scope
- 來源與建立者
- 建立時間及保留期限
- 敏感等級
- 可讀、可寫與可分享的對象
- 是否允許被模型摘要或再寫入
個人偏好不應自動變成團隊規則；專案決策也不應只存在離職員工的個人 Agent 裡。共享記憶的價值，在於它能脫離單一成員持續存在；它的風險，也在於內容可能被更多人反覆取回。
OpenClaw 將記憶保存在 Agent workspace 的檔案中，讓使用者能直接檢查與版本控制。QM 則把記憶與 scope 綁定。兩者共同提醒我們：記憶不能只是模型看不到來源的一團 embedding。想看另一種可檢查的長期記憶設計，可搭配 GBrain 的雙軌 Agent 記憶架構閱讀。
第三層：Keychain View 不等於複製 Secret
憑證隔離最危險的做法，是把所有 API key 和登入狀態複製到每一個 Agent 環境。這雖然方便，卻讓任何 prompt injection、錯誤工具呼叫或套件漏洞都可能接觸完整權限。
比較穩健的模型是讓每個 scope 只看見一個 憑證檢視（keychain view）：它知道哪些能力可以申請，卻不必永久持有所有原始密鑰（secret）。真正執行時，再由控制層依政策發出短效、限用途的授權（grant）。
一個授權至少應包含：
- 允許呼叫的服務與動作
- 允許存取的資源範圍
- 有效期限
- 是否需要人工批准
- 誰授權、誰觸發
授權決策還要與交付政策一起檢查，確認結果能否送到目前的交付對象（audience）。
共享 scope 尤其不該默認繼承發言者全部的個人登入狀態。若專案確實需要 GitHub、CRM 或雲端資源，應配置專案服務身分，或使用可撤銷的使用者委派。這樣員工離開專案時，可以撤掉授權，而不必重建整個 Agent。
第四層：Durable Sandbox 同時要持久與隔離
很多 Agent 任務無法在一次請求內完成。它可能需要下載程式碼、安裝依賴、等待測試、保存中間檔，甚至隔天由 cron 繼續。因此執行環境需要 durable，也就是任務之間能保留狀態。
但持久狀態也會累積風險：惡意檔案、被竄改的工具、舊憑證與錯誤設定，都可能跟著環境留下來。所以 durable sandbox 必須同時限制：
- 可掛載的檔案與目錄
- 程序與系統呼叫
- 對外網路與內部服務
- CPU、記憶體、儲存及執行時間
- 可注入的憑證
- 產物如何被取出與掃描
Workspace 只是 Agent 的工作位置，不自動構成上述限制。OpenClaw 的官方安全說明也特別區分 workspace 與 sandbox：如果沒有啟用沙箱，workspace 路徑本身不會阻止工具讀取系統其他位置。
QM 將每個 scope 對應到 durable sandbox，讓個人與共享空間既能延續任務，又能分開影響範圍。對準備自行測試隔離環境的開發者，與其一開始購入昂貴主機，更值得先把可重建的環境與權限清單做好；需要整理測試工作區時，可參考本站挑選的開發者桌面 4 件套。這是聯盟連結，若透過連結購買，我們可能獲得少量分潤，價格不受影響。
第五層：Core 要把訊息、政策與執行接起來
如果 Slack、Web、cron 和 webhook 各自直接啟動 Agent，隔離政策很容易散落在不同入口。比較一致的架構，是讓所有入口先進入同一個無介面核心服務（headless core），由核心解析身分、scope、權限與交付對象，再啟動相對應的 Agent loop 和 sandbox。
QM 的架構以 Postgres 保存 session、memory、job queue 等長期狀態，Agent loop 本身則可以替換為 Pi、OpenCode、Claude Code 或 Codex。這種分層的重點不是資料庫品牌，而是把「組織知道什麼」和「某個 Agent loop 此刻正在運算什麼」分開。
當 loop 當機或模型被替換時，身分、權限與任務狀態仍留在控制層；當新的訊息入口加入時，也不必重新發明一套安全政策。
第六層：部署隔離不能只停在應用程式
應用程式裡的 scope 欄位很重要，但如果所有 sandbox 仍在同一個高權限主機上執行，底層錯誤可能跨越邏輯邊界。
QM 的部署文件把 core、外部服務與 plugins、資料層及 sandbox substrate 分開配置。這表示公司在設計部署時，還要逐層回答：
- 外部訊息從哪裡進來？
- 哪一層能連到資料庫與秘密管理服務？
- 誰能建立或銷毀 sandbox？
- sandbox 能否主動連回內部網路？
- 稽核事件在哪一層產生，能否被工作負載修改？
QM 的 v1 部署契約會驗證 egress host 設定並拒絕危險的 wildcard，但官方明確標示目前是 validated-only：驗證設定不等於已在執行期強制網路出口政策。部署者仍要用實際的容器、主機或雲端網路控制補上這一層。
小型試點不必第一天複製完整分層，但必須知道自己省略了哪一道邊界。把 core、資料庫與執行程序全放在一台機器，不代表一定不可行；它只是形成一個更大的影響半徑（blast radius），必須用更低敏感度的資料與更窄權限來補償。
一個 Scope 的六項驗收檢查
在把 Agent 加進下一個部門或頻道前，可以用六個問題檢查：
- Principal（身分主體）：Agent 目前代表個人、專案還是服務？
- Memory（記憶）：讀寫的內容屬於誰，多久後刪除？
- Credentials（憑證）：能使用哪些授權，能否立即撤銷？
- Sandbox（沙箱）：檔案、程序與網路是否真的分開？
- Audience（交付對象）：輸出可以送給哪些人與哪些頻道？
- Audit（稽核）：誰觸發、批准並執行了哪一個動作？
只要其中一題沒有答案，scope 就還只是介面分組，不是完整的信任邊界。
這也是為什麼 MCP 工具投毒不能只靠提醒模型小心處理。工具描述、執行權限與結果交付都要被平台約束，才能在模型判斷失誤時縮小損害。
Scope 是公司 Agent 的最小治理單位
公司級 Agent 不需要一開始就做成龐大平台，但需要先選對治理單位。
以使用者為單位，無法承接長期專案；以 conversation 為單位，又包不住憑證與執行環境。Scope 比較實用，因為它讓一個工作場景的身分、狀態、權限與影響範圍一起建立，也能一起撤銷。
這套設計仍不代表系統已經安全。下一篇會繼續處理更難的部分：prompt injection、權限提升、跨 scope 資料外洩，以及公司 Agent 應該留下哪些稽核證據。
常見問題
AI Agent 的 scope 是什麼？
Scope 是一組彼此對齊的身分、記憶、檔案、憑證授權、執行環境與交付對象。它決定 Agent 正在代表誰、可以使用什麼，以及結果能送給誰。
為什麼不能只用 conversation ID 隔離 Agent？
Conversation ID 通常只區分聊天紀錄，未必同時隔離長期記憶、檔案、登入憑證、背景任務與執行環境，因此不能單獨當成安全邊界。
Agent workspace 就等於 sandbox 嗎？
不等於。Workspace 是工作資料所在的位置；sandbox 才是限制程序能讀寫哪些檔案、連到哪些網路及取得哪些憑證的執行邊界。
共享 Agent 應該使用誰的憑證？
應依任務與組織政策選擇專案服務帳號、短效授權或經批准的使用者委派，不能因為某位成員曾登入，就讓整個共享 scope 繼承他的權限。