透過結構化事件進行 AI 代理安全監控
在工具讀取受保護資料、更改狀態、執行程式碼或呼叫外部系統之前，記錄授權決定。記錄請求的操作類別、政策版本、應用程式是允許、拒絕還是將操作送交核准，以及最終結果。不要在這些事件中包含提示詞或工具酬載。
Telemetry 讓你用 SQL 查詢這些結構化決策。它不會執行授權控制、在沙箱中執行工具、隔離租戶、管理機密，也不會取代保存安全證據的系統。應用程式和原則層必須負責執行這些控制。只傳送經過核准且檢視長期行為所需的欄位。
從工具和風險清單開始
列出代理可以發現或呼叫的每個工具。根據它可以產生的效果而不是友好的顯示名稱對其進行分類：
| 動作類 | 範例 | 典型的複習題 |
|---|---|---|
read_only |
搜尋經批准的公共索引 | 結果是否會暴露受限資料或跨越租戶邊界？ |
local_state_change |
在隔離的工作區中寫入生成的檔案 | 目的地是否已確定範圍且可恢復？ |
external_state_change |
更新票證、資料庫行或雲資源 | 行動者是否有權執行確切的目標和操作？ |
code_execution |
執行命令或作業 | 適用哪些隔離、許可名單、時間限制和資源限制？ |
credential_use |
使用委派憑據呼叫服務 | 憑證的範圍是否僅限於使用者、資源和請求的操作？ |
風險分類是產品和安全決策。不要將此範例作為策略複製到生產中。與擁有授權、事件回應、隱私和受影響系統的人員一起定義受控值。
大型語言模型應用程式的 OWASP Top 10 將即時注入、不安全的輸出處理、過度代理和敏感資訊洩露等風險視為不同的問題。監控授權決策可以幫助調查這些邊界，但儀表板本身並不能緩解問題。 OWASP 提示注入指導 還解釋了為什麼不可信內容會影響模型行為，即使應用程式並不打算將其充當指令。
執行前記錄政策決定
每個最終策略決策使用一個 agent_tool_authorization_decided 事件。它的粒度是一種邏輯工具呼叫嘗試，而不是一種模型回應，也不是一次完整的代理執行。建議的欄位包括：
event_id、timestamp_utc、run_id和tool_call_id用於同一性和相關性；workflow、tool_name和action_class作為有界操作尺寸；risk_level、decision、reason_code、policy_version作為受控策略欄位；release、environment和用於變更分析的隱私安全account_id。
代理工具授權事件架構 記錄了完整的入門合約。將 decision 限制為 allowed、denied 和 approval_required 等值。諸如 scope_denied 或 human_approval_required 之類的原因比自由形式模型解釋更安全且更具可比性。
請勿包含原始提示、完成、工具參數、工具結果、檢索到的文件、授權標頭、cookie、權杖、連線字串或客戶內容。工具名稱應該是穩定的識別符號，例如 database_write，而不是序列化的函式呼叫。
將決策和執行結果分開
授權回答該操作是否可以繼續。它並不能證明執行成功或業務成果是安全的。發出單獨的終端事件，例如具有相同 run_id 和 tool_call_id 的 agent_tool_completed。
| 活動 | 穀物 | 有用的結果 |
|---|---|---|
agent_tool_authorization_decided |
一項最終政策決定 | 允許、拒絕或需要批准 |
agent_approval_resolved |
一項已完成的人工審查 | 批准、拒絕、過期或取消 |
agent_tool_completed |
一次終端執行嘗試 | 成功、失敗、超時或取消 |
agent_run_completed |
一個終端代理執行 | 任務成功、失敗或人工交接 |
agent_policy_changed |
一項已發布的政策變更 | 先前版本、新版本、所有者和部署 |
將這些顆粒分開可以使重要情況變得可見：允許的呼叫可能會失敗，批准可能會在不執行的情況下過期，技術上成功的工具呼叫仍然可能導致代理結果被拒絕。
在資源伺服器上申請授權
對於模型上下文協議部署，請在實現邊界遵循協議的授權和安全指南。 MCP授權規範 描述了授權職責，而 MCP 安全最佳實踐指南 則涵蓋了已部署系統的威脅和緩解措施。 MCP 工具規範 將工具註釋視為提示而不是可信的安全邊界。
在實踐中：
- 在擁有受保護資源的程式碼中做出策略決策。
- 驗證參與者、租戶、目標資源、操作和委託範圍。
- 您的策略標記為重要的操作類別需要人工批准。
- 僅在評估最終後才發出有界決策。
- 僅當執行層允許時才執行該工具。
- 執行後發出單獨的終端結果。
切勿依賴模型自行報告某項操作已獲得授權。同樣，不要將工具描述或註釋視為操作是隻讀或安全的證據。
使用 SQL 審查拒絕、批准和政策更改
AI代理工具授權SQL菜譜 按工具和風險類別對決策進行分組。除了拒絕率之外，它還保留絕對計數，因此微小的樣本不會造成虛假的緊迫性。
有用的儀表板包括：
- 按工具、工作流程、風險級別和發布進行總體決策；
- 允許、拒絕和需要批准的計數；
- 具有明顯決策分母的拒絕率；
- 批准佇列年齡和解決結果；
- 允許後來失敗的操作；
- 政策版本變更前後的決策組合。
仔細解釋這些訊號。預期的否認可以表明政策正在發揮作用。拒絕率的下降可能反映了更安全的代理發布、更弱的策略或流量的變化。不斷成長的審批佇列可能是所有權問題，而不是攻擊。
制定調查時間表
將決策、批准、工具結果和執行結果與 run_id 和 tool_call_id 關聯起來。對於審查的事件視窗，重建：
- 哪個工作流程和發布請求了該操作；
- 哪個政策版本對其進行了評估；
- 有界決策和原因程式碼；
- 人類是否批准或拒絕它；
- 執行是否開始以及如何結束；
- 代理執行是否完成、失敗或移交。
在為完整性、存取、保留和刪除要求而設計的系統中保留詳細的證據。一般分析可以識別模式並提供可重複的時間表，但在沒有經過驗證的控制的情況下，不應將其呈現為合規性存檔。
在發出警示之前驗證故障路徑
對允許、拒絕、需要批准、批准過期、執行失敗和策略版本更改路徑進行綜合案例。確認：
- 每個相應的工具呼叫都會收到一個最終決定；
- 被拒絕的呼叫不執行；
- 需要批准的通話不能繞過審查；
- 相關識別符號僅連線預期的顆粒；
- 禁止的內容永遠不會到達事件有效負載；
- 遙測缺失並不會削弱執法力度；
- 警示使用經過審查的閾值、足夠的數量和明確的所有者。
從 AI 代理安全用例 開始獲取實施提示或複製 AI代理安全稽核範本。對於成本、延遲、重試和工具可靠性，請使用 AI代理監控。對於代理邊界之外的身分驗證和管理操作，請使用更廣泛的 安全稽核分析指南。