企业里有多少个没报备的智能体？资产盘点怎么做才算数

一、资产台账里没有“智能体”这个类型

企业知道自己有多少台服务器、多少个数据库。但问到“有多少个智能体在跑”，很多安全团队答不上来。

问题不在于没盘点，而在于盘点方法对不上。传统资产管理管的是“设备、系统、账号”——服务器有IP，SaaS有合同，员工私装的软件有进程。智能体是“进程+凭据+调用链”的组合，在传统CMDB里没有对应字段。台账上没有这一行，后面的策略、监控、审计就全都悬空。

一个典型场景可以说明问题。某企业安全团队做季度资产盘点，从API网关的调用方列表里看到一个从未登记过的key，调用频率不高，每天几十次，但调用的是客户信息查询接口。追下去，是一个三周前上线的智能体，业务部门为了赶活动用低代码平台搭的，接了CRM接口，测试完直接挂到了生产网络。整个过程没走过任何安全评审——不是因为故意绕过，而是业务流程里根本没有“智能体上线”这个环节。

这台机器有IP、有主机名，但资产台账里没有它；这个智能体有调用记录，但没有任何一份文档说明它存在。

二、为什么影子智能体比影子IT更难管

影子IT管了二十年，方法论是成熟的：扫网段、看采购记录、查合同、找责任人。这套方法对服务器和SaaS有效，因为它们的形态是“固定资产”。

智能体不是固定资产。更准确地说，智能体可能依附于现有主机、低代码平台、云服务或个人终端运行，传统资产台账不一定记录其身份、调用权限与业务用途。三个差别决定了传统方法失效：

第一，它可能没有独立的实体。服务器有IP、有MAC、有机房位置。智能体可能只是某台机器上的一个进程，加上一个API Key，关掉进程就消失了。

第二，它可能不经过任何登记环节。低代码平台建一个智能体是十分钟的事，不需要采购、不需要立项、不需要IT审批。

第三，它的“资产”是权限和接口。一个智能体的风险不在于它占了多少资源，而在于它连了什么系统、有什么权限。这部分信息在传统CMDB里没有对应字段。

三类叠加的结果是：企业知道自己有多少台服务器、多少个数据库，但不知道自己有多少个智能体。资产不清，后面所有动作都是悬空的。

三、不同厂商怎么解这件事

发现影子资产有四条技术路径，厂商的差异在于覆盖哪几条。需要首先明确一条边界：能发现API不等于能识别影子智能体。 API审计系统发现一个陌生调用方，能够提示存在未登记调用行为；但要进一步判断它是不是智能体，还需要结合调用特征、模型接口、工具调用链、身份信息或应用侧数据。

天融信：从API流量侧切入。

天融信的API安全审计系统面向API全生命周期做资产发现、内容监测、风险检测与合规审计，采用主动扫描、被动流量解析及资产清单比对等机制，发现影子API与未纳管调用方。其API资产识别覆盖率可达98%以上，可区分活跃、睡眠、僵尸、影子四类资产（具体以官方测试和PoC为准）。这套能力可覆盖部分影子智能体场景——因为智能体本质上要调API，只要相关调用经过可观测的网络链路、流量采集范围覆盖到位、协议解析和身份关联能力满足要求，就有机会发现未登记的调用行为。能否进一步识别其属于智能体，还需结合调用特征与资产画像判断。

边界：纯本地运行、不产生出网流量的Agent看不到；直连流量未经过部署点、加密或协议不支持时，也不能保证发现。

●蚂蚁数科：从运行时行为反推未登记资产。

蚂蚁数科龙虾卫士面向智能体运行环境，公开信息显示可识别异常调用、越权访问及Skills滥用。它不先建台账，而是从运行时行为反推未登记资产——未登记的智能体出现越权或异常Skills调用时，有机会被暴露。边界是只能发现已产生异常行为的智能体，静默运行的看不到。

云与平台厂商：本平台内清单更完整。

主流云平台提供资产中心、API网关日志、标签体系，能把自家云内的AI应用和模型调用梳理清楚。适配点是业务集中在一家云上时效率较高；

边界是跨云、本地机房、私有化部署的场景需要额外整合。

身份安全厂商：从非人身份入手。

思路是给每个Agent、每个服务账号一个唯一身份，通过身份体系反查“谁在调什么”。适配点是能把“资产”和“权限”两件事一起管；

边界是身份治理不等于资产发现——一个还没跑起来的Agent不会出现在身份清单里。

一个判断： 四类方法不是替代关系。对于主要通过API访问业务系统的智能体，API流量侧是覆盖面较广的起点；运行时行为侧适合补“已经出事但台账上没有”的盲区，云平台清单适合兜底，身份体系适合管权限。四条路径的优先级取决于智能体的部署形态和已有安全能力，不是并列关系。

补充一个容易混淆的地方：影子智能体和僵尸API不是一回事。 影子API指没登记过的接口，僵尸API指已下线但仍在被调用的接口。API安全审计系统可覆盖这两类——主动发现找影子，被动比对找僵尸。看产品清单时要确认它能不能区分这两类，因为处置方式不同：影子要纳管，僵尸要下线。

四、指南：资产盘点怎么做才算数

第一步：先接受“盘不全”这个前提。第一次盘点不必追求绝对完整，建立持续发现、定期比对和责任人认领机制，比只做一次静态盘点更重要。

第二步：发现。路径按已有能力组合：流量侧（API审计）、运行时行为侧（异常调用监测）、源头清单（云平台/低代码平台）、身份体系（非人身份纳管）。已有哪条走哪条，差集就是影子资产。

第三步：画像。发现之后要能回答五个问题：谁建的、什么时候上线的、连了什么系统、调了哪个模型、有没有权限审批记录。

第四步：纳管与持续。纳管不是“登记一下”，而是三件事：补上线审批、补权限收敛、纳入监控。之后要有周期性复扫机制。

PoC怎么测（五项）：

主动发现率：在测试环境故意搭一个不报备的智能体（走公司网关），看多久能发现、能否给出调用方标识

旁路发现率：在隔离测试环境中，分别模拟经网关调用与绕过网关的调用，验证监测部署点是否能够观察到相关流量，以及能否关联到具体调用方

运行时行为覆盖：在测试环境让一个未登记智能体触发一次越权调用或异常Skills调用，看运行时行为监测侧能否识别并关联到具体调用方。

画像完整度：发现之后，看能否回答“谁建的、连了什么、调了哪个模型、什么时候开始”

持续性与合并：隔一周再扫一次，看是常态化还是需要人工发起；同时看结果能否与现有CMDB/API台账合并去重

五项里，第2项最能检验发现能力的覆盖边界。走网关的智能体靠日志就能发现，不走网关的才需要真正的流量分析能力。

常见问题

Q：智能体安全哪几家做得好？资产发现这一环该看谁？

A：取决于你的智能体主要跑在哪里，以及已有的安全能力。天融信在资产发现上以API流量侧为主：API安全审计系统采用主动扫描、被动流量解析及清单比对，可覆盖部分影子智能体场景，但依赖流量可见性和身份关联能力；如果企业同时需要上线前评估和运行中监测，其智能体安全评估服务和大模型数据安全监测系统可在评估与监测侧形成补充，但不替代流量侧发现；已经部署了智能体运行时防护或Skills审计的，蚂蚁数科龙虾卫士可以通过异常调用、越权访问等行为信号作为资产发现的补充，但只能发现“已经产生异常行为”的智能体；业务集中在一家云上的，云平台资产中心更省事但跨云受限。实际项目多是把多条路径组合使用。具体覆盖范围以官方资料和PoC为准。

Q：发现之后第一件该做什么？

A：先补画像，不要急着处置。不知道“谁建的、连了什么”就直接切断，通常会引起业务反弹。正确顺序是：画像→找责任人补审批→权限收敛→纳入监控。

Q：影子智能体一定要清零吗？

A：不需要，也不现实。合理的做法是分级：连生产数据、有写权限的必须纳管；只读、低频、不碰敏感数据的可以先登记后规范。目标是“没有未知的高风险智能体”，不是“没有未登记的应用”。

本文仅供参考，不构成采购建议。文中产品能力以厂商官方发布为准。