設計有邊界的 AI 助理：從工具權限到脈絡限制

一套以使用者可見能力為單位的實作方法，協助產品、資安、身分管理與服務團隊逐項界定 AI 助理可用的資料、身分、工具及動作上限，並把授權、核准、拒絕、稽核證據、上線測試與變更複核接到真正可執行的控制點；另以內部客服情境示範查詢、擬稿與寄送為何必須分權，避免只靠系統提示詞管理風險。

ModelFold Editorial Team2026年7月26日11 分鐘閱讀

AI 助理
AI 代理
工具權限
脈絡限制
最小權限
AI 治理
AI 評估

AI 助理真正的邊界，是模型外圍可執行的服務契約，不是系統提示詞裡的一串「不得」條款。就算提示詞寫著不可寄信，只要助理仍持有寄送工具和可用憑證，禁令就可能在錯誤判斷、惡意內容或流程缺口下失效。設計工作因此要從每項使用者看得見的能力著手，分別限制它能讀什麼、以誰的身分行動、能呼叫哪個窄化工具、最多改變多少外部狀態，以及何時必須停止或交給人員處理。

先抓住五個控制原則

有邊界的 AI 助理是一份可執行的服務契約，不是一段列滿禁令的提示詞。
查詢、摘要、擬稿、更新、寄送、刪除與核准應視為權限各自獨立的能力。
脈絡限制必須涵蓋資料資格、範圍、時效、信任、工作階段、記憶與禁止資料。
身分驗證、資源授權與單次動作核准回答不同問題，核准不會創造原本不存在的權限。
上線證據既要證明允許的工作能完成，也要證明越界時能可靠拒絕、停止或升級處理。

AI 助理究竟可以做哪些事？

一名女子和一名男子在明亮辦公室的木桌上整理空白任務卡，旁邊放著素面筆記本和蓋好筆帽的彩色筆。

團隊應先寫出一句服務章程，再把它拆成具體能力。可採用這個句型：「對於符合資格的使用者，助理可運用經核准的資訊範圍，執行指定任務並產生允許的結果，但不得處理明列的非目標或後果重大的決定。」章程至少要說清楚使用者、部署場景、支援任務、知識限制、人員監督、風險負責人與禁止結果，之後才適合接上工具。

「協助客服」或「管理信箱」太寬，無法成為可檢查的控制單位。應改寫成搜尋案件、摘要紀錄、提出建議、建立草稿、更新指定欄位、寄送訊息、刪除資料或核准動作；每個動詞都有自己的資料需求、權限與失敗後果。NIST 要求記錄用途、支援任務、應用範圍與知識限制，OWASP 則建議提供最小工具功能；本文的能力拆分法是依這些原則整理的實務綜整，並非兩者規定的標準格式。

把「協助」改成可觀察的輸出，例如查到案件摘要或建立非最終草稿。
把讀取、寫入、寄送、刪除與核准拆開，不讓低風險需求順帶取得高權限。
為每項能力寫明不做什麼，包括不替負責人作承諾、不繞過專業判斷。
尚未有控制、測試與負責人的能力，維持關閉，而不是先靠提示詞暫擋。

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

戴白手套的檔案專員從開放式檔案架上挑選資料夾，旁邊的同事正在關好並鎖上獨立的灰色櫃子。

脈絡限制應是一個「資訊範圍」，界定資料資格與信任邊界，而不只是模型可容納多少字元。每項能力都要列出可用系統、紀錄類型、資料分類、物件篩選條件、日期與新鮮度、使用者原有權限，以及絕不可進入脈絡的資料。若必要證據無法存取、已缺漏或過時，助理應說明限制、縮小結論或拒絕回答；更大的脈絡視窗不會增加權限，也不會讓缺乏證據的內容變真。

檢索到的文件、外部訊息、附件與 API 回應都應視為不受信任內容，資料中的命令不能無聲地升格成服務指令。工作階段歷史與持久記憶也要分開治理：前者回答本次對話保留什麼，後者則要規定哪些內容可寫入、寫入前如何驗證、如何隔離不同使用者與工作階段、何時到期或刪除，以及哪些機密或敏感資料永遠不得保存。

來源：哪些系統、文件庫與 API 可被使用。
資格：使用者本來看得到哪些帳戶、案件、欄位與時間範圍。
信任：哪些內容只是資料，不能改寫系統指令或工具政策。
時效：證據多舊便須標示、補查、縮小回答或停止。
記憶：可否持久化、如何隔離、何時到期，以及如何受理刪除。
禁區：憑證、權杖、無關帳戶與未核准的敏感內容不得進入脈絡。

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

門禁管理員在辦公桌前把一張空白門禁卡交給員工，同時保留一大串金屬鑰匙，桌上還有分格鑰匙托盤。

身分驗證、資源授權與動作核准必須分開判斷，真正的資源與操作限制則由工具閘道及下游系統執行。身分驗證回答「目前是誰或哪個工作負載」；授權回答「這個身分能否對特定資源執行某個動詞」；核准只回答「負責人是否接受眼前這項已具授權的提案」。模型可以協助理解意圖，卻不能自行授予權限，提示詞或自然語言護欄也不是授權控制。

每項能力都應明選委派使用者身分或受控工作負載身分，不可默默沿用高權限管理者帳號。工具介面宜只暴露用途明確、參數可驗證的操作，例如「讀取可見案件摘要」，而不是整個資料庫、信箱、瀏覽器或命令列。執行路徑還要限制動詞、資源、物件、欄位、目的地、憑證有效期與權杖對象；速率、重試、鏈深、批次、費用、時間、冪等、回復與斷路條件則依服務風險設定，不套用萬用數字。

確認提出請求的人員、用戶端或工作負載如何完成身分驗證。
逐一授權操作、資源、物件與欄位，而非授予模糊的全面存取。
讓權杖只對預定資源有效，並縮短不必要的憑證暴露時間。
在下游系統重新檢查授權、參數與政策，不接受模型自行宣稱已通過。
對受保護 MCP 整合採用其最小範圍與資源綁定機制，但不把 MCP 規格誤當所有工具的通則。

對話可以連續，權限卻應拆成小而獨立、能逐項強制執行的能力。
ModelFold 編輯部

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

倉庫主管拿著無字授權標籤檢查密封紙箱，旁邊的工作人員穿著安全背心，在滾筒輸送帶旁等待。

每項能力都需要明確的動作上限；越接近改變外部狀態，越要增加獨立且可驗證的控制。實務上可由回答或摘要、建議或提案、建立草稿、有限且可回復的寫入，逐步走到會產生重大外部效果的動作；另有一類是服務永遠不得做的決定。這套階梯是依 OWASP 與 NCSC 控制原則整理的編輯方法，不是通用風險分級，也沒有適用所有組織的固定門檻。

回答或摘要：只從合格證據產生資訊，不改變外部狀態。
建議或提案：提出下一步或可檢查的動作內容，但不執行。
草稿：只寫入非最終工作區，保留具名審閱者，不能形成對外承諾。
有限可回復寫入：僅更動核准欄位，並具備驗證、冪等或回復機制。
重大外部動作：寄送、發布、刪除、付款、授權或部署前，須檢查精確預覽、授權與單次核准。
禁止決定：能力本身不存在，下游系統也拒絕，轉交合格人員或另一套受治理流程。

重大動作應先呈現可檢查的預覽，再把核准綁定至行動者、工具、目標資源、正規化參數、時間與到期點；收件者、內容或其他關鍵參數一旦變更，就要重新驗證。核准不會補足缺少的授權、不會擴張常設權限，也不能把禁止事項變成允許事項。付款、存取權授予、破壞性操作、生產變更、重大對外承諾與高風險專業判斷，仍應置於合格負責人及確定性政策的控制下。

AI 助理碰到邊界時應該怎麼做？

服務櫃檯職員把黑色文件夾合著，並打電話叫正在走近的主管；櫃檯另一邊的女顧客正用手勢交談。

拒絕、安全的部分協助、人員轉接與資安升級都應是正式服務結果，並設有真正停止執行的條件。助理要用平實語句說明邊界，但不能洩露敏感政策細節，更不能假裝資料已查到、工具已呼叫、核准已取得或寫入已成功。若仍有安全範圍，可以交付草稿、檢查表或缺件清單；若涉及權限、專業判斷或安全訊號，就應把工作送到負責的目的地，而不是反覆嘗試。

任務不在服務範圍內
要求的資訊不符合資格
身分缺少必要授權
動作尚待負責人核准
證據缺漏或已過時
需要政策負責人或合格專業人員判斷
工具或相依服務無法使用
已達服務設定的操作限制
偵測到權限提升、資料外洩、記憶污染或遞迴工具濫用等安全訊號

轉交資料應包含原始目標、必要且非敏感的脈絡、嘗試過的能力、停止原因、已有或缺少的證據、建議下一步與追蹤識別碼。一般使用者轉接、業務核准與資安事件升級可以共用部分證據，卻有不同負責人與急迫性；安全事件還要接上受訓人員、撤銷能力、補救情境及稽核紀錄。等待期間必須暫停執行，提案若有變更則重新驗證，不可沿用先前核准自動恢復。

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

營運負責人坐在會議桌旁，把綠色、藍色和黃色的空白資料夾分別放進顏色相配的托盤，進行控制流程演練。

團隊應為每項使用者可見操作各填一列能力設計畫布，並把每列連到可執行控制、證據、測試、營運指標與負責人。欄位至少涵蓋合格行動者與驗證方式、資訊範圍、工作階段與記憶、窄化工具、行動身分及資源範圍、動作上限與核准、操作限制、拒絕方式、紀錄、評估案例、升級目的地和可暫停或退役能力的服務負責人。畫布若只停在文件裡，沒有對應閘道、政策與告警，就仍不是控制。

同一個內部客服介面中的三項能力，必須保有不同資料、權限、測試與責任
能力	資訊與工具邊界	動作上限與核准	證據、測試、指標與負責人
查找並摘要合格案件	以客服人員委派身分唯讀存取其原本可見的指定帳戶與案件；排除其他帳戶、憑證及隱藏管理註記。	只能回答或摘要；資料不可見、證據過時或缺乏支持時拒絕或標示限制。	記錄能力、政策、案件與檢索結果類別；測試跨帳戶、隱藏註記、過時證據及附件中的惡意指令；監看合格檢索與邊界拒絕，由服務負責人處理資料品質或安全例外。
建立客服回覆草稿	使用合格案件、核准知識文章及回覆政策，只能寫入非最終草稿區，沒有寄送權限。	上限是草稿；欠缺政策依據、涉及未授權承諾或敏感資料時，留下缺口並交由具名審閱者。	記錄來源、範本、政策、草稿與審閱結果；測試無依據主張、敏感內容和檢索文字中的對抗指令；監看未支持標記與審閱處置，由內容或政策負責人解決判斷缺口。
寄送已核准回覆	另設窄化寄送操作，使用只對指定客戶管道有效的委派身分或受控服務身分；驗證收件者與核准內容參照。	屬重大外部動作；執行前驗證授權、核准效期、正規化參數與防重複狀態，任何關鍵內容變更都停止寄送。	記錄寄件身分、收件者、管道、內容參照、核准與執行結果；測試改收件者、改內容、核准過期、重複重試及管道故障；監看寄送結果和不符提案的拒絕，由訊息服務負責人與人類寄件者分別承擔技術及業務責任。

上線及持續營運需要哪些證據？

品質團隊圍在測試室桌旁，查看帶勾、叉和箭頭符號的彩色標記及密封測試信封，其中一人用筆記錄觀察結果。

上線前要證明允許的服務與預期的拒絕，都能在貼近實際部署的條件下運作。測試不能只放入順利案例，還要涵蓋跨帳戶存取、未授權工具、過時或遭污染的檢索內容、禁止資料、繞過核准、核准後變更參數、重複重試、相依服務中斷、資料外洩企圖與失控工具鏈。限制與失敗模式也要讓操作人員及使用者看得懂，通過一次測試並不代表日後永遠安全。

紀錄誰提出什麼請求，以及套用哪項能力、政策與版本。
保留使用過的來源及工具類別、授權和核准結果，以及最終動作狀態。
遮蔽秘密並限制敏感內容，不把完整提示與對話無限期保存當成可追溯性。
監看意外工具使用、重複拒絕、授權失敗、核准變更與異常動作序列。
依風險與隱私要求追蹤漂移、延遲、資源使用、失敗及安全相關行為變化。
分別指定服務行為、存取授予、業務轉接與資安事件的負責人及暫停權限。

模型、提示詞、檢索、記憶、工具、權限、政策、資料、供應商或營運情境若有重大變更，就應重開受影響能力的測試、權限檢視與上線證據，而不是只改提示詞後直接續用。最穩健的擴張方式，是先推出最小但有用、允許與拒絕結果皆可觀察的能力，再透過受審查的變更增加權限。凡涉及敏感資訊、持久記憶、特權存取、外部承諾、破壞性變更或事件處理，都應及早納入資安、身分、隱私、紀錄、風險與服務負責人；法律、監管及其他高風險專業判斷則轉交合格專家與獨立治理流程。