三家厂商在同样的四天里发布了智能体安全产品,而在三样不同的东西底下,他们作出了同一份自认:没有人说得出自己公司里到底有哪些智能体在跑。CrowdStrike 把答案放进了端点传感器,AIR 融了 5000 万美元把它放进请求路径,Tenable 与 OpenAI 把它放在一个登记册前面——而这三份答案,每一份都是一次抽样普查:对某一个位置是完整的,对其余各处一言不发。这要紧,是因为拿来审计你的那些体系要的不是普查。它们要的是一份登记册;而这一周真正有用的指标,不是你发现了多少个智能体,而是"已发现"与"已登记"之间那道缝有多宽。
速览
四天,三则公告,三个截然不同的落脚点。
| 产品 | 发布时间 | 埋点位置 | 主要做什么 |
|---|---|---|---|
| CrowdStrike Falcon Guardian | 2026-09-01,Fal.Con 大会 | Windows 与 macOS 端点上的 Falcon 传感器 | 发现已知与影子智能体,把提示词一路追到动作,拦下未获批的 |
| AIR | 2026-09-01,走出隐身 | 内联,位于上下文被组装起来的那道边界 | 在智能体动手之前,筛查进入其上下文的指令、工具与数据 |
| Tenable / OpenAI Exchange Inspector | 2026-09-03 | CyberAgents Exchange 登记册,部署之前 | 在采用之前审查提交上来的智能体、技能、MCP 服务器与多智能体剧本 |
先读第一行,因为它正是今天多数组织所倚仗的那一行。一个自助登记册——那份表格、那张 ServiceNow 工单、那个让各团队自行申报 AI 系统的 wiki 页面——在唯一一列"它的全部存在意义所系"的项目上得了低分。登记是自愿的,而你最需要知道的那些智能体,恰恰是没人替它填过表的那些。
三样产品,三个落脚点
CrowdStrike:那台笔记本上早就装着的传感器
Falcon Guardian 是 Falcon AIDR 的后继者;后者在去年 12 月正式可用,并在 3 月的 RSAC 上拿到了影子 AI 发现与端点运行时保护。Guardian 的说法是,Falcon 传感器本来就坐在每一台受管的 Windows 与 macOS 机器上,所以它可以像一直以来枚举进程那样去枚举智能体:一份关于正在运行的与休眠的智能体的实时清单、每一个是谁部署的,以及它当前的安全状态。随后,Agent Runtime Visibility 把智能体的行为与普通端点遥测连起来,把提示词、身份、工具调用与技能使用一路追到它们所产生的下游系统动作。Agent Access Controls 定义哪些智能体可以在受管端点上运行,其余一律拦下。托管服务与一个 AI 网关被写成计划中,而非已发布。
真正的战略动作是那个不炫的。CrowdStrike 并没有宣称一项新颖的检测技术;它宣称的是"枚举问题是一个端点问题",而端点本来就归它。在那一群"就是普通桌面进程"的智能体上——一个编码智能体、一台本地 MCP 服务器、某位开发者周二装上的一个助手——这个说法基本上是对的,而任何基于登记册的做法都竞争不过它。
AIR:架在上下文前面的那道防火墙
AIR 在同一天走出隐身,带着由 Sequoia 与 Greenoaks 领投的 5000 万美元种子轮、由 Yair Saban 与 Niv Hoffman 组成的创始团队、二十多家集中在金融服务与制药的客户,以及一件坐在链路里、筛查什么东西进入智能体上下文的产品:指令、工具与数据,在智能体动手之前先过一遍。它公布的研究才是值得留下的那部分:超过 17,800 个公开 AI 附加组件、合计约 670 万次安装,依赖着不可信的外部指令源——也就是说,它们在运行时从安装者控制不了的地方拉取文本。
这个数字很好地说明了"部署前审查"这条路为什么有天花板。一个在运行时才去取指令的技能或 MCP 服务器,不是一件你审一次就完事的固定产物;它是一条通道。审阅清单告诉你的是它在你看的那一天是什么样。这也正是智能体供应链安全这件事别扭的地方,也是为什么一道内联控制并不与目录审查重复。
Tenable 与 OpenAI:采用之前先审
Tenable 在 8 月上线了 CyberAgents Exchange——一个面向智能体、技能、MCP 服务器与多智能体剧本的开源、安全原生登记册;在 Black Hat 的 SWARM 共建活动之后,它已收录一百多个社区提交的组件。9 月 3 日公布的 Exchange Inspector 就是架在它前面的那道审查流程:用 OpenAI 的 GPT cyber 模型做评估、经由 Tenable One AI Exposure 做技能检查,再加上 Tenable 研究员的人工复核,检视 LLM 指令、工具链式调用权限与提示词注入暴露面。
这是三者里最常规的一个,也是最容易被低估的一个。一份带公开审查流程的精选目录,正是其他每一个组件生态最终变得可用的方式;而另一条路——每个安全团队自己去读每一个技能文件——过不了几个团队就撑不住。它的局限同样常规:它管的是从正门进来的东西,而正门并不是多数东西抵达的地方。
三者共有的那个前提
把产品剥掉,底下压着的是同一句话:那份登记册并不存在。当前正在落地的每一套 AI 治理体系,开篇都是一项清单义务。欧盟《人工智能法案》对提供者与部署者的责任,预设了你知道自己在运营哪些系统。ISO/IEC 42001 要一份成文的范围。NIST 的 AI RMF 以 Map 开篇,而 Map 从枚举开始。这些框架,每一套都写得像是"一份权威名单靠问就能拿到"。
拿不到,而理由是结构性的,不是文化性的。一个经典的企业应用是走采购来的,要一台服务器,无论谁想不想要都会留下纸面痕迹。而一个智能体是以一条命令行安装的形式抵达的,跑在用户空间、用着用户自己的凭据;或者是部门本来就在付费的某个 SaaS 产品里的一个复选框;或者是某人午饭时间在自动化工具里搭出来的一条工作流。这些没有一个会经过一个"会产生记录"的控制点。它所凭借的环境权限是用户的,早就授予了,而整个流程里从来没有哪一步会去问管理员一句话。
所以当三家厂商在同一周里各自发布发现能力时,正确的读法不是"智能体安全多了一项新本事"。而是市场已经认了:那份登记册本来就填不满,于是现在改为把"从自家传感器所在之处得出的估计值"卖给你。这份认账既诚实又有用。它也很容易被误当成对那项义务的解答——而它不是:一次从单一观测点做出的普查不是登记册,而在审计里把它称作登记册,是一句你撑不住的陈述。
每一个看不见什么
把三者放在同一根轴上比,图样很干净:每一个都恰好对经过自己那道咽喉的流量是权威的,而每一个都有一大群点得出名字、却永远观察不到的对象。端点传感器在开发者的笔记本上极为出色,而对一个跑在某 SaaS 厂商产品内部、跑在 CI 执行器里、跑在一个用私人卡报销的云账号的容器里、或者跑在手机上的智能体,则结构性地看不见。内联防火墙对经它转发的东西是权威的,而对一个配了个人 API 密钥、直连模型提供方的智能体则完全无形。部署前审查管的是它自己的目录,对某位开发者从一篇博客里抄来的那个技能文件无话可说。
这些都不是对三者中任何一个的批评。这就是"埋点位置"这个词的意思。这里现成的错误,正是企业十年前在 CASB 上犯过的那个:买下传感器,看着"已发现"的计数往上爬,把一个上升的数字读作覆盖率在改善——而一个上升的数字同样可以解释成:你在抽样的那个群体正在变大,而你抽到的比例或多或少。
另外注意,三者中有两个在发现之外还卖执行,而执行正是这些层次不再可以互换的地方。在受管端点上拦下一个未获批的智能体二进制,是一道针对真实群体的真实控制。但让一个智能体变得危险的那份权限,通常住在一个令牌里,而不是一个进程里——用户一路点过去的那次 OAuth 授权、某个配置文件里的 API 密钥、某人复用的那个服务账号。把笔记本上的进程杀掉并不吊销那份授权,而同一份授权会很乐意伺候下一个进程。这就是委托访问与同意记录里的那个论证,而这一周的产品没有一个能取代它。
真正值得跟踪的那个数字
如果发现是一个估计值、而登记册是一个愿望,那么有用的仪器就是两者之差。具体说:
- 保留登记册,但别再把它当清单。它的职责从"存在什么的名单"变成"有人认领了责任的名单"。那是一件真正有价值的产物,也是一句诚实得多的主张;而这正是智能体清单与登记册实际要做的事。
- 把"已发现"与"已登记"按环境、按周期对账。两个计数,一把连接键。难的是那把连接键,也正是设计评审上值得吵一架的东西:端点传感器给出的是一个进程名与一个部署它的用户;登记册给出的是一个系统与一个负责人。把这两者连起来的那一块,没有谁卖给你。
- 把差值当趋势看,不当水位看。第一个月缝很大,意味着你的发现能力开始工作了。缝到了第六个月还在扩大,意味着智能体被造出来的速度快过有人认领它们的速度——而这本身就是一项治理发现,与任何单个智能体是否有风险无关。
- 按环境报覆盖率,别报总数。"94% 的智能体已被发现"若指的是端点智能体的 94%、而对 SaaS 毫无可见性,那它毫无意义。把这个数字按"你能在哪儿埋点"拆开,让没有传感器的那些环境显示为空白,而不是显示为零。
- 把发现出来的东西闭环。一个未登记的智能体被发现、被登记、被认领,这才是全部意义所在。如果你"已发现且无人认领"的计数逐月持平,那你买的是遥测,不是治理。
一个不太舒服的推论:你清单的完整度如今是你安全厂商传感器覆盖面的一项属性——这意味着智能体清单已经悄悄从平台团队挪到了安全团队。谁掌握传感器,谁就掌握那个计数;而审计员读的正是那个计数。这件事值得刻意地定下来,而不是在审计过程中才发现。
什么时候该拿哪一个
| 如果你的问题是…… | 部署前审查 | 端点传感器 | 内联上下文防火墙 |
|---|---|---|---|
| "我不知道有什么在跑" | 仅限它自己的目录 | 受管主机上最好的选择 | 仅限经它转发的部分 |
| "开发者乱装技能" | 强——这就是它的场景 | 事后才检出 | 在运行时筛查那些指令 |
| "某个技能在运行时才取指令" | 弱——审查只是一张快照 | 看得见由此产生的动作 | 强——这就是它的场景 |
| "跑在我没托管的 SaaS 产品里的智能体" | 否 | 否 | 只有在强制路由的前提下 |
| "我需要一份可审计的登记册" | 贡献一份目录 | 贡献一次普查 | 贡献一份流量 |
值得在最后一行上多坐一会儿。三家厂商,三份真实的贡献,而法规要的那件产物,仍然得由你自己拼出来。
常见问题
一个端点传感器足以满足 AI 清单义务吗?
不足,而声称足够是一个听上去站得住、但一被问到 SaaS 就塌掉的立场。端点传感器能给出一份关于"在受管 Windows 与 macOS 机器上作为进程运行的智能体"的有力普查。而欧盟《人工智能法案》、ISO/IEC 42001 及类似体系下的义务,其范围是你所提供或部署的 AI 系统——其中有大量从不触及一台笔记本。
为什么把休眠的智能体也发现出来很要紧?
一个休眠的智能体照样持有它的凭据与工具授权,而且通常还留着一个触发器——一个定时任务、一个 webhook、一个快捷键。只枚举正在运行的进程,给你的是一个随时段变化的计数,并且会漏掉一切等着被唤醒的东西。
内联防火墙能取代智能体自身的提示词注入防御吗?
它加了一层,也没有拿掉任何一层。筛查进入上下文的东西,能抓住已知的坏指令源与过分的权限申请;它并不能让一个智能体变得"可以放心地喂给它敌意文本",因为分类器有失败率,而真正奏效的载荷很少与你的指令相抵触。控制手段的分类见2026 年的提示词注入防御。
既然登记册不可靠,为什么还要留着它?
因为"归属"是发现不出来的。传感器能告诉你某个进程存在、是哪个账号启动的;它没法告诉你谁为它所做的事负责、它被允许碰什么,或者有没有人审过它。这些信息只有在一个人把它写下来时才存在——而这正是登记册在你不再要求它完整之后的用处。
这周最便宜的那件事是什么?
挑一个你已经有遥测的环境,数一数里面的智能体,数一数为它登记过的智能体,把这两个数字放在同一页幻灯片上。多数团队从没见过这两个数字挨在一起,而那道缝通常不用再多争就把预算谈完了。
延伸阅读
本站:
- 智能体清单与登记册——当你不再指望它完整之后,一份登记册还有什么用。
- 环境权限——为什么一个智能体不经过任何控制点就抵达了。
- 委托访问与同意记录——那份把进程杀掉也活得下来的授权。
- 检测智能体被攻陷——拿到运行时遥测之后该拿它做什么。
- 智能体供应链安全——为什么把一个组件审一次只是一张快照。