AWS 提出 Trust in Depth 框架，以四層檢查擴大 AI 代理自主權

背景

AI 代理（能自行挑選工具、安排步驟來完成任務的 AI 程式）的用處來自自主性，但文章指出，這也讓它難以被信任：同一個任務跑兩次可能走不同路線，今天通過的測試，說明不了它明天會怎麼做。作者表示，企業主管都想讓代理做更多事，卻不信任它每次都做對。常見解法是讓人逐一核准代理的動作，文章認為這在小規模可行，但工作量增加後核准會堆積、產生審核疲勞，負責檢查的人反而漏掉重要問題。 AWS ML Blog

發生什麼事

AWS ML Blog 於 10 月 15 日發表文章，提出名為 Trust in Depth 的做法。它借用 Defense in Depth（縱深防禦，以多層獨立防護降低風險的資安做法）的分層思路，文章說業界已實踐這套方法 two decades（二十年）。差別在於 Defense in Depth 限制可能出錯的範圍，Trust in Depth 則用來擴大可以安全放手的範圍。框架在代理生命週期的四個時點提出問題：執行前的 Scope（這個代理做什麼、需要哪些能力、絕不能做什麼）、部署時的 Know（誰授權、帶著什麼身分）、執行中的 Bound（動作是否留在設定的界線內）、每次執行後的 Observe（能否重建代理做了什麼與原因）。 AWS ML Blog

重點內容

框架的技術核心是 automated reasoning（自動推理，用數學邏輯檢查一條規則是否在所有可能情況下都成立）。文章說 AWS 已在正式環境使用自動推理超過十年，其中 IAM（身分與存取管理，控制誰能存取哪些雲端資源的服務）處理量達每秒超過 2.1 billion 次請求，現在要把它用到代理上。可精確表述的規則能被證明，例如「Only a manager can approve access」（只有經理能核准存取）；「Keep a friendly tone」（保持友善語氣）則無法證明，這類情況應限制代理的存取與動作、評估其行為，並把真正模稜兩可的情況交給人判斷。 AWS ML Blog

在 Scope 層，Kiro（AWS 的代理式程式開發系統）會把高層意圖轉成以規格驅動的結構化需求，在寫程式前用自動推理找出矛盾、模糊與缺漏，並產生 property-based tests（以大量不同輸入檢查實作是否符合需求的測試）。Strands 提供開源工具組，用來定義代理的模型、指令與工具，另有代管的執行環境。Amazon Bedrock AgentCore 的 Policies 功能讓使用者用白話描述代理可接觸的工具、API（應用程式介面，程式彼此呼叫的接口）與資料，在政策生效前由自動推理檢查是否授權過多，或是否有永遠無法被滿足的矛盾規則。文章舉例，若為了一項任務給代理管理員角色，代理可能繼承整個環境的權限。 AWS ML Blog

在 Know 層，AWS Agent Registry 是代管且經核准的目錄，收錄組織內的代理、MCP（Model Context Protocol，讓 AI 連接外部工具與資料的協定）伺服器、工具與技能；管理員透過核准流程決定哪些項目可被搜尋到，並移除不再符合安全、合規與品質標準的項目。AgentCore 會發給每個代理獨立身分，並在每次請求時檢查，讓每個動作都能追溯到特定代理與其授權來源。談到 Bound 層時，文章指出代理可能每一步都經過核准，走完 10 步卻得到沒人預期的結果，因此需要設下界線。 AWS ML Blog

對使用者的意義

這套框架主要針對想把更多工作交給 AI 代理的企業與開發者。文章建議把最多心力放在執行前的 Scope 階段，因為在這裡發現的問題修正成本最低；做法包括只給代理完成工作所需的權限，留意隨工具或角色附帶、沒人刻意授予的能力。文章也提出放權的條件：確認相關規則有被執行、代理在任務上表現可靠、失敗能被偵測與處理之後，再逐步給予更多自主權。作者表示，不論選用哪種框架，定義代理工作與界線的責任都一樣。 AWS ML Blog

限制與未定事項

文章明說，自動推理只適用於能精確表述的規則，其證明結果的品質取決於背後的規則與假設；測試則只能顯示控制機制在預期情況下有效，代理可能走出未預期的路徑。作者也承認，把人類意圖轉成完整且可執行的政策需要精確與完整，是整套流程中最困難的部分。 AWS ML Blog