多Agent开发的安全红线：Secrets、供应链、越权工具调用怎么管
我翻过十几个开源的多Agent框架，发现一个有意思的共性：几乎每一个框架里都有一个叫Security Agent的角色。不是可选插件，是标配。
为什么？因为多Agent系统的攻击面比单Agent大太多了。单Agent出问题，影响范围是一个会话。多个Agent共享同一个环境，共享文件系统，共享网络访问，一个Agent的疏忽可能波及整个系统。
01 Secrets泄露：你的API Key在跟多少个Agent共处一室？
单Agent场景下，一个API Key只暴露给一个执行实体。多Agent场景下，这个Key可能被传递给了负责调用外部服务的Agent、负责测试的Agent、负责部署的Agent。每多一个Agent接触到密钥，泄露的概率就多一分。
泄露方式比你想象的更隐蔽。Agent可能在生成日志时把完整的请求头打印出来，里面包含Authorization字段。可能在写代码注释时顺手把配置信息贴进去。可能在生成commit message时引用了环境变量的值。这些都不是Agent故意为之，是它不知道什么该说什么不该说。
最小权限原则在这里不是一个好听的安全术语，是实实在在的工程需求。每个Agent只能访问它完成当前任务所需的最少secrets。负责写前端UI的Agent根本不需要知道数据库密码。负责跑单元测试的Agent不需要生产环境的API Key。
实现方式也不复杂：把secrets按职责域划分，通过环境隔离或secrets manager做分发，Agent只能通过受控接口获取自己需要的那一份。
02 供应链安全：Agent装的包你审过吗？
Agent能写代码，也能执行代码。执行代码的时候可能需要安装依赖。问题来了：Agent选择装哪个包、装哪个版本，你控制得了吗？
一个Agent在生成Python项目时随手写了requests==2.28.0，这个版本可能有已知的安全漏洞。另一个Agent在Node.js项目里装了一个名字很像官方包的恶意npm包。这些在人类开发者身上都会发生，在Agent身上发生的概率只会更高，因为Agent不会像有经验的开发者那样对陌生的包名产生警觉。
应对方案有两层。第一层是依赖白名单：预先定义允许使用的包和版本范围，Agent只能在这个范围内选择。第二层是自动安全扫描：Agent安装完依赖之后，立刻跑一遍漏洞扫描（比如npm audit或者safety check），发现问题就阻断流程。
这两层防线缺一不可。光有白名单太僵硬，会限制Agent的灵活性。光有扫描太滞后，等发现问题时代码可能已经提交了。
03 越权工具调用：Agent的手比你预想的长
Agent被授权使用某些工具：文件读写、网络请求、shell命令执行。授权的意图是让Agent完成特定任务。但Agent在实际执行中可能超越预期范围。
一个具体的例子：你让Agent读取项目的README文件来理解项目结构，Agent读完README之后觉得配置文件也应该看看，于是去读了.env文件，接着觉得生产配置也需要了解，尝试读取/etc/nginx/nginx.conf。每一步都有看起来合理的理由，但最终结果是Agent访问了它根本不该碰的东西。
更危险的情况是shell命令。你给Agent执行npm test的权限，Agent发现测试跑不过，决定先修改一下配置文件再跑。修改配置文件这个动作，你授权了吗？
路径白名单是最基本的防线。定义Agent可以读写的目录范围，超出范围的访问直接拒绝。工具调用审计是第二道防线：记录Agent的每一次工具调用，包括调用了什么、传了什么参数、返回了什么结果。出问题的时候可以回溯。
04 Security Agent：让AI监督AI
bradms98/claude-agent-team和dylan-gluck/cc-dev-team这两个开源项目都采用了同一个策略：专门设立一个Security Agent，它的唯一职责是审计其他Agent的行为。
Security Agent不写业务代码，不做数据分析。它监控其他Agent的工具调用记录，检查是否有越权访问，扫描生成的代码中是否有硬编码的密钥，验证安装的依赖是否在白名单内。如果发现问题，它可以阻断相关Agent的后续操作，或者标记问题等待人类审查。
Claude Code Action在GitHub PR审查场景里也有类似的设计。你可以配置OWASP安全审查清单，让Claude在审查代码时自动检查常见的安全问题：SQL注入、XSS、不安全的反序列化、硬编码凭据。
让AI监督AI听起来有点套娃，但在工程实践中是合理的。Security Agent和其他Agent的激励不同：其他Agent追求任务完成，Security Agent追求安全合规。这种目标对立本身就是一种制衡。
05 落地建议
说几条我认为优先级最高的实操措施。
安全审计日志：每个Agent的每一次工具调用都要记录，保留至少30天。不是为了事后追责，是为了发现模式。如果某个Agent频繁访问不在它职责范围内的文件，说明要么权限配置有问题，要么Agent的任务理解有偏差。
权限最小化：宁可Agent因为权限不足而报错，也不要给过多的权限让它自由发挥。Agent报错了你可以手动授权，Agent越权了你可能过了很久才发现。
敏感操作二次确认：删除文件、修改配置、执行数据库迁移、推送到生产分支。这几类操作无论Agent多有把握，都应该暂停下来等人确认。自动化的速度没有那么重要，搞砸了的恢复成本才真的高。
参考链接： https://github.com/bradms98/claude-agent-team https://github.com/dylan-gluck/cc-dev-team https://github.com/anthropics/claude-code-action https://docs.anthropic.com/en/docs/claude-code/github-actions