一份模板，用来记录 AI Agent 工具、权限、失败模式、负责人、控制措施和上线决策。
为什么需要工具风险登记表
工具调用是 AI Agent 从对话界面变成会影响真实世界的系统的地方。错误回答可能让用户不满，错误工具调用却可能发送邮件、修改记录、暴露数据、退款、开工单或触发其他系统信任的流程。工具风险登记表让团队在一个地方记录每个工具能做什么、可能出什么错、谁负责风险、上线前必须有哪些控制。
用普通语言描述工具
每一行先写普通人能懂的工具名称和说明，不要只写内部函数名。工程师理解 update_customer_status，但产品、安全和客服更容易评审“修改客户账号状态”。说明里应包括被影响系统、执行动作和用户可见后果。
拆分读取和写入范围
很多团队会低估风险，说工具只是“连接了 CRM”。登记表应该分别记录读取、写入、删除和外部通信范围。读取支持备注和更新支持备注不同；起草邮件和发送邮件不同；查询退款政策和执行退款也不同。
写出最可信的严重失败
每个工具都要写最可信的严重失败，而不是最夸张的想象场景。消息工具可能把错误或敏感消息发给客户；记录更新工具可能改错账号；检索工具可能跨租户取数。可信意味着在真实 prompt、过期数据、含糊请求或局部故障下可能发生。
定义审批策略
每个工具都应有审批策略。有些低影响工具可以自动运行；有些超过阈值才需要审批；有些永远需要人工确认；有些不应该暴露给公开 Agent。策略要写清原因，如果依赖角色、账号等级、金额、数据敏感度或置信度，也要写明。
记录校验和护栏
登记表应该包括工具周围的控制：schema 校验、允许值、租户检查、角色检查、确认提示、限流、dry-run、回滚和日志。“小心一点”的 prompt 不是控制；服务端拒绝跨租户账号 ID 才是控制。
分配负责人
每个工具都需要负责人，能在上线评审和事故时回答问题。负责人可能是维护集成的工程团队、负责工作流的产品经理，或敏感动作的安全负责人。没有负责人，工具会变成没人照看的风险点。
上线前链接证据
登记表不只列风险，还应链接证据：测试结果、trace、截图、审批示例、失败运行和事故演练记录。证据让评审更难流于形式。如果工具被认为低风险，证据要说明为什么；如果需要审批，证据要证明审批真的阻止执行。
每次重要变更后复查
prompt、模型、schema、目标系统或用户群变化时，工具风险都会变化。登记表不应只在首次上线时看一次。只读工具变成可写，需要复查；内部工具开放给客户，需要复查；审批规则放宽，也需要复查。
用登记表决定范围
登记表最终服务于上线决策。团队应该能据此判断哪些工具现在能开、哪些需要人工审批、哪些需要更多测试、哪些应该继续关闭。风险记录清楚后，团队可以先发布低风险工作流，把危险能力留在审批门之后。
如何使用这份资源
把这篇文章当作工作评审辅助，而不是法律认证、正式渗透测试或安全保证。真正有用的下一步，是把每个部分转成可复查的证据：trace、策略、测试样例、负责人、阈值和上线决策。
相关 IBBS 资源
可复制的分享文案
AI Agent 工具风险登记表模板：一份模板，用来记录 AI Agent 工具、权限、失败模式、负责人、控制措施和上线决策。 阅读链接：https://ibbs.ai/zh/2026/07/08/ai-agent-tool-risk-register-template-cn/
如果需要更完整的评审，可以先做 AI Agent 就绪度自评，或查看 样例审计报告。