AI供应链安全（1）：先看见，再管住——智能体资产发现与管理

锦岳智慧

2026年10月17日 23:47
北京

去阅读

设想一个场景：安全团队被问到“公司现在有多少个智能体在跑”，没人答得上来。IT 部门说低代码平台上登记了四十多个；业务部门自己搭的、跑在个人服务器上的、接了第三方 MCP 工具的，没人统计过。更麻烦的是，就算勉强列出来，也说不清每个智能体用的是哪个模型、接了哪些工具、能碰到什么数据。

这不是个别现象。智能体正在以远超资产管理能力的速度扩散：低代码平台让一个业务人员半天就能搭出一个 Agent，MCP 让工具可以在运行时动态挂载，开源模型把本地部署的成本压到一台服务器。而传统的资产管理手段——CMDB、云资产盘点、端点管理——都是为“静态、可枚举、有明确版本号”的 IT 资产设计的。

于是出现了一个尴尬的治理真空：智能体已经能读文件、调接口、发消息、改数据，但没人知道它们在哪、由谁负责、变了什么。

本篇是“AI 供应链安全”系列的第一篇，讨论填补这个真空的第一道环节——如何把智能体资产“看见”。第二篇将在此基础上讨论如何用 AIBOM 回答“它由什么构成”。

一智能体为什么“看不见”

要解决问题，先要看清楚传统资产管理在智能体面前失效在哪里。

失效点一：分散部署，入口不唯一

传统应用的部署入口相对集中——应用服务器、容器平台、云主机，盘点时总有一个“权威数据源”可依。智能体可能跑在公有云的模型服务上，可能跑在本地一台装了 Ollama 的服务器里，可能嵌在某个 SaaS 产品的功能中，也可能只是业务人员在自己电脑上起的一个 Gradio 页面。没有一个系统天然知道它的存在。

失效点二：动态创建，生命周期不受 IT 控制

传统应用的发布要经过需求、开发、测试、上线，IT 全程可见。智能体的创建常常跳过这条链路：业务人员在低代码平台上拖拽几下就发布了一个助手，用完随手停掉，下周又新建一个。资产的诞生与消亡都不经过 IT，CMDB 自然无从登记。

失效点三：运行时挂载，构成在构建时不可知

这一条最特殊，也最容易被忽略。传统软件的依赖在构建时就已确定，写在 package.json 或 requirements.txt 里，扫一遍就清楚。智能体不同：MCP Server、Skills、第三方插件可以在运行时动态挂载。一个智能体上线时只接了三个工具，跑了一周后可能已经挂了七个。这意味着构建时的清单，无法代表运行时的真实构成。

三个失效点叠加的结果是：不是“资产台账不准确”，而是根本没有台账。在谈检测、谈合规之前，第一件事是把底数摸出来。

二资产发现：多种发现方式与交叉验证

单一路径不可能覆盖全部场景。可采用主动探测、被动分析、平台侧对接，再用交叉验证把三路结果合并成一份可信的台账。

2.1 主动探测：不依赖任何既有系统

主动探测由平台从网络侧发起，基于资产网段与域名清单，对智能体与模型服务的默认端口、特征路径及协议响应进行探测识别。它的最大价值在于不依赖既有台账、平台接口或主机 agent，可以在治理初期快速圈定分布范围，是发现无人认领影子资产的主要手段。

必须清醒地认识到主动探测的边界：它只能证明“该端点存在且具备智能体特征”，不能证明它正在实际运行或被真实使用。一个登录页、一个占位服务、一个早已废弃的测试实例，都可能被命中。

2.2 被动分析：唯一能证明“正在运行”的路径

在确认资产是否实际运行这一目标上，流量侧是首选路径。通过对 API 网关与出口流量中的模型调用特征进行识别，可以确认智能体确实在被调用，其证据效力高于平台登记信息。

识别对象包括：模型服务域名与调用路径；请求体中的 model、messages、tools、functions 字段；响应体中的 choices、usage、object 字段；对 MCP 协议，重点识别 JSON-RPC 2.0 封装下的 tools/list 与 tools/call 方法调用；以及 SSE 流式响应特征。

被动分析方法的主要局限性是 HTTPS 需要解密或旁路镜像，落地成本相对高。

2.3 平台侧对接：批量获取已纳管对象

通过与 Kubernetes、智能体开发平台、API 网关及工单系统的接口对接，可以批量获取已纳入平台管理的智能体配置与运行状态。

典型特征包括：Deployment 或 Pod 的环境变量含 OPENAI\_API\_KEY、ANTHROPIC\_API\_KEY 等；镜像名含 langchain、vllm、ollama；网关路由含 agent、chat 等关键字；工单内容含“智能体”“Agent”“助手”等字样。

这条路依赖平台接口开放与授权，只能覆盖已纳管对象，但它是补充业务属性与责任人的最好来源。

表 1 三路发现方法对比

01主动探测

数据来源

资产网段与 IP／域名清单、DNS 解析记录、证书透明日志、互联网暴露面线索、内网资产库

适用条件与局限

不依赖台账，适合摸底阶段快速圈定范围；只能证明存在与特征，不能证明在运行，需与流量侧交叉验证

02被动分析

数据来源

API 网关日志、出口／镜像流量

适用条件与局限

可确认是否实际运行，证据效力最高；HTTPS 需解密或旁路镜像

03平台侧

数据来源

Kubernetes／容器平台、智能体与低代码平台管理接口、API 网关配置、ITSM 工单

适用条件与局限

依赖平台接口开放与授权，覆盖已纳管对象；是补充业务属性与责任人的主要来源

2.4 发现之后才是关键：交叉验证与可信度分级

发现不是终点，把发现结果处理成可信台账才是。三种方法各自存在覆盖盲区与误判可能，结果需经归一化处理才能进入台账，处理分四步。

第一步：是交叉验证与可信度分级。对同一资产的多路证据做一致性比对：两路及以上相互印证的，判定为高置信并直接入库；仅单路命中的标记为待确认并降低置信等级。

第二步：是归一化与去重。以端点、镜像、凭证等唯一标识为键，把三路结果合并为统一资产对象，同一资产的多路证据合并保留，避免重复计数。

第三步：是入库与待补全分流。确认的资产全部写入台账；具备输入材料的转入 AIBOM 生成流程；暂不具备材料的登记为待补全，进入持续收敛队列。

第四步：是周期性重跑。发现任务按配置周期自动重跑，新增资产自动入库，已下线资产状态自动更新，人工补录项随重跑结果自动校正，避免台账随时间失真。

三建档：让台账从“列表”变成“可判定风险的依据”

资产进入台账只是开始。台账要能支撑风险判定，还需要三件事。

3.1 来源与可信度标记

台账每条记录都要标记其来源为自动发现还是人工补录，并保留发现路径与采集时间。这两类来源的可信度不同，混记将导致台账无法支撑风险判定。自动发现项随周期性重跑自动校正；人工补录项需明确维护责任人与复核周期。对无法通过接口自动获取的非技术类、管理类字段，支持人工补录与自定义字段扩展。

3.2 分类分级：数据敏感度 × 动作权限

传统资产按“重要性”分级，智能体不能照搬。智能体的风险不取决于它有多重要，而取决于两个维度的乘积：它能碰到什么数据（数据敏感度）× 它能做什么动作（动作权限）。一个看似边缘的客服智能体，如果具备写操作与外联能力，风险远高于一个只读的内部问答机器人。

按这两个维度划分为核心、重要、一般、试验四级。核心级指可访问敏感数据或具备写操作与外联能力的智能体，纳入强制检测与变更审批；试验级指仅用于验证、不接触生产数据的智能体，可简化流程。分级结果直接决定检测频次与变更审批层级——这是让治理资源真正投到高风险对象上的前提。

3.3 责任人确权与兜底

对发现时无明确归属的资产，按“流量反查—平台反查—确权认领”的顺序定位责任人；确仍无法定位的，由 IT 部门兜底托管并标注托管状态。资产治理最常见的失败形式不是没找到，而是找到了没人认。无人负责的资产，等于无人整改的漏洞。

四版本变更追踪：给没有版本号的智能体赋予版本

需要特别说明的是，智能体不同于传统软件，通常不存在现成的版本号可供比对。所以版本标识不是智能体自带的，而是必须由平台赋予。

4.1 六要素版本快照

做法是把六类可变要素固化为一个版本快照，以此作为智能体的版本标识与比对基线：基座模型、提示词、知识库、工具与插件、编排逻辑、权限边界。任何一项发生变化，快照就随之变化。

在此基础上自动记录智能体及其依赖组件（基座模型、工具、MCP Server、Skills 库等）的版本变更历史，提供版本差异对比与历史快照追溯，为风险定级、漏洞定位与溯源审计提供上下文依据。

4.2 运行期变更检测：最关键的一环

这一环节之所以关键，是因为智能体的多数变更并不经过发布系统。修改提示词、向知识库上传文档、运行时挂载新的 MCP Server、上游供应商静默更新——这些都可以在不重新构建应用的情况下改变系统行为。

如果只检测发布流程内的变更，会漏掉绝大部分真实变更。更危险的是，此时“台账没变”会成为一种假象：它让人以为一切如常，实际上系统行为已经改变，而所有的检测结论、合规判定都还建立在旧的行为假设上。

合理的做法是按配置周期重新生成版本快照并与基线比对，对未走发布流程的运行期变更同样形成记录与告警，避免台账与实际脱节。

4.3 回滚与熔断

发现风险变更时，需要有不同的处置粒度：支持按版本快照整体回滚；对单个工具或 MCP Server 支持单独摘除而不影响智能体其余能力；对确认存在高危行为的智能体支持一键熔断，暂停其运行与调用；对依赖外部供应商的智能体，提供切换至备用供应商的处置路径。

五小结

摸清“有多少个智能体”只是第一步。治理真正需要回答的下一个问题是：每一个智能体，究竟由什么构成？当某个 MCP 组件曝出漏洞时，能不能在几分钟内给出受影响的智能体名单和责任人？这是本系列第二篇要讨论的主题——AIBOM。