設計有界 AI 助理：工具、權限與情境限制實務

AI 助理真正的邊界，是模型外圍可執行、可查核的服務合約，而不是系統提示內一句「不要發送」。只要助理仍握有可發送訊息的工具和憑證，文字禁令便不是權限控制。若團隊把整個助理一次過授權，普通查詢亦可能沿用無關資料、過大權限或不合適的行動路徑；較穩妥的做法，是把搜尋、摘要、草擬、更新、發送、刪除和批准逐項拆開，分別設定資料、身份、工具、上限、證據、測試及負責人。

助理應獲准做甚麼？

團隊應先寫一項一句式服務章程，再把章程拆成用戶看得到的具體能力。可採用這個句式：「對於合資格用戶，助理可運用獲批資訊範圍處理指定工作，產生獲准結果，但不可作出列明的後果性決定。」當中的「協助」或「管理」必須改寫成搜尋、摘要、建議、草擬、更新、發送、刪除或批准等操作。連接工具前，還要列明用戶、部署環境、支援工作、知識限制、人手監督、風險負責人和禁止結果。NIST AI RMF 要求機構記錄用途、支援工作、知識限制、應用範圍與監督；OWASP 則主張只暴露最低所需工具功能。以能力作控制單位，是根據這些原則整理出的實務方法，並非任何一方規定的架構。

• 把「處理客戶個案」拆成讀取合資格個案、摘要、建立回覆草稿及已批准發送。
• 為每項能力寫成功結果、明確非目標、容許輸入、可產生輸出及責任人。
• 先讓最小而有用的能力成立；日後擴權須走變更覆核，不應只修改提示。

每項能力可使用哪些資訊？

情境限制應是一個資訊封套，界定能力可接觸甚麼資料及信任邊界，而不只是模型可容納多少文字。每項能力須列出獲批系統、紀錄種類、資料分類、物件篩選、日期範圍、時效要求、用戶原有權益及禁止資料。NIST 的 Map 成果把知識限制、應用範圍及輸出使用監督列為應記錄事項；因此，擴大情境視窗不會增加資料權限，也不會令缺乏證據的內容變真。所需紀錄無法存取、缺漏或過時時，服務應拒絕回答或清楚限定結論。

外來訊息、附件、文件、API 回應和檢索內容應視為不可信內容，不能悄悄變成服務指令。會話紀錄與持久記憶亦要分開設計：甚麼可在同一會話沿用、甚麼經驗證後才可保存、如何隔離不同用戶及會話、何時失效和刪除，以及哪些敏感資料永不寫入記憶。OWASP 的相關指引同時涵蓋保存前驗證、隔離、期限、容量、敏感資料覆核及完整性保護，但具體數值須按服務、私隱和紀錄政策制定。

身份、工具與權限如何落實邊界？

身份驗證、授權和批准必須分開判斷，而真正限制資源及操作的地方，應是工具閘道和下游系統，不是模型。身份驗證回答「目前是誰或哪個工作負載」；授權回答「這個身份可否對指定資源執行指定操作」；批准則回答「負責人是否接受眼前這一項建議行動」。團隊要明確選擇委託用戶權限或受控工作負載身份，不能暗中借用高權限操作員帳戶。工具亦應只提供經參數驗證的窄操作，限制動詞、資源、物件、欄位、目的地、憑證期限及權杖受眾，避免提供廣泛郵箱、資料庫、瀏覽器或指令殼存取。OWASP 要求最低下游權限並保留用戶授權脈絡；NCSC 亦建議最小權限、安全預設及外部失效保障。MCP 的最小範圍和資源綁定可作受保護 MCP 整合的參考，但不是所有工具的通用規格。

• 為每次執行核實行動身份、操作、目標資源及物件範圍。
• 按服務設定速率、重試、行動鏈深度、批量、開支、時限、冪等、回復及斷路條件，不套用虛構的統一門檻。
• 讓下游系統完整仲裁每次請求；自然語言守則只能提示行為，不能充當授權。

對話可以連續，權限卻應拆成細小而獨立執行的能力。

每項能力可以採取多大行動？

每項能力都要有明確行動上限；越接近改變外部狀態，越需要獨立而強的控制。以下階梯是根據最小工具、下游授權和外部保障原則整理的實務綜合，不是通用風險分級。草擬與發送要分開，可逆紀錄更新與破壞性變更要分開，提出方案與承擔決定亦要分開。對有實質外部影響的行動，介面應先展示可檢查預覽，再把批准綁定於行動者、工具、目標、正規化參數、時間和有效期，並在執行前重新驗證。批准只接受該項建議行動，不能補回缺失授權、擴大常設權限或令禁止決定變成可做。

1. 回答或摘要：只從合資格資料提供資訊，不改變外部狀態。
2. 建議或提出：建立可檢查方案，清楚標示依據、不確定性及尚未執行。
3. 建立草稿：只寫入非最終工作區，由指定人士覆核，不產生對外承諾。
4. 有限而可逆寫入：只改獲批物件和欄位，具驗證、冪等或回復及稽核紀錄。
5. 後果性外部行動：發送、發布、刪除、付款、授予存取或生產變更，須有有效授權、逐次批准及獨立執行政策。
6. 禁止決定：高風險專業判斷或服務明訂不可作出的事項，即使用戶要求或在助理內批准，能力仍須缺席並由下游拒絕。

助理觸及邊界時應怎樣處理？

拒絕、安全的部分協助、人手交接及保安升級應設計成正式服務結果，並各有真正停止條件。原因可包括工作不在範圍、資料不合資格、授權不足、需要批准、證據缺漏或過時、需要專業判斷、依賴服務不可用、營運上限已達或偵測到保安訊號。回應要用清楚語言交代邊界，但不披露敏感政策細節；未完成來源檢查、工具呼叫、批准或寫入時，絕不能聲稱成功。仍安全的部分可以是草稿、核對清單或補充資料要求。NIST 把超出知識限制時安全失效納入評估成果；NCSC 則要求事故計劃、升級情境、受訓應變人員及高質素稽核紀錄。

• 交接包應包含原始目標、非敏感脈絡、嘗試的能力、原因、現有或缺失證據、建議下一步及追蹤識別碼。
• 一般用戶交接、業務批准及保安事故升級要送往不同責任人；三者可共用證據，但擁有者及處理急切性不同。
• 等待處理期間停止相關執行；若收件人、內容、目標或其他參數改變，必須重新驗證，不能沿用舊批准自動恢復。

團隊如何把邊界變成營運設計？

團隊應為每項用戶可見操作填寫一列能力設計畫布，並把每列直接連到可執行控制、證據、測試、營運指標和責任人。欄位至少涵蓋合資格行動者與驗證方式、資訊封套、會話及記憶、窄工具操作、行動身份及資源範圍、行動上限與批准、各類運作限制、拒絕與安全部分協助、證據紀錄、評估情境、監察指標及升級擁有者。畫布若只是一份文件而沒有工具政策、日誌事件、測試個案和停用權，便未成為服務控制。

三項能力可共用同一對話介面，卻不應共用資料權限、工具、授權、上限、指標或交接方式。OWASP 的監察指引涵蓋決定、工具呼叫、授權結果、批准識別碼、政策版本、結果、資源使用及異常權限模式，並要求遮蔽敏感資料；NIST 的管治成果亦強調清楚角色、溝通路線、人機責任、持續監察及定期覆核。實際紀錄應足以重建事件，但不應保存秘密或無限量原始敏感脈絡。

甚麼證據足以推出及持續營運助理？

推出前須有證據顯示獲准服務與預期拒絕都能在貼近部署的情況下運作，推出後則要持續監察，並在重大變更後重開相關評估。正面測試以外，還要覆蓋跨帳戶存取、未授權工具、過時或受污染檢索內容、禁止資料、繞過批准、批准後改參數、重複重試、依賴服務故障、資料外洩企圖及失控行動鏈。日誌須重建誰提出要求、採用哪項能力與政策、使用哪類來源及工具、發生甚麼授權與批准決定、最終行動和生效版本，同時遮蔽秘密並限制敏感內容。NIST 要求貼近部署的測試、安全失效及生產監察；NCSC 亦建議推出前保安評估及交代已知限制。

• 按能力監察非預期工具使用、重複拒絕、授權失敗、批准變更、異常行動次序、漂移、延誤、資源使用及故障。
• 分別指定服務行為、存取授予、業務交接及保安事故負責人，並賦予暫停、修訂或退役能力的權力。
• 模型、提示、檢索、記憶、工具、權限、政策、資料、供應商或營運環境有重大變更時，只重開受影響範圍並按風險調整覆核深度。

最實際的起點，是先推出最小而有用的一項能力，確認成功及拒絕情境都可觀察，才透過受覆核變更逐步擴權。能力若涉及敏感資訊、持久記憶、特權存取、外部承諾、破壞性改動或事故應變，應同步邀請機構的保安、身份、私隱、紀錄、風險及服務負責人；法律、監管或其他高風險專業判斷，則交由合資格專家及另行管治的流程處理。窄工具、最小權限、紀錄和測試只會收窄風險，並不保證消除提示注入、資料外洩或營運故障。