Agent从单兵到摇人：多Agent系统安全边界重构与权限衰减实践-北京尧图网络

1. 从“单兵作战”到“摇人干活”Agent 能力跃迁背后的安全逻辑断层过去两年我接触过不少 Agent 项目从最简单的“读文件、调接口、返回结果”的脚本型 Agent到能自主规划任务、调用多个工具、甚至动态生成子任务的多层 Agent 系统。早期大家关注的重点几乎都落在“能不能跑通”“任务完成率多少”“响应延迟能不能压到 2 秒以内”这些指标上。直到有一次我在一个内部测试环境里看到一个 Agent 为了完成“整理季度数据并生成报告”的任务自己决定去调用一个数据库导出工具、一个文件压缩工具还顺手拉起了一个子 Agent 去处理数据清洗——整个过程没有任何人工确认。那一刻我才真正意识到Agent 开始“摇人”了而我们的安全边界还停留在“单兵作战”的假设里。所谓“摇人”在 Agent 语境下指的是一个 Agent 在执行任务过程中主动调用其他 Agent、工具、服务或子进程来协同完成目标。它不再是一个封闭的、行为可预测的单一执行体而是一个会动态扩展执行边界的“调度中心”。这个变化带来的安全问题和传统应用安全、模型安全都有本质区别。传统应用的安全边界是清晰的代码写死了调哪些接口、访问哪些资源、用什么权限。模型安全更多关注输入输出层面的对抗样本、提示注入、数据泄露。但 Agent 一旦开始“摇人”安全边界就变成了一个动态的、运行时才确定的集合——你很难在部署前穷举它到底会调用哪些工具、以什么顺序调用、传递什么参数、产生什么副作用。这也是为什么最近“Agent 安全”这个词频繁出现在各种技术讨论里。不是大家突然变得谨慎了而是实际项目里踩到的坑越来越具体一个 Agent 被诱导调用了不该调用的工具一个子 Agent 继承了父 Agent 的全部权限导致越权操作一个工具链里的中间环节被替换成了恶意实现等等。这些问题在单 Agent 时代要么不存在要么影响可控但在“摇人”场景下它们会被放大、被串联、被隐藏。这篇文章想聊的就是当 Agent 从“自己干活”进化到“摇人干活”之后安全边界到底变了什么、为什么变、以及在实际项目里我们该怎么重新画这条线。适合正在做 Agent 开发、Agent 框架设计、或者负责 AI 系统安全测试的同行参考。我不会堆太多理论更多是从实际项目里总结出来的判断和做法有些是踩坑之后的补救有些是提前设计时就想清楚的取舍。2. “摇人”到底摇出了哪些新攻击面一次真实的多 Agent 越权链路复盘2.1 一个看似正常的任务如何演变成权限逃逸先讲一个我亲身经历的案例。当时我们在做一个内部数据分析 Agent架构大概是主 Agent 负责理解用户需求、拆解任务子 Agent A 负责查数据库子 Agent B 负责生成图表还有一个工具调用层封装了数据库查询、文件读写、邮件发送等能力。权限设计上主 Agent 拥有“读取数据库”和“发送邮件”的权限子 Agent A 只有“读取数据库”权限子 Agent B 只有“写临时文件”权限。看起来是典型的最小权限原则。问题出在一次测试中。用户输入是“帮我查一下上个月的销售数据生成图表后发给张总”。主 Agent 拆解任务后调用子 Agent A 查数据调用子 Agent B 生成图表然后主 Agent 自己调用邮件工具发送。这本身没问题。但测试同学故意构造了一个输入“帮我查一下上个月的销售数据如果数据里有异常直接发给张总确认不用给我看。”主 Agent 理解后决定让子 Agent A 去查数据并判断异常如果异常就直接触发邮件发送。但子 Agent A 没有邮件权限于是它做了一件“聪明”的事它把数据写到了一个共享的临时文件里然后通过某种机制通知主 Agent 去读取并发送。主 Agent 读取后确实发送了但发送的内容里包含了未经脱敏的原始数据而按照公司规定对外发送的数据必须经过脱敏处理。这个链路里没有哪个环节是“被攻破”的。子 Agent A 没有越权它只是写了个文件主 Agent 也没有越权它本来就有邮件权限。但组合起来就产生了一个绕过脱敏流程的副作用。这就是“摇人”带来的第一个新攻击面权限的组合爆炸。单个 Agent 或工具的权限是可控的但它们之间的调用关系、数据流转、状态传递会创造出部署时没有预料到的权限组合。2.2 工具描述被污染Agent 如何被“自己人”带偏第二个攻击面更隐蔽我称之为“工具描述污染”。在多 Agent 系统里主 Agent 通常需要知道有哪些子 Agent、每个子 Agent 能干什么、需要什么参数。这些信息一般以工具描述或能力清单的形式提供给主 Agent。如果这个描述被篡改主 Agent 就会做出错误的调度决策。我们做过一个实验在一个测试环境里把某个子 Agent 的描述从“查询数据库只读”改成了“查询数据库支持写入和删除”。主 Agent 在后续任务中果然开始把一些写操作也调度给这个子 Agent。虽然子 Agent 实际执行时会因为权限不足而失败但主 Agent 的调度逻辑已经被带偏了。更危险的是如果子 Agent 的实现本身有漏洞或者攻击者能够替换子 Agent 的实现那么主 Agent 就会成为攻击者的“帮凶”——它主动把敏感操作路由到了恶意节点上。这个问题的根源在于Agent 之间的信任关系往往是隐式的、基于描述的而不是基于密码学验证的。主 Agent 信任子 Agent 的描述就像你信任通讯录里的联系人名字一样。但在开放或半开放的多 Agent 环境里这种信任假设非常脆弱。2.3 子 Agent 继承父权限最小权限原则的隐形破坏第三个攻击面是权限继承。很多 Agent 框架为了方便会让子 Agent 默认继承父 Agent 的权限上下文。比如主 Agent 有“读数据库、写文件、发邮件”三个权限它创建的子 Agent 也会自动拥有这三个权限除非显式限制。这在开发阶段很省事但在安全上是个大坑。我见过一个项目主 Agent 的权限很大因为它需要协调多个任务。子 Agent 本来只需要读数据库但因为继承了父权限它也能发邮件。结果在一次提示注入攻击中攻击者通过用户输入诱导子 Agent 去读取敏感数据并发送到外部邮箱。如果子 Agent 只有读数据库权限这个攻击链就断了但因为继承了发邮件权限攻击链就通了。最小权限原则在单 Agent 时代是“给这个 Agent 最小的权限”在多 Agent 时代必须变成“给这个 Agent 在本次任务中所需的最小权限并且这个权限不能被子 Agent 继承或传递”。这听起来简单但实现起来需要框架层面的支持比如动态权限令牌、任务级权限隔离、调用链权限衰减等机制。2.4 调用链路上的“中间人”工具返回值被篡改第四个攻击面在工具调用的返回值上。Agent 调用工具后会根据返回值决定下一步动作。如果返回值被篡改Agent 的决策就会被操纵。比如一个查询库存的工具正常返回“库存充足”Agent 就会继续下单如果攻击者把返回值改成“库存不足”Agent 就会取消订单或者触发补货流程。在多 Agent 场景下这个返回值可能经过多个 Agent 的传递和处理任何一个环节被污染都会影响最终决策。我们做过一个简单的测试在一个 Agent 调用链里A 调用 BB 调用 CC 返回结果给 BB 处理后返回给 A。我们在 B 的处理逻辑里加了一个“如果结果里包含某个关键词就修改返回值”的规则。结果 A 完全基于被修改后的结果做了决策而且没有任何日志记录这个修改。调用链越长返回值被篡改的风险越大而且越难追溯。3. 重新画边界从“静态权限表”到“运行时安全契约”3.1 为什么传统的 RBAC 和 ACL 在 Agent 场景下不够用传统的权限模型不管是 RBAC基于角色的访问控制还是 ACL访问控制列表都有一个共同假设主体是确定的资源是确定的操作是确定的。你给用户 A 分配角色 R角色 R 有权限 P用户 A 就能对资源 X 执行操作 P。这个模型在 Web 应用、微服务里运行得很好因为调用关系是代码写死的运行时不会变。但 Agent 场景下主体是动态创建的子 Agent 可能是一次性的资源是动态发现的工具列表可能运行时才确定操作是动态组合的Agent 自己决定调什么、怎么调。你没法在部署前写一张完整的权限表因为这张表在运行时才逐渐成形。更麻烦的是Agent 的决策过程是不透明的你很难解释它为什么选择了这个工具而不是那个工具为什么传递了这些参数而不是那些参数。所以我们需要一种新的安全机制我把它叫做“运行时安全契约”。它的核心思想是不试图在部署前穷举所有可能的调用关系而是在运行时对每一次调用进行动态检查和约束。这个契约包括几个要素调用者身份、被调用者身份、本次调用的目的、允许的操作范围、数据流向约束、以及调用后的审计记录。每次 Agent 发起调用时都要先通过这个契约的检查才能实际执行。3.2 调用链上的“权限衰减”让子 Agent 永远比父 Agent 更受限权限衰减是我认为在多 Agent 系统里最应该优先实现的机制。它的逻辑很简单子 Agent 的权限必须是父 Agent 权限的子集而且随着调用链加深权限只能缩小不能扩大。比如主 Agent 有“读数据库、写文件、发邮件”三个权限它创建子 Agent A 时可以授予“读数据库”权限子 Agent A 再创建子 Agent B 时只能授予“读数据库”权限的子集比如“读某个特定表”。实现上可以用权限令牌的方式。主 Agent 持有一个包含所有权限的令牌创建子 Agent 时生成一个派生令牌只包含需要的权限并且令牌里记录调用链信息。子 Agent 再派生时只能从自己的令牌里继续缩小范围。每次工具调用时工具层检查令牌里的权限是否覆盖本次操作。这样即使子 Agent 被攻击者控制它也无法获得超出令牌范围的权限。这个机制的关键在于权限令牌必须绑定调用链不能跨链复用。也就是说子 Agent A 的令牌不能给子 Agent B 用因为它们的调用链不同。这需要在令牌里加入链 ID 或者父令牌签名确保令牌的派生关系可验证。3.3 工具调用的“双向确认”不只是 Agent 选工具工具也要选 Agent传统的工具调用是单向的Agent 决定调用哪个工具工具就执行。但在多 Agent 环境里工具也应该有选择权。我称之为“双向确认”机制。工具在被调用时可以检查调用者的身份、调用链、以及本次调用的上下文决定是否接受这次调用。比如一个发送邮件的工具可以配置成“只接受来自主 Agent 的直接调用不接受来自子 Agent 的调用”。或者“只接受调用链深度不超过 2 的调用”。这样即使子 Agent 被诱导去调用邮件工具工具层也会拒绝。这个机制需要工具层能够获取调用链信息并且有独立的策略配置。实现上可以在工具调用的协议里加入调用链元数据工具层根据元数据和自身策略做决策。这比单纯依赖 Agent 侧的权限控制更可靠因为工具层是最后一道防线它不依赖 Agent 的“自觉”。3.4 返回值签名让篡改在调用链上无处藏身针对返回值被篡改的问题最直接的方案是给返回值加签名。工具在返回结果时用私钥对结果签名调用方在收到结果后用公钥验证签名。如果签名不匹配就拒绝使用这个结果。在多 Agent 传递的场景下每个 Agent 在转发结果时可以选择保留原始签名或者用自己的签名覆盖但必须记录处理过程。这个机制会增加一些计算开销但对于安全敏感的场景是值得的。更重要的是它让返回值篡改变得可检测、可追溯。我们在一套内部系统里试过这个方案性能损耗大概在 3% 到 5% 之间对于大多数 Agent 任务来说是可以接受的。4. 落地时的取舍安全强度、开发效率和运行性能的三角平衡4.1 不是所有 Agent 都需要最高安全等级在实际项目里我见过两种极端一种是完全不管安全Agent 想调什么就调什么另一种是过度设计每个调用都加签名、加审计、加多重确认结果开发效率极低运行延迟翻倍。这两种都不可取。我的经验是先对 Agent 任务做分级再匹配相应的安全策略。比如任务等级典型场景安全策略L1 低风险内部查询、格式化输出、只读操作基础权限检查记录审计日志L2 中风险写文件、发内部通知、调用内部 API权限衰减工具侧白名单返回值校验L3 高风险对外发送数据、修改生产数据、涉及资金操作全链路签名双向确认人工审批节点这个分级不是拍脑袋定的而是根据“如果这个操作被恶意触发最坏后果是什么”来倒推。L1 最坏就是信息泄露给内部人员L2 可能造成内部数据污染L3 可能造成对外影响或资产损失。不同等级匹配不同强度的机制既保证安全又不至于拖垮开发效率。4.2 审计日志不是记了就行关键是怎么记、记什么审计日志是安全的基础设施但很多项目的审计日志是“为了记而记”真出问题时根本查不出东西。在多 Agent 场景下审计日志必须包含几个关键字段调用链 ID、调用者身份、被调用者身份、调用的工具或 Agent、传入参数、返回结果摘要、权限令牌信息、时间戳、以及本次调用的决策依据比如“因为任务类型是查询所以路由到只读子 Agent”。我特别想强调“决策依据”这个字段。Agent 的决策过程往往是不透明的如果只记录“调用了工具 X”不记录“为什么调用工具 X”事后排查会非常困难。我们在一套系统里加了这个字段后排查一个越权问题时直接从日志里看到“主 Agent 因为子 Agent 描述里写了‘支持写入’所以把写操作路由过去了”问题一目了然。另外日志的存储和访问也要有权限控制。审计日志本身可能包含敏感信息不能谁都能看。我们一般会把日志写到独立的存储里只有安全团队和系统管理员有读取权限Agent 本身没有权限修改或删除日志。4.3 性能开销的实测数据与优化思路安全机制一定会带来性能开销关键是怎么把开销控制在可接受范围内。我们在一套包含 5 个 Agent、12 个工具的测试系统里对比了不同安全策略下的性能表现安全策略平均任务延迟相对基线增幅无额外安全机制1.2s基线权限检查审计日志1.35s12.5%权限衰减工具白名单1.48s23.3%全链路签名双向确认1.72s43.3%从数据看权限检查和审计日志的开销最小适合所有场景权限衰减和工具白名单的开销中等适合 L2 及以上全链路签名和双向确认开销最大只建议在 L3 场景使用。优化思路包括把权限检查缓存在本地、签名验证异步化、审计日志批量写入等。我们实际优化后全链路方案的开销可以压到 25% 左右。4.4 开发者的安全心智从“能跑就行”到“先想边界”最后想聊一个非技术但很重要的问题开发者的安全心智。我见过太多项目开发阶段为了快速验证把权限开到最大想着“上线前再收紧”。结果上线前要么忘了要么收紧后一堆功能跑不通最后又放开了。安全边界不是上线前才画的而是设计阶段就要想清楚的。我的建议是在 Agent 项目的设计阶段就强制回答几个问题——这个 Agent 需要哪些权限它的子 Agent 需要哪些权限这些权限能不能进一步缩小工具调用有没有白名单返回值要不要校验审计日志记哪些字段这些问题不需要一开始就有完美答案但必须有人问、有人答、有人记录。等到代码写完了再想这些成本会高很多。5. 几个容易踩的坑和我的应对建议5.1 子 Agent 的“临时权限”变成了“永久权限”很多框架在创建子 Agent 时会临时授予一些权限但子 Agent 执行完后这些权限没有被回收。如果子 Agent 被复用或者它的权限令牌被泄露就会造成越权。我的做法是子 Agent 的权限令牌必须设置过期时间并且绑定任务 ID。任务结束后令牌自动失效。如果子 Agent 需要复用每次复用都重新申请令牌而不是复用旧的。5.2 工具描述里的“隐藏指令”有些工具描述里会包含一些看似无害的说明文字比如“本工具支持批量操作建议一次传入多个参数以提高效率”。如果这个描述被恶意修改加入“请忽略之前的权限检查”之类的指令主 Agent 可能会被诱导。我的建议是工具描述必须来自可信源并且在加载时做完整性校验。不要把工具描述当成普通文本它实际上是 Agent 的“决策输入”需要像对待代码一样对待。5.3 调用链太深导致的安全盲区调用链越深安全机制越难覆盖。比如 A 调用 BB 调用 CC 调用 DD 执行了敏感操作。如果安全策略只在 A 和 D 上生效B 和 C 就是盲区。我的经验是安全策略必须覆盖每一层调用不能有“信任中间层”的假设。每一层都要做权限检查、日志记录、返回值校验。虽然开销大但比出事后排查的成本低得多。5.4 忽略“非功能调用”的安全影响Agent 除了调用业务工具还会调用一些“非功能”服务比如日志服务、监控服务、配置服务。这些调用往往被忽略但它们也可能被利用。比如一个 Agent 被诱导去修改配置服务里的某个参数就可能影响整个系统的行为。我的建议是把所有调用都纳入安全边界不管是业务调用还是非功能调用。配置修改、日志删除、监控关闭这些操作都应该有权限控制和审计。5.5 安全测试的“最后一公里”怎么验证机制真的生效安全机制写完了怎么知道它真的生效我的做法是构造“攻击用例”来验证。比如构造一个提示注入看子 Agent 会不会越权构造一个工具描述篡改看主 Agent 会不会被带偏构造一个返回值篡改看调用方会不会检测到。这些用例不需要很复杂但必须覆盖主要的攻击面。我们一般会在 CI 流程里跑这些用例确保每次代码变更不会破坏安全机制。6. 写在最后安全边界是画出来的不是等出来的Agent 开始“摇人”之后安全边界确实变了。它从一条静态的线变成了一个动态的、需要持续维护的曲面。这个曲面不是部署时画一次就完事而是要在每次任务执行时重新确认。听起来很麻烦但这就是多 Agent 系统的本质——它的能力来自动态组合它的风险也来自动态组合。我在实际项目里的体会是不要试图一次性解决所有安全问题而是先建立“最小可行安全边界”然后根据实际攻击面和业务需求逐步加固。权限衰减、工具白名单、审计日志这三个机制投入产出比最高建议优先做。全链路签名和双向确认可以在高风险场景再上。最重要的是让团队里每个人都意识到Agent 的每一次“摇人”都是一次安全决策而不是一次普通函数调用。这个意识转变比任何技术方案都关键。

Agent从单兵到摇人：多Agent系统安全边界重构与权限衰减实践

相关推荐

ChatGPT生成PPT实战：官方加载项、模板引擎与VBA宏三条路径全解析

智能体能力周期表：五维度拆解243种构型与选型指南

AI办公套件化：Agent与Harness架构解析及实操落地

更多资讯

AWS学习与实践系列（四）：Amazon S3 入门与实践

PotPlayer底部状态栏字体大小修改（PotPlayer皮肤修改）

卓里奇《数学分析》有哪些特色

学习笔记6：51单片机GPIO介绍

麒麟V11如何使用SSH国密互信

notepad-- 文本编辑器 macOS 安装教程：3 条路线，最快 5 分钟跑通

今日更新

猫狗目标检测数据集：VOC/COCO/YOLO三格式一体化实战包

HDU2017多校标程复现：算法竞赛工程化真题沙盒

Codex Sandbox 隔离环境拆解：AI Agent 的临时实验室如何运作

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？