背景
隨著 AI 代理（agent）承擔更多工作，安全領導者面臨如何保留人工監督的挑戰。雖然權限設定決定了代理可以執行哪些動作，但獲准的動作仍可能需要人的判斷。若要求每一步都進行批准，多步驟任務會產生重複的提示，甚至對例行動作也是如此。研究顯示，隨著重複次數增加，使用者對安全警告的注意力和遵循度會下降。因此，挑戰不在於要求更多批准，而在於將注意力保留給真正需要人工審查的決策。 AWS ML Blog
發生什麼事
Amazon Quick 推出 Smart Approvals 功能，旨在解決上述問題。該功能在現有控制措施內審查符合資格的動作，評估每個擬執行的動作是否符合使用者請求，並自動批准或退回給使用者審查。此過程不會授予額外權限，也不會移除必要的人工批准。安全領導者保留對哪些動作必須由人處理的控制權，而 Smart Approvals 旨在減少例行工作中的不必要中斷。 AWS ML Blog
重點內容
Smart Approvals 的運作基於政策邊界。Quick 在自動審查前，會根據 Custom Permissions、Quick Guardrails、連接器動作權限以及使用者設定來評估每個擬執行的動作。被拒絕的動作保持拒絕，強制性的人工批准仍然適用。只有當使用者設定為「每次詢問」且無其他控制措施要求人工批准時，動作才符合自動審查資格。管理員使用 Custom Permissions 決定誰可以使用 Smart Approvals。該功能預設開啟，但啟用預設拒絕（deny-by-default）的設定檔必須明確允許。使用者也可以為自己關閉 Smart Approvals，此選擇適用於所有對話和排程執行。 AWS ML Blog
在審查機制方面，Smart Approvals 使用一個獨立的模型，稱為分類器（classifier，用於判斷動作是否符合使用者請求的模型），來評估符合資格的動作。分類器考慮動作的內容、資料流向以及影響對象。它可以參考使用者的知識圖譜（knowledge graph），其中包含從連接來源提取的人員和工作關係，以理解收件人與使用者的關係（例如是否在報告鏈中）。此查找僅限於 Quick 帳戶內，且 Quick 不會使用分類器審查的內容（包括知識圖譜資料）來訓練模型或改進服務。即使動作符合請求，若涉及將內容發送給組織外或報告鏈中的高級領導者、變更存取權限、刪除記錄或啟動付款等情況，仍可能需要人工審查。 原文
分類器提供判斷，而權限服務執行授權。每個自動批准僅限於所審查的特定動作和參數，是一次性的，不授予持續權限。Quick 會在對話中標記自動批准。分類器未批准的動作、超時或其他審查失敗的情況會退回給使用者，絕不授予自動批准。此外，Smart Approvals 透過指示代理與分類器將檢索內容視為資訊而非指令，來協助防範間接提示注入（indirect prompt injection，檢索內容中的指令試圖重導代理行為）。然而，模型審查仍可能出錯，因此必須始終獲得人工批准的動作（包括移動敏感資料的動作）應透過連接器動作權限來強制要求。 原文
對使用者的意義
對於使用者而言，Smart Approvals 預設開啟，但管理員可透過 Custom Permissions 限制其使用範圍。建議從確認需要人工批准的動作是否已透過連接器動作權限配置開始。為了支援調查，應設置 AWS CloudTrail 軌跡，並將聊天日誌和代理元資料日誌傳送至 Amazon CloudWatch Logs。CloudTrail 事件歷史記錄保留 90 天，若需更長時間的調查，需配置軌跡。由於聊天日誌可能包含敏感內容，應限制存取並考慮使用 CloudWatch Logs 資料保護政策來遮蔽敏感資料。 AWS ML Blog
限制與未定事項
Smart Approvals 的自動批准標記並不證明權限服務已接受授權或動作已執行。調查人員需將這些事件與其他 Quick 活動進行關聯，並結合目標系統的記錄（如已發送的電子郵件或更新的工單）來確認動作是否完成。在擴展使用範圍前，建議先在定義明確的工作流上對試點團隊進行測試，並定義成功標準：減少例行動作的提示，同時確保重要動作仍退回給人工審查。 AWS ML Blog
