把多个 AI Agent 放进一个生产系统，很多团队遇到的第一课不是模型不够聪明，而是"谁在真正为一次操作负责"。一个 Agent 判断客户问题已经解决准备关单，另一个从新消息里识别出补充问题准备重开，第三个按日报任务更新状态。三个判断单独看都有道理，也都拿到了同一个写接口，几十秒后同一条记录被连续改写，最后没人能说清状态是怎么变成这样的。
多 Agent 协作最危险的时刻，往往不是某个 Agent 答错了，而是每个 Agent 都按自己的指令"答对了"，然后一起改动了同一个真实对象。安全问题的性质也因此从"模型说了什么"变成"模型做了什么"。权限怎么隔离、越权怎么防、动作怎么追溯，成为多 Agent 上生产前必须先回答的问题。
为什么多 Agent 协作让安全问题更难管
单个 Agent 的行为边界相对清晰：一个身份、一套权限、一条调用链，出问题可以用常规的权限拦截和操作审计去约束。多 Agent 协作把这条边界打散了。
第一，多个 Agent 会并发操作同一个共享对象。工单、订单、配置文件这类真实资源一旦被两个以上 Agent 同时读写，就会出现竞态，且每次写入都来自不同 Agent，事后难以判定哪个动作是最终结果。
第二，Agent 之间的消息传递扩大了注入面。提示注入不只来自用户输入，还可能藏在一封邮件、一个网页、一段文档里。某个 Agent 读取外部内容后被诱导，又通过协作消息把恶意指令传给下游 Agent，风险就在系统内部横向传播。
第三，子 Agent 可能绕过父 Agent 的限制。现实中常见的情况是：一个只被授权查询数据的 Agent，在处理复杂任务时通过子代理绕过了权限边界。协作链条越长，这类权限冒用越难被发现。
第四，责任归属变得模糊。分工回答了"谁应该做什么"，但回答不了"意见冲突时谁的决定生效、条件变化后谁能让它不生效"。OWASP 面向 Agentic 应用的威胁清单里，目标劫持、工具滥用、身份与权限滥用都被列为高危项，原因正是 Agent 一旦拥有真实执行权，一次越权操作就可能造成不可逆影响。
先把五类控制权收回运行时
不少团队把安全约束写进 Prompt，例如"请谨慎操作""未经确认不要删除"。这类自然语言约定无法可靠地暂停一个队列、拒绝一次过期写入、缩小一份授权或限制一次事故的损害半径。Agent 回复"我已停止"并不等于任务真的停了。
多 Agent 系统一旦接触共享对象和真实写操作，运行时就应该统一掌握五类控制权：终止、状态、权限、动作、范围。
以权限为例，要区分"职责"和"控制权"。"执行 Agent 负责写回数据"是一项职责，可以写进角色说明；"只有运行时在审批通过之后才能发出写请求"才是一项控制权，必须由系统强制执行。前者靠约定，后者靠代码。Agent 可以保留局部判断，但只要一个决定同时涉及多个 Agent、共享对象和难以撤销的后果，最终决定权就应收回到一个可治理的运行时。
判断一项权力是否真正受控，可以看它能否被独立地拒绝、暂停、追溯和恢复。做不到这四点，权力就仍然散落在自然语言和团队默契里。
权限怎么做：任务级最小授权代替"一人一号"
多 Agent 权限管理最常见的问题是权限过度暴露。让 Agent 复用员工的完整账号，等于把该账号在系统内的所有权限都交给了模型，包括它根本不需要的审批、导出和删除能力。
工程上的做法是给每个 Agent 建立独立身份，而不是让它顶着人的账号操作。可以是服务账号或受限账号，权限范围与任务匹配。Agent 只负责处理工单分类，就不应拥有修改系统配置的权限。
具体落地时，可以参考这几条原则。
默认拒绝，而不是默认放行。 未在授权列表里的操作一律禁止，避免"给一把钥匙开所有门"。
按任务预定义权限集合，而不是每次操作单独询问。 频繁的权限弹窗会造成审批疲劳，最后退化成全部点允许。更稳妥的方式是任务开始前声明需要哪些权限，任务完成后自动收回超出最小必要集合的部分。
把粗粒度的角色授权升级为细粒度授权。 传统基于角色的授权在 Agent 场景下往往过粗，可以结合资源标签、操作类型和运行条件做组合判断，让"客服 Agent 只能在工作时间处理自己部门的退款工单"这类约束变成可执行的策略。
高风险操作默认禁止。 删除、发布、发送、转账、修改权限这类动作，除非任务明确要求且经过批准，否则一律不放开。
令牌短生命周期且可撤销。 Agent 使用的令牌应频繁轮换，一旦会话结束或检测到异常，可以按会话或按 Agent 批量失效，避免长期凭证泄露后无法及时止血。
权限策略本身也要当代码管理：进入版本仓库、走评审、每次变更配套回归测试，防止一次"临时放开"变成长期存在的后门。
安全怎么做：把护栏写成确定性代码
多 Agent 运行时的核心分工是：指令解析可以交给模型，权限校验不能交给模型。 模型的职责是理解任务、规划步骤；每一个动作在真正执行前，都要经过确定性代码构成的策略引擎校验。策略判断一旦交给模型自由裁量，就等于把安全边界建立在概率之上。
围绕这条主线，纵深防御通常包含几层。
沙箱隔离。 Agent 运行的代码、Shell 命令和文件操作放进隔离环境，数据处理尽量从副本开始，避免一次误操作污染生产数据。会话之间也要隔离，防止一个 Agent 的运行状态影响另一个。
统一执行入口。 所有工具调用都收敛到同一个带策略校验的入口，让"绕过策略直接调底层接口"在结构上变得困难。很多越权事故不是没有策略，而是某个新功能绕过了策略检查。
输入隔离。 外部读取的内容与系统指令要分层处理，不能让网页、邮件或文档里的文本直接获得指令权限。多 Agent 场景下，Agent 之间的协作消息也应视作不可信输入，接收方需要校验而不是盲目执行。
风险分级与人工审批。 把操作按风险分级，只对真正不可逆的动作设置强制人工确认，并给审批设置超时降级机制，避免审批人离线导致业务永久阻塞。审批请求应附带风险评分、影响范围和 Agent 的推理摘要，降低审批人的判断成本。
熔断与限流。 Agent 可以在短时间内发起大量操作，系统需要设置频率限制和异常行为检测。一旦检测到短时间大量敏感操作或异常模式，自动暂停任务并转人工处理，防止单个错误被自动化放大。
供应链审查。 工具、插件、Skill 和 MCP 服务是 Agent 的执行能力来源，也是新的攻击入口。第三方能力应经过来源和安全性审查，不能因为"能跑通"就直接接入生产。
审计怎么做：从"调用了什么接口"到"为什么这么做"
传统日志只记录技术动作，例如"调用了删除接口"。但多 Agent 出事后，团队真正要回答的问题是：是哪一轮对话、哪个 Agent、哪一步推理触发了这次操作。审计需要从流水账升级为语义级证据链。
用全链路 Trace ID 贯穿始终。 从用户请求开始，到编排 Agent、子 Agent、每次工具调用，都带上同一个追踪标识，才能把分散的事件串成一条完整链路。
记录语义字段。 除了谁在什么时间执行了什么操作，还应记录 Agent 识别的用户意图、推理摘要、调用的工具、工具输入的关键信息、执行结果以及策略决策是允许、拒绝还是人工批准。这些字段让审计员能理解 Agent"为什么这么做"，而不只是看到"做了什么"。
否定事件同样要记录。 被策略拒绝的操作、工具调用失败、审批超时，这些"没有成功"的事件往往是发现攻击尝试和策略过严问题的重要线索。只记成功不记失败，会让审计留下大片盲区。
防篡改。 审计日志采用只写一次、不可修改的存储，并用哈希链把前后事件关联起来。任何对历史记录的改动都能被校验发现。敏感的工具输入只存哈希，避免把原始数据复制进审计库扩大暴露面。
保留周期与导出格式。 日志保留时长按业务合规要求设定，并支持导出为标准格式，供安全与合规平台继续消费。
多 Agent 协作安全落地检查清单
上线前可以用下面这份清单快速自查，发现第一处空白就先补齐再放行。
- 每个 Agent 是否有独立身份，是否复用了员工或管理员账号
- 权限是否默认拒绝，写操作是否只授予任务所需的最小集合
- 终止权、状态权、动作归属和影响范围是否由运行时控制，而不是写在 Prompt 里
- 删除、发布、发送、转账等高风险操作是否有人工审批与超时降级
- Agent 之间的协作消息是否被当作不可信输入处理
- 工具调用是否全部经过统一入口的策略校验
- 被拒绝的否定事件是否与成功事件一样进入审计
- 全链路是否能用 Trace ID 串起意图、推理和每一次工具调用
- 是否存在异常熔断与速率限制
- 每次模型或策略升级后，是否重新跑过权限矩阵测试与红队测试
从单点防御走向平台化治理
多 Agent 权限、安全与审计的难点，不在于某个环节缺少工具，而在于控制权分散在各自的 Agent、Prompt 和团队约定里。真正稳定的做法，是把终止、状态、权限、动作和范围这五类控制权收拢到一个统一的治理平面上，让安全成为平台能力而不是事后补丁。
这也正是企业级 Agent 平台要解决的问题。以 ThinkingAI 的 Agentic Engine 为例，它面向企业创建和管理各类 Agent，支持多 Agent 协作并把感知到行动的链路放到统一平台上管理，同时支持私有化部署，方便企业把 Agent 运行边界放进自己的安全体系内。ThinkingAI 已服务全球超 1500 家企业、接入产品超 8000 款，这类规模化实践反过来也在推动平台把权限、审计与合规能力做成默认配置。
给 Agent 划清边界，不是限制它做事，而是让它做的事值得被信任。多 Agent 协作越深入，这个前提就越重要。
