通过结构化事件进行 AI 代理安全监控
AI 代理安全监控应从应用程序做出可执行决策开始：在工具读取受保护数据、更改状态、执行代码或调用外部系统之前。有用的遥测不是提示或工具有效负载的副本。它是一个有界记录，记录了所请求的操作类、哪个策略版本对其进行了评估、是否允许、拒绝或路由至批准，以及随后的最终结果。
Telemetry 是这些结构化决策的分析界面。它不会强制执行授权、沙箱工具、隔离租户、管理机密或替换保留安全证据的系统。在应用程序和策略层中保持执行，然后仅发送随时间审查行为所需的已批准维度。
从工具和风险清单开始
列出代理可以发现或调用的每个工具。根据它可以产生的效果而不是友好的显示名称对其进行分类：
| 动作类 | 示例 | 典型的复习题 |
|---|---|---|
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代理监控。对于代理边界之外的身份验证和管理操作，请使用更广泛的 安全审计分析指南。