企业AI Agent权限怎么设计？最小权限、审批与审计清单

为什么提示词不能充当权限系统

普通聊天应用主要生成文本，AI Agent还可能查询数据库、更新CRM、发送消息、创建工单或调用其他业务接口。风险因此不只来自“回答错误”，还来自错误动作真正进入外部系统。把“不要越权”“重要操作先确认”写进系统提示词是必要约束，但它不能替代身份认证、服务端授权和接口本身的权限校验。

OpenAI在《A practical guide to building agents》中明确提出，guardrail应与认证、授权、严格访问控制和标准软件安全措施共同使用。对企业来说，正确边界是：模型可以建议下一步、选择候选工具和准备参数，但最终能否执行，必须由模型之外的确定性控制层决定。即使输入被提示注入影响，攻击者也不应因此获得更高权限。

第一步：先画清用户、数据、工具和动作矩阵

权限设计不要从“Agent很聪明，应该让它做什么”开始，而要从现有业务责任开始。先列出谁在使用、代表谁执行、允许读取什么数据、允许调用哪些工具、每个动作的业务影响，以及失败后能不能恢复。一个客服Agent可以读取当前客户的公开订单状态，不等于它可以读取全部客户资料；能够生成退款建议，也不等于能够直接提交退款。

FDE在项目启动阶段应把这张矩阵与业务负责人、安全负责人和系统Owner共同确认。矩阵越具体，后续越容易写成代码和测试；如果只写“按岗位授权”或“敏感操作需谨慎”，开发团队仍然不知道怎样拦截一次实际请求。

第二步：每次工具调用都在服务端重新鉴权

Agent不应持有一个可以跨用户、跨部门访问所有系统的通用超级账号。工具调用到达服务端后，要使用当前用户、组织、角色、资源和动作重新判断权限，并核对请求参数是否超出允许范围。模型输出的用户ID、部门ID或资源路径只能被视为不可信输入，不能因为格式正确就直接执行。

实现时可以把“模型决定做什么”和“系统允许做什么”分开。模型产生结构化工具请求，策略层完成身份绑定、资源范围过滤、参数白名单、速率限制和幂等检查，业务接口再执行具体动作。这样即使Agent选错工具或生成了异常参数，权限边界仍由确定性代码守住，也便于在不更换模型的情况下独立调整安全策略。

• 身份从受信任会话或服务令牌取得，不接受模型在参数中自报身份。
• 查询接口强制附加租户、部门或数据所有者范围，避免先全量读取再让模型过滤。
• 写接口校验允许字段、对象状态和重复请求，不能把整段模型输出直接拼入执行语句。

第三步：给工具分级，并把人工确认做成真实流程

OpenAI的Agent指南建议按照只读或写入、是否可逆、所需账号权限和财务影响评估工具风险，并在高风险动作前暂停或转交人工。企业可以据此建立低、中、高三级工具清单：低风险工具在授权范围内自动执行；中风险工具增加参数校验、频率限制或抽样复核；高风险工具默认要求明确审批。

人工确认不是在页面上放一个含糊的“继续”按钮。确认界面至少要展示即将调用的系统、目标对象、关键参数、可能影响和是否可撤销，让审批人知道自己批准了什么。对于批量发送、删除、资金、账号权限和对外发布，即使单次操作看似合理，也要检查累计范围，防止Agent通过多次小动作绕过单次阈值。

第四步：隔离凭据，限制Agent可获得的能力

不要把长期API密钥、数据库密码或管理员令牌放进提示词、知识库或模型可回显的上下文。凭据应保存在独立密钥系统或服务端连接层，由受控工具在执行时使用；Agent只看到必要的工具名称、参数结构和执行结果。能使用短期令牌时，不给长期凭据；能限制到单个接口、租户和动作时，不给整套系统权限。

还要控制工具返回的数据量。只读接口也可能泄露敏感信息，因此响应应按用户权限裁剪字段、限制条数并进行必要脱敏。日志中避免记录完整令牌和敏感原文，报错信息也不应把内部连接信息返回给模型。权限收紧后如果业务流程无法运行，应补充明确的授权路径，而不是临时把Agent账号升级为管理员。

第五步：审计日志必须能还原一次Agent决策和动作

审计的目标不是简单保存一段对话，而是能够回答：谁在什么时间发起任务，Agent使用了哪个版本和策略，读取了哪些资源，准备调用什么工具，服务端为何允许或拒绝，谁批准了高风险动作，最终外部系统发生了什么变化。关键写操作还应记录请求ID、变更前后值或业务系统返回的可追踪编号。

审计记录应与业务数据分开控制访问权限，并设定保留期限和脱敏规则。发现异常时，团队需要能按用户、工具、资源和时间范围定位影响，并立即停用某个工具或撤销某类令牌。对于可逆操作，要在设计阶段确认补偿动作；对于不可逆操作，则应把审批和范围限制放在执行前，而不是指望事后用日志补救。

• 为一次Agent运行生成统一追踪ID，串联模型步骤、工具调用、审批和业务结果。
• 记录授权策略命中结果与拒绝原因，但不记录明文密钥和不必要的敏感数据。
• 准备工具级熔断、令牌撤销和人工接管入口，异常时不必等待整套系统下线。

第六步：用攻击样本和灰度运行验证权限边界

OWASP Top 10 for Agentic Applications把Agent目标劫持、工具滥用、身份与权限滥用等列为专门风险。上线前测试不能只覆盖“正常用户能完成任务”，还要主动构造越权和误操作场景：诱导Agent忽略规则、伪造资源ID、请求其他部门数据、把只读任务改成写入、连续触发多次小额动作，以及在工具报错或超时时重复执行。

NIST的生成式AI风险管理资料强调把治理、测量与管理放进系统生命周期。对应到Agent项目，就是权限测试不能只做一次。每次新增工具、扩大用户范围、修改审批阈值或更换关键流程，都要复跑安全样本。首轮上线只开放少量用户和低风险工具，确认拒绝、审批、审计和回退都真实可用后，再逐步放开能力。

FDE交付时应带走的AI Agent安全清单

一套可验收的企业AI Agent权限方案，至少应交付用户与资源矩阵、工具风险清单、服务端授权规则、审批界面与流程、凭据管理方式、审计字段、异常告警、熔断与回退步骤，以及一组可重复执行的越权测试。业务方应能根据这些材料判断当前Agent被允许做什么、被禁止做什么、出现异常由谁处理。

如果你的企业正在把AI Agent接入CRM、ERP、工单、客服或内部数据系统，可以通过点煜科技官网底部的企业AI项目咨询入口提交当前流程、目标用户、计划接入的工具和最担心的风险。点煜科技会先帮助核对场景边界、权限依赖和灰度范围，再给出可实施、可审计、可回退的FDE交付方案。