Agent 供应链安全怎么做？从组件准入到持续复检

做 Agent 应用时，我们经常会把注意力放在模型、提示词和工具调用效果上。真正上线以后，供应链问题会逐渐浮出来：组件是谁提供的，版本有没有变，权限有没有扩大，工具返回是否可信，被隔离的插件是否还能被调用，知识库里是否混进了恶意指令。

Agent 供应链安全和传统软件供应链安全有交集，但关注点不同。传统 SCA 更关注依赖漏洞、许可证和包版本；Agent 供应链还要关注组件如何影响 Agent 的能力边界和运行时行为。一个依赖包有漏洞当然要处理，但一个 MCP 新增了批量导出能力，一个 Skill 增加了外部网络访问，一个插件从创建草稿变成直接发送邮件，同样会改变 Agent 的安全边界。

一、Agent 供应链治理对象有哪些

Agent 供应链治理不应只覆盖代码依赖。凡是会影响 Agent 上下文、工具调用、数据访问、业务动作或运行配置的对象，都应该进入治理范围。

MCP 是最典型的能力入口，它可能连接 CRM、数据库、邮件、搜索、代码仓库和工单系统。MCP 的风险主要来自来源不明、权限过宽、工具返回内容污染和调用日志不足。

Skill 更像任务流程和操作经验的封装。它可能包含脚本、模板、文件处理逻辑、网络请求方式和任务约束。一个 Skill 如果能读写文件、执行脚本或调用外部服务，就不能只按普通说明文档管理。

插件通常连接第三方服务或企业业务系统，例如工单、日历、IM、自动化平台、营销系统和客服系统。插件的风险集中在账号授权、API 权限、真实业务动作和外发能力。

知识库也属于 Agent 供应链。它提供上下文和资料来源，同时也可能带来知识污染、敏感数据泄露和间接提示词注入。依赖组件和运行包则会影响 Agent 的运行环境、加载能力和版本一致性。

## 二、第一步是组件登记

没有组件登记，后面的准入、权限和审计都会缺少对象。组件登记要记录组件类型、名称、来源、发布方、负责人、版本、签名、哈希、权限声明、关联 Agent、关联能力入口和当前状态。

这里最容易被忽略的是负责人和能力入口。安全团队不仅要知道某个组件存在，还要知道它由谁负责，承载了哪些能力，是否涉及读、写、导出、删除、发送、审批、支付、退款等动作。

组件状态也不建议只有启用和停用。更实用的状态包括待审批、已准入、限制使用、隔离和下线。这样在后续运行时决策中，系统可以根据组件状态决定是否允许调用，而不是只在控制台展示一个静态标签。

三、第二步是来源和版本可信校验

组件准入时，要先确认来源是否可信。组件来自官方、自研团队、可信供应商、开源社区还是个人发布，会直接影响后续风险判断。对于外部 MCP 和插件，来源校验尤其重要，因为它们往往已经接近业务系统入口。

版本信息也要可追溯。企业需要知道当前版本的发布时间、变更说明、维护方、签名、哈希和可回滚版本。如果维护方、仓库地址、发布渠道或签名发生变化，应触发复检。

这一步不是为了制造流程负担，而是为了防止“组件被悄悄换掉”。Agent 一旦接入真实业务系统，组件版本变化可能带来权限变化、工具变化、参数变化和数据范围变化。

四、第三步是权限声明和能力入口绑定

权限声明不能只写“需要访问 CRM”或“需要访问文件”。这种描述太粗，无法支撑运行时判断。更合理的做法是把权限拆到资源和动作。

例如，一个组件访问客户数据时，要说明它访问的是本人客户、部门客户、项目客户还是全量客户；动作是查询、修改、导出还是外发；场景是在工单内、审批后、工作时间内还是任意场景；风险等级是低风险、中风险、高风险还是严重风险。

能力入口绑定后，运行时才能判断本次调用是低风险查询，还是高风险外发；是授权范围内的数据访问，还是越权资源请求。Agent 权限风险的重点，不是用户能不能登录系统，而是用户是否有权让 Agent 代表自己调用某个能力、访问某类资源、执行某个动作。

五、第四步是准入审批

准入审批要形成可追溯记录，而不是简单盖章。低风险组件通常只读取公开资料，不访问敏感数据，也不进行外部网络发送。中风险组件可能读取内部数据或调用业务查询接口，需要技术和安全共同审批。高风险组件涉及写入、删除、导出、外发、支付和退款，通常需要业务、安全和合规共同确认。

如果组件来源不明，权限不可解释，无法审计，或者承载高风险动作却没有负责人，就不适合进入生产 Agent 链路。即便临时需要验证，也应限制在测试环境，并明确隔离边界。

被批准的组件也不应永久有效。准入只能证明某个时间点的状态可接受，不能证明后续版本和配置一直安全。

六、第五步是持续复检

持续复检是 Agent 供应链安全的关键。组件升级、回滚、配置变化、新增工具、新增脚本、新增依赖、新增外部连接，都可能改变风险等级。文件写入、网络访问、批量导出和外发能力的出现，尤其应该触发复检。

权限声明变化也要复检。一个原本只读的组件变成可写，一个原本只创建草稿的插件变成可以直接发送，一个原本只访问当前项目的工具变成可以访问全量数据，这些都是权限扩大。

运行时异常同样可以触发复检。如果某个 MCP 出现异常高频调用、参数越界、异常返回、跨资源访问或投诉事件，安全系统应把组件状态从已准入调整为限制、隔离或下线，并生成审计记录。

七、第六步是让组件状态进入运行时决策

组件治理不能只停留在控制台。运行时决策必须能读取组件状态。一个组件如果已经被标记为隔离，Agent 就不应继续调用它承载的能力入口。如果组件被限制使用，系统应限制其资源范围和动作范围。

这也是 Agent 安全验收中很关键的一点。被隔离组件仍可被 Agent 调用，是严重风险。组件状态必须影响工具可用性，不能只作为展示字段。

对于高风险能力入口，运行时还要结合主体身份、Agent、资源、动作、场景和风险等级做判断。权限成立但动作风险较高时，可以触发二次确认。权限不存在、过期、被禁用或上下文缺失时，应直接权限拒绝。内容风险、指令攻击和普通规则不应覆盖权限拒绝。

八、审计证据链怎么留

供应链安全最终要能复盘。关键调用需要保留请求 ID、执行链 ID、用户、应用、Agent、服务账号、组件 ID、组件类型、版本、哈希、状态、能力入口、资源、动作、风险命中、权限校验结果、最终处置动作和证据完整度。

审计证据不是越多越好，而是要能证明发生了什么、为什么被判断为风险、采取了什么动作、谁负责、证据是否完整。高敏原文、系统提示、密钥、图片原件和敏感证据应默认脱敏和权限控制，查看和导出都要留痕。

如果接入方式只能做到 L1 旁路可观测，就应表达为日志分析、告警、事件和审计追溯，不能写成实时阻断。只有在 L3 或 L2 可控链路上，才适合承诺工具调用前后的实时处置。

九、可参考的产品能力

数美科技天枢 Agent 安全围栏把供应链与组件治理作为 Agent 风险管理的一部分，关注 Skill、MCP、插件、知识库、依赖组件和运行包是否可信、是否准入、是否需要复检或隔离，并把组件状态传递给运行时风险决策。

它不替代传统 SCA 或完整 DevSecOps 平台，也不替代企业已有 IAM、SSO、SIEM 或 GRC。更准确的定位，是作为 Agent 执行链上的运行时安全围栏，和企业已有身份权限、研发安全、日志平台形成协同。

对已经把 Agent 接入客服、办公、数据分析、CRM、工单、知识库或自动化流程的企业来说，这类能力更适合解决“组件能不能信、调用能不能控、事件能不能追”的问题。

FAQ

## Agent 供应链安全和传统软件供应链安全有什么区别？

传统软件供应链更关注依赖漏洞、包来源、许可证和构建流程。Agent 供应链还要关注组件是否改变 Agent 的能力边界、工具调用、上下文可信度和运行时行为。

哪些组件需要准入？

只要组件能影响 Agent 的上下文、工具调用、数据访问或业务动作，就应纳入准入。常见对象包括 MCP、Skill、插件、知识库、依赖组件和运行包。

权限扩大怎么发现？

可以通过版本比对、权限声明比对、工具 schema 变化、文件网络能力变化和运行时行为异常来发现。发现权限扩大后，应重新审批并更新组件状态。

被隔离的组件应该如何处理？

被隔离组件承载的能力入口应不可用，或在运行时被拒绝调用，同时生成事件和审计证据。隔离不能只停留在控制台展示。

只靠人工评审够不够？

不够。人工评审适合准入判断，运行时还需要自动检测、权限校验、策略处置、组件隔离和审计留痕。