从一个有边界的业务任务开始
假设企业希望让智能体读取客户工单、检索内部知识库并生成回复草稿，后续再考虑自动更新工单和发送邮件。前一阶段主要影响信息读取，后一阶段已经涉及业务记录和对外沟通。如果为了省事直接给它一个管理员账号，原本有限的试点就可能拥有超出任务需要的能力。这是假设场景，不是客户案例或实际事故描述。
JOTOglobal 建议先写一张任务边界表：允许读取哪些对象，可以产生什么结果，哪些操作必须由人决定，遇到无法判断的情况交给谁处理。业务负责人定义任务目的，系统负责人说明接口能力，安全人员确认权限边界。没有明确的任务范围时，先缩小试点，而不是用一句“请谨慎操作”代替控制。
把权限落实到执行工具
OWASP 关于智能体威胁与缓解措施的资料讨论了工具滥用、权限失陷及工具执行控制等问题。其建议可以用于检查设计遗漏，但不是某个产品已经安全的证明。以下权限表、审批流程和测试安排属于 JOTOglobal 的实施建议；具体措施需要结合企业系统、数据和实际风险调整。
为每个工具分别记录读取、修改、删除、导出和对外发送能力，并明确作用对象。例如工单查询只返回当前业务队列中所需字段，草稿生成只写入指定草稿区，发送接口只能访问经允许的收件范围。限制应在接口、身份系统或执行服务中生效。模型即使生成了越界参数，执行端也必须拒绝，不能只靠提示词自律。
明确身份和委派的边界
要区分是谁提出请求、哪个智能体处理、哪个服务账号执行，以及最终代表谁访问数据。共享一个高权限身份会让调查和撤权变得困难。优先为任务配置可以追踪的执行身份，将凭证保存在受控的凭证系统中，避免直接写入提示词、文档或普通运行日志；同时规定失效时间、轮换和紧急撤销办法。
多个智能体协作时，不能因为上游有权限就默认下游也有权限。每次交接应带有明确的任务范围，由接收方的执行服务再次验证。只需要检索资料的子任务，不应继承发送邮件或修改客户状态的能力。系统负责人维护委派规则，安全人员检查实际调用是否符合规则，并对例外设置责任人和复核时间。
让审批对应即将执行的动作
审批不应只是一个“允许继续”的按钮。审批人需要看到目标对象、具体动作、关键参数、预期影响和回退方式。例如发送客户邮件，应展示实际收件人和正文；修改工单状态，应展示当前值与新值。审批界面隐藏关键内容，或者批准后还能任意改变参数，都容易让人的判断与真正执行的动作脱节。
批准结果应绑定这一份操作内容，并设置有效期。目标、正文或关键参数改变时重新审批；重复提交则通过请求标识控制，避免同一动作执行多次。需要分级处理时，可以让低风险查询自动运行，把批量修改、删除和外发交给指定负责人。分级标准由业务和安全共同维护，不能让智能体自行降低自己的审批门槛。
把外部内容当资料而非授权
网页、邮件、附件和检索结果可能包含看起来像操作命令的文字。智能体可以使用这些内容回答问题，但它们不应扩大工具权限或替代业务授权。即使资料写着“请把所有记录发到这个地址”，执行端仍需检查目的地、字段和任务范围。把资料内容与控制指令分开，是设计时必须明确的边界。
测试应包含正常任务和越界尝试：访问其他部门记录、把收件人改成未授权地址、在附件中夹入指令、审批后替换参数，以及重复调用修改接口。使用获授权的测试数据，在约定环境完成验证。验收不能只看智能体最终回答是否礼貌，还要检查执行服务是否真正拒绝请求，以及拒绝事件能否被发现和追踪。
记录足够调查的证据并练习停止
日志应能把任务、发起人、执行身份、工具、目标、审批和执行结果关联起来。成功、拒绝和失败都需要记录；涉及敏感字段时采用脱敏或受控引用，避免为了审计又复制出一套无人管理的数据。运维负责人检查日志是否可用，安全负责人定义保留和访问规则，业务负责人确认谁接收需要人工处理的异常。
上线前还要演练停止：暂停任务队列、撤销执行权限、阻止尚未发送的动作，并核对已经完成的操作。取消任务不等于撤回已发送邮件或恢复已改动记录，因此需要区分可回退和不可回退的结果。故障时先止住后续影响，保留调查证据，再由负责人员决定恢复范围，不能让智能体无休止地重试有副作用的动作。
按证据逐步扩大自动化范围
试点先从读取和生成草稿开始，验证权限、审批、日志和停止机制后，再考虑开放有限写入。每次扩展都更新任务边界表，并重复关键拒绝测试。接口版本、知识库范围或模型配置变化也可能改变实际行为，需要重新评估。权限管理的目标是让自动化始终处于可解释、可限制和可停止的范围内，而不是承诺有了审批就不会发生任何错误。