Exaforce AI Security 推出：为失控代理设置终止开关

Exaforce 于 9 月 15 日推出 Exaforce AI Security，并作出直接承诺：发现失控代理，并在其行为演变为安全漏洞之前将其制止。此次发布为 Exaforce 现有安全运营平台增加了无代理发现、风险分析、运行时检测和代理终止开关功能。

关键变化并非又一个用于追踪 AI 使用情况的仪表盘。Exaforce 希望安全团队能够将代理的行为与其背后的员工、设备、凭据、文件和云资源关联起来。这种关联至关重要，因为代理可能执行一系列单独看来都合法、但组合起来却具有危险性的操作。

Exaforce 进入的是一个已有 Microsoft、Cisco 和 Palo Alto Networks 提供代理发现与运行时控制竞争方案的市场。其差异化之处在于采用无代理模式，利用现有集成和端点遥测数据。核心问题在于，该模式能否足够准确地识别恶意意图，从而证明自动化干预是合理的。

Exaforce AI Security 将代理行为串联为同一事件

此次发布将 AI 代理的行为视为一段相互关联的连续过程，而非一组彼此孤立的日志条目。

Exaforce AI Security 已通过公司的自营平台和托管检测与响应服务正式全面推出。公司在其发布详情中介绍了三项主要功能：发现 AI 活动、识别高风险配置，以及在代理运行期间检测威胁。

发现范围涵盖 AI 应用、桌面代理、模型使用情况、Model Context Protocol 服务器、技能、插件及相关凭据。Model Context Protocol 通常简称为 MCP，是一种让 AI 系统连接外部工具和数据源的标准。

据称，该平台使用来自模型提供商、SaaS 服务、生产力套件和身份系统的 API。它还会分析 Exaforce 已收集的端点检测与响应数据。这一设计意味着客户无需仅为这些新功能额外安装端点代理。

Exaforce 表示，它能够将 AI 代理与设备上的其他进程区分开来。随后，平台会将该进程与员工身份、所用设备以及该员工可获得的权限关联。

平台还可以追踪后续活动，包括由代理打开的 shell、其读取的文件或联系的外部地址。它还会监控模型提供商日志和 AI 聊天会话，以识别敏感信息、可疑意图、提示词注入和异常使用情况。

这些上下文信息会被输入代理图谱。该图谱连接员工、代理、AI 应用、OAuth 授权、凭据、MCP 服务器、文件和可访问资源。OAuth 授权是委托权限，允许应用在无需获得用户密码的情况下访问另一项服务。

这种方法解决了一个实际的日志记录难题。代理通常通过启动它的人员所持有的凭据执行操作。因此，云审计日志可能显示一名已获授权的员工正在读取文件、轮换密钥或更新代码。

单独审查时，每个操作都可能看似合理。只有当系统将这些行为关联起来，并识别出异常的推进过程时，风险才会显现。

例如，代理可能读取浏览器 Cookie、利用存储的会话访问云服务，然后将数据发送至陌生域名。传统工具可以记录每一个步骤，却未必能识别它们共同构成了一起事件。

Exaforce 表示，其知识图谱整合了身份、端点、云、SaaS、代码和 AI 提供商信息。其检测模型随后可根据该身份的常规行为评估完整的操作序列。

公司还让安全团队自行选择响应自动化程度。一项操作可以要求分析师批准、自动执行，或依据组织政策采用介于两者之间的模式。

独立发布报道称，响应选项包括撤销会话、停用模型提供商密钥、隔离设备和终止代理进程。Exaforce 将这些操作统称为“代理终止开关”。

这个名称听起来像是一个通用的关闭按钮。实际上，它是一组针对支撑代理运行的各类资源所采取的遏制措施。

进程可以被终止，但同一工作流可能仍保留凭据，或在其他位置重新启动。因此，有效遏制需要对进程、会话、密钥、设备和已连接服务进行协调控制。

失控代理检测正成为身份问题

当自主软件继承受信任的人类访问权限，却比其所有者运行得更快、更难预测时，安全挑战便由此开始。

企业代理很少孤立运行。它可以接收任务、读取内部文档、调用 API、调用本地工具、创建代码，并与其他服务通信。

这些能力赋予代理运营价值，但也会将错误指令、遭入侵的集成或恶意提示词，转化为一连串经过身份验证的操作。

这正是 Exaforce 的失控代理检测高度关注身份的原因。系统需要回答：是谁启动了代理、它代表哪一个身份、可以使用哪些凭据，以及这些凭据能够访问哪些资源。

传统员工身份通常具有相对容易理解的行为模式。安全团队了解该员工的角色、常用设备、正常使用的应用以及预期工作时间。

代理令这一模型变得复杂。它可以持续运行、快速完成大量操作，并在每一步都无需请求批准的情况下选择工具。它还可能启动本地进程，或使用原本为更广泛人工工作流授予的权限。

由此产生的是归因缺口。日志识别出的是员工，但员工并未手动发起每一项记录的操作。调查人员必须区分人的意图与代理的执行。

Exaforce 认为，现有端点和 SaaS 工具并非为这种区分而设计。首席执行官 Ankur Singla 表示，安全团队需要将代理活动与其已经收集的身份、云和端点信息结合起来。

公司用一个关闭安全提示的 AI 桌面代理来说明这一问题。根据 Exaforce 的说法，该代理打开了 shell，复制了浏览器 Cookie 数据库，并在其中搜索企业会话 Cookie。

端点并未阻止这一活动。Exaforce 表示，其平台追踪了进程树，将该活动与一个外部地址关联，并把它与涉及同一用户和地址的 15 项更早发现联系起来。

公司将该事件归类为一级优先级发现，并称其在 11 分钟内完成了分诊。这些细节来自 Exaforce 自身环境或客户遥测数据，尚未经过独立基准测试。

不过，这一场景说明了为何运行时序列分析很重要。读取浏览器数据库可能令人怀疑，但周边的身份与网络行为决定了实际风险等级。

第二个例子涉及过度的 OAuth 权限。Exaforce 表示，它发现一款 OpenAI 应用获授权在整个 Google Workspace 环境中写入、修改、发送或删除数据。

它还发现，一个 Claude 日历集成拥有超出其预期任务所需范围的写入和发送权限。这些发现代表的是安全态势风险，而非已确认的攻击。

这一区分很重要。宽泛权限会扩大潜在影响范围，而恶意运行时行为则表明风险正在被实际利用。

Exaforce AI Security 试图将两方面联系起来。其风险层会在事件发生前识别脆弱配置，而运行时检测则寻找正在发生的滥用行为。

对安全团队而言，这带来了一项新的资产清单要求。他们不仅要了解员工访问哪些模型，还要了解哪些代理、技能、插件和 MCP 服务器能够将模型输出转化为实际操作。

这份清单必须保持最新。员工可能在没有集中部署项目的情况下安装 AI 编程扩展，或连接新的 SaaS 助手。

多年来，安全负责人一直面临类似的影子 IT 问题。代理式软件提高了风险等级，因为未经批准的应用不仅能够存储或展示信息，还能够采取行动。

无代理设计是 Exaforce 的主要押注

Exaforce 押注于现有遥测数据能够揭示代理行为，而无需在每个端点额外部署一个监控组件。

“无代理”的说法需要谨慎解读。Exaforce 并非在没有数据收集器或集成的情况下运行。它依赖来自现有端点安全产品、模型提供商、身份系统、云服务和生产力平台的信息。

“无代理”意味着客户无需专门安装额外的 Exaforce 组件来监控 AI 代理。该平台分析的是 Exaforce 已经接收的数据，或可通过提供商 API 获取的数据。

这种架构具有显而易见的运营优势。企业安全团队已经在管理拥挤的端点技术栈，而每增加一个代理，都会带来部署、维护、兼容性和性能方面的顾虑。

复用既有遥测数据可以缩短实施时间。它也可以将 AI 活动纳入与身份、云、端点和 SaaS 事件共用的调查队列。

这一统一视图是 Exaforce AI Security 的核心机制。该平台不会仅根据发送给模型的提示词或模型返回的响应来判断代理。

相反，它会审视周边活动，包括设备进程、网络连接、文件访问、账户认证、云调用、代码上下文和提供商使用情况。

打开 shell 的编程助手并不必然具有恶意。但若它打开 shell、读取凭据文件、联系陌生域名并尝试登录云服务，便构成了更具意义的行为模式。

同样的原则也适用于业务应用。日历助手访问事件符合其用途；而同一助手若获得发送电子邮件或修改无关工作区数据的广泛权限，则值得更仔细审查。

Exaforce 的风险层还会在执行前评估技能和插件。公司描述称，其发现一项与烹饪相关的技能，其分析功能会搜索并外传敏感环境变量。

该技能宣称用途与其代码行为之间的不一致提高了风险。这是通过 AI 扩展体现出来的软件供应链问题。

技能和 MCP 服务器能够迅速扩展代理能力。它们也可能引入未经审查的代码、远程依赖项以及用户并不了解的访问路径。

Exaforce 表示，其平台会为这些组件分配风险评分并提供建议。这类评分有助于确定审查优先级，但其实用性取决于检测质量和可用上下文。

无代理模式也带来了其最重要的限制。Exaforce 只能分析其接收到的遥测数据中所呈现的活动。

端点产品可能显示某个进程读取了文件，却无法揭示代理完整的推理过程，或触发该操作的提示词。模型提供商可能提供使用日志，却不会记录每一次本地工具调用。

提供商 API 在覆盖范围和时效性方面也各不相同。有些提供丰富的审计追踪，而另一些只提供有限的管理信息。本地托管模型或自定义智能体还可能产生不同类型的记录。

加密流量、不受支持的工具、断开连接的设备以及短生命周期进程都可能形成盲区。基于现有日志构建的系统必须清楚识别并披露这些缺口。

这并不意味着该架构无效。它意味着，“无代理”描述的是部署便利性，而非完整的可观测性。

评估该产品的买方应询问：每种智能体类型可获取哪些信号。针对 ChatGPT、Gemini、Copilot、Claude、本地编码智能体、自定义工作流和自托管模型，答案都会有所不同。

最强大的部署方案很可能会结合提供商记录，以及端点、网络、身份和云遥测数据。缺少其中任何一层，都可能削弱归因能力或延误遏制措施。

对于已将这些信号发送至 Exaforce 的团队而言，集成可能相对直接。使用不受支持端点或身份产品的组织，则可能面临不同的体验。

Microsoft、Cisco 和 Palo Alto 已经控制了关键层面

Exaforce 并非在创建智能体安全这一类别；它是在与更大型的厂商争夺控制权应归属何处。

Microsoft 已将 Agent 365 定位为用于观察、治理和保护智能体的控制平面。它覆盖使用委托员工访问权限的智能体，以及使用自身凭据运行的智能体。

该公司的 智能体控制平面 整合了 Microsoft Defender、Intune、Entra 和 Microsoft 365 管理功能。它可以发现本地和云端智能体、映射身份与资源，并对受支持的智能体应用策略。

Microsoft 还表示，Defender 可以将智能体映射到其设备、关联身份、已配置的 MCP 服务器以及可访问的云资源。这与 Exaforce 所推广的基于图谱的上下文能力颇为接近。

战略上的差异在于分发能力。Microsoft 已在许多企业中掌握身份、生产力、设备管理和端点安全。

因此，Agent 365 可以将智能体治理变成既有 Microsoft 管理环境中的一项功能。Exaforce 则必须证明，为什么独立的安全层能够提供更广泛或更有用的上下文。

Microsoft 的优势也可能成为限制。企业会在多个云、模型提供商、端点和 SaaS 平台上使用智能体与服务。安全团队可能更倾向于选择不以单一软件生态系统为中心的供应商。

Palo Alto Networks 通过其 AI 安全平台 Prisma AIRS 处理这一问题。Prisma AIRS 3.0 包含智能体发现、制品扫描、红队测试、身份控制和运行时强制执行。

其 AI Agent Gateway 被设计为治理和运行时控制的中心节点。Palo Alto Networks 还将 AI 安全与网络、云、浏览器和端点产品相连接。

Cisco 则通过 AI Defense 采取另一条路径。其运行时保护覆盖提示词、响应、数据流、MCP 交互和智能体工作流。

Cisco 可以利用网络可见性和威胁情报。这一优势有助于其检查智能体、模型、用户和外部服务之间的流量。

这些竞争对手表明，市场正围绕几项共同功能趋于一致：

• 发现已获批准和未经批准的智能体。

• 将智能体与所有者和身份关联。

• 映射工具、权限、数据和可访问资源。

• 评估技能、模型、提示词和集成。

• 在智能体运行期间监控其行为。

• 阻止危险操作或撤销访问权限。

• 为调查保留证据。

Exaforce 的差异化在于将这些功能置于其智能体化安全运营平台内。该公司认为，智能体活动应与其他所有企业信号处于同一调查上下文中。

这种设计可能吸引托管安全服务提供商和精简的安全团队。他们可能更愿意使用一个运营队列，而不是再使用一个专门的 AI 安全控制台。

不过，大型平台厂商也可以提出同样的整合论点。Microsoft 可以围绕其管理控制平面进行整合。Palo Alto Networks 可以围绕其安全产品组合进行整合。Cisco 则可以围绕网络和运行时强制执行进行整合。

因此，竞争的关键不在于谁最先提供智能体清单或终止开关，而在于谁能收集最相关的上下文并将其转化为准确决策。

Exaforce 还运营着自有的 AI 安全智能体，称为 Exabots，用于检测、分流、调查、追踪和响应。其平台现在正使用 AI 智能体来帮助保护其他 AI 智能体。

这种对称性同时带来价值和风险。自动化分析能够比人工团队更快处理复杂活动，但错误的模型判断可能触发不必要的遏制措施。

人工审批设置让客户能够管理这一风险。然而，若每次响应都要求审批，可能会削弱自动化所承诺的速度优势。

市场最终正走向分级自主。低风险操作可自动执行，而具有破坏性的响应则需要更有力的证据或人工确认。

智能体终止开关无法弥补薄弱的检测能力

响应控制的可信度取决于用于触发它的证据。

“智能体终止开关”这一说法暗示了确定性：系统检测到失控智能体，操作员按下按钮，威胁随即结束。

企业环境远没有这么整齐。智能体依赖进程、凭据、模型提供商账户、集成、浏览器会话和云资源。终止一个组件并不总能消除其余部分。

攻击者可能在智能体进程结束后保留 OAuth 令牌。计划任务可以重新启动该进程。被攻陷的身份可以通过另一种工具发起同样的操作。

这就是为什么 Exaforce 的响应选项不限于终止进程。会话撤销、密钥停用、设备隔离和身份控制可以同时移除多条路径。

这些操作也可能中断合法工作。隔离开发人员设备或撤销生产凭据都会带来运营后果，特别是在检测置信度不确定时。

因此，误报与漏报同样重要。若一个平台会针对每次 shell 调用、大文件读取或陌生域名都发出警报，就会压垮分析师，并使人们不愿启用自动响应。

Exaforce 表示，其上下文模型通过关联相关行为来减少这一问题。这一主张具备合理性，但发布材料并未提供独立的检测率衡量数据。

它们也未披露新智能体安全功能的误报率。没有公开基准将 Exaforce 的失控智能体检测能力与 Microsoft、Cisco、Palo Alto Networks 或专业厂商进行比较。

覆盖范围是另一项不确定因素。Exaforce 点名了包括 OpenAI、Google、Microsoft 和 Anthropic 在内的主要提供商。企业也在运行自定义智能体、开源模型、浏览器扩展和内部编排系统。

产品的有效性将取决于其能否持续识别这些不同的实现方式。在不受支持工具中运行的智能体，可能只会表现为普通进程。

行为上下文可以提供帮助，但上下文不等于意图。安全测试智能体可能会收集 Cookie 或探测访问边界，作为获授权演练的一部分。

被攻陷的智能体也能模仿正常工作。它可能通过获批准的服务少量外传数据，或保持在用户现有的访问模式内。

自动响应还带来治理问题。客户必须决定平台可在无需确认的情况下执行哪些操作，以及这些操作造成中断时由谁负责。

成熟的策略应将响应权限与置信度、资产敏感性和业务影响联系起来。终止低价值实验性进程，与禁用生产系统使用的凭据并不相同。

安全团队还应在启用完全自主之前测试故障模式。演练可以衡量被隔离的端点是否仍可用于调查，以及密钥撤销是否会影响无关服务。

最具说服力的证据将来自有文档记录的客户部署。买方需要了解发现需要多长时间、哪些智能体仍然不可见，以及有多少发现需要分析师修正。

他们还需要涉及真实对抗活动的案例，而非仅是风险权限或刻意不安全的测试配置。态势发现和威胁检测解决的是不同问题。

Exaforce 报告的实时租户案例提供了早期视角，但不足以证明其在多样化企业环境中的普遍表现。

这正是 Exaforce AI Security 背后的主要权衡。无代理部署可以减少上线阻力，但对现有遥测数据的依赖可能导致可见性不均衡。

在 Exaforce 已获得丰富端点、身份、云和提供商数据的环境中，该产品可能表现良好。只要这些信号不完整，其结论的确定性就会降低。

什么将证明 Exaforce AI Security 有效

下一项考验不是又一次功能发布，而是可衡量的证据：该平台能够发现危险序列，同时不干扰合法智能体。

首先需要关注的是独立客户验证。Exaforce 需要提供部署报告，说明它发现了哪些智能体、最初遗漏了哪些风险，以及分析师如何处理其发现。

有价值的证据应区分资产清单覆盖、态势分析、主动威胁检测和响应。将这些结果合并为一项成功主张，会使评估变得困难。

客户结果还应披露每个环境中可用的遥测数据。建立在广泛端点和身份覆盖基础上的检测表现，不应被泛化到集成较少的组织。

强劲的现场结果将强化 Exaforce 的主张：现有数据能够支持无代理运行时安全。持续存在的盲区则会削弱其核心设计论点。

第二项信号是更广泛的集成覆盖。当前发布连接了主要模型提供商，并利用现有端点和企业数据。

企业对智能体的采用不会长期集中在少数产品中。内部团队可以利用开放模型、代码框架、MCP 服务器、命令行工具和自定义 API 组装智能体。

Exaforce 必须持续识别新的智能体形态，而无需为每一种形态配备专用传感器。只有在提供足够数据以支持归因和响应时，集成公告才有意义。

仅支持发现还不够。安全团队需要进程关系、工具调用、权限、凭据、网络目标和响应控制。

第三项信号是竞争对手的反应。Microsoft、Palo Alto Networks 和 Cisco 已在身份、端点、网络和云等领域占据了有价值的强制执行点。

如果这些厂商将跨平台智能体上下文作为既有产品的标准组成部分，Exaforce 将面临更强的分发压力。如果它们的工具仍局限于狭窄的生态系统，独立的关联层就会更具吸引力。

定价并非唯一的采购因素。安全团队还将比较部署工作量、调查质量、集成深度、托管服务选项，以及错误自动化操作所带来的后果。

Exaforce 的定位对于已经使用其安全运营平台或 MDR 服务的组织最为明确。新功能可将 AI 智能体活动纳入既有工作流程。

新客户则面临更广泛的平台选择。他们必须将 Exaforce 与其身份、端点、云或网络技术栈中已包含的控制措施进行比较。

此次发布也凸显出围绕智能体活动建立机构记忆的需求日益增长。调查人员需要获取早期部署中的决策、审批、事件证据和经验教训。

可搜索的 AI 知识库 可以帮助团队保留这些背景信息，但无法替代运行时安全控制措施。

对于企业采购方而言，眼下应在选择安全平台前，先盘点智能体及其访问权限。明确每个智能体的负责人、所用凭证，以及它能够更改哪些系统。

随后，应使用贴近实际的场景测试 Exaforce AI Security 或竞品平台。其中应包括提示注入、过度的 OAuth 权限、可疑工具链、凭证访问、数据流转，以及看似攻击的合法工作流。

既要衡量检测能力，也要衡量干预效果。最终胜出的平台不会是那些使用最耸动“紧急终止开关”措辞的平台，而是能够持续区分危险自主行为与高效自动化，并在恰当层级作出响应的平台。