AI Agent怎么做权限控制？从工具白名单到人工确认的安全设计指南

AI Agent能够根据任务调用搜索、订单、邮件、数据库等工具，但“会调用”不等于“应该允许调用”。安全设计的重点，是让模型负责提出行动建议，由受控的执行层判断是否可以执行，并由业务系统承担最终权限校验。

一、先拆分三层权限

第一层是模型决策权限：模型只能生成行动计划、选择候选工具和填写参数，不能因为输出了一段文本就直接获得数据库、支付或管理权限。第二层是工具执行权限：执行服务根据用户身份、会话状态、工具白名单和参数规则决定是否放行。第三层是最终业务权限：订单系统、财务系统或内容系统再次校验操作者是否有权完成具体业务。

这种分层可以避免把模型输出当成可信指令。例如，客服Agent可以建议查询某个订单，但订单服务仍应验证当前客服的账号、所属组织和订单访问范围。

二、用白名单限制可调用工具

不要让Agent直接访问任意函数或通过自然语言拼接命令。应为每个场景配置明确的工具白名单，并为工具定义用途、输入字段、访问范围和风险等级。

• 只读工具：如订单查询、库存查询和知识库检索，通常不应包含修改数据的参数。
• 低风险写入工具：如创建内部待办，可限制目标项目、字段范围和调用频率。
• 高风险工具：如删除数据、转账、发送外部邮件或修改权限，应默认关闭自动执行。

白名单还应区分用户、租户、环境和会话。例如测试环境的工具不能自动映射到生产环境，客服只能查询与当前业务关联的订单。

三、做好身份、参数和最小权限校验

每次调用都应携带可验证的用户身份、租户信息、会话标识和请求来源，不能只相信模型提供的用户字段。执行层应重新从可信的登录会话或服务端上下文中取得身份信息。

参数校验至少包括类型、格式、长度、取值范围和对象归属。查询订单时，应检查订单是否属于当前用户可访问的组织；发送邮件时，应限制收件人域名、附件类型和附件大小；删除操作则应要求明确的资源标识，拒绝模糊条件或批量范围过大的请求。

最小权限不仅是“能不能调用”，还包括“能调用到什么程度”。可为工具使用专用服务账号，只授予必要的表、字段或接口权限，并设置短时效凭证，避免长期持有高权限密钥。

四、为高风险动作设置人工确认

删除、转账、发布内容、修改权限和向外部发送消息等操作，应采用人工确认或二次审批。确认界面不能只显示“是否执行”，而要展示具体影响范围，包括操作对象、收件人、金额、正文、附件、预计变更和风险提示。

例如，自动化助手准备发送邮件时，应先展示收件人、主题、正文和附件，由用户明确确认后再调用发送工具。如果确认后关键参数发生变化，应使原确认失效并重新确认。对于金额较大、批量对象或敏感数据操作，可以增加第二审批人或限定审批时效。

五、保留完整调用审计

审计记录应覆盖请求时间、用户和租户、会话标识、模型提出的工具、最终放行的工具、参数摘要、策略判断、执行结果、失败原因和审批记录。敏感字段应按业务要求脱敏或加密，日志访问本身也需要权限控制。

记录模型原始建议与执行层最终决策，有助于区分“模型提出了什么”和“系统实际做了什么”。运营人员可据此发现异常调用频率、反复失败、越权尝试和策略误拦截，并持续调整规则。

六、设计超时、撤销、重试和回退

工具调用应设置超时和最大重试次数，避免下游异常导致资源长期占用。重试前要判断操作是否幂等：查询通常可以重试，发送邮件或扣款则应使用幂等键、请求流水号或状态查询，防止重复执行。

对可撤销操作，应提供撤销窗口或补偿流程；对不可逆操作，应在执行前再次确认并降低自动化程度。工具失败时，Agent不应自行假设成功，而应明确返回“未确认执行结果”，将任务转人工或进入待处理队列。

七、上线前检查清单

1. 是否明确区分模型决策、工具执行和业务最终授权？
2. 是否为每个场景配置工具白名单和最小权限？
3. 是否校验真实用户身份、资源归属和全部关键参数？
4. 高风险操作是否需要展示详情并获得人工确认？
5. 是否记录请求、参数、审批、结果和失败原因？
6. 是否具备超时、幂等、撤销、重试和异常回退机制？

权限控制的目标不是让Agent完全不能行动，而是让每次行动都具备清晰边界、可验证条件和可追溯结果。提示词可以帮助模型遵守规则，但不能替代服务端鉴权、业务校验和审计机制。