Eagle Cloud B+轮融资检验AI Agent安全统一治理路径

Eagle Cloud在上一轮融资四个月后完成近1亿元人民币B+轮融资，用于扩展AI Agent安全治理。该公司希望通过统一的身份、策略和审计框架来管理人类用户与自主Agent。这一时点也构成了Eagle Cloud B+轮融资背后的核心矛盾：企业当前就需要Agent控制能力，但统一治理在真实系统中的有效性仍难以验证。

根据该公司9月14日的公告，MTR Lab与北极光创投共同参与本轮投资，Voyagers Partners担任财务顾问。Eagle Cloud表示，将投资于其企业生产力治理平台，并扩大国际团队、市场覆盖及本地交付能力。

这一定位使Eagle Cloud面对的是由身份、端点、网络、应用和数据等独立控制措施构成的碎片化安全模式。Microsoft、Palo Alto Networks、Zenity等厂商也在将Agent身份与运行时执行控制结合起来。Eagle Cloud必须证明，其现有访问基础设施提供的价值不止是又一个管理控制台。

Eagle Cloud B+轮融资支持更广泛的控制层

这笔新资金支持Eagle Cloud尝试将办公安全平台转变为AI Agent的运营控制层。

该公司将其Yunshu平台描述为一套面向组织内所有执行工作的行为主体的共享治理系统。这些主体如今包括员工、传统软件，以及能够选择工具并执行多步骤任务的AI Agent。

AI Agent是能够在有限人工指导下，为实现目标进行规划并采取行动的软件。与仅返回文本的聊天机器人不同，Agent可以检索记录、更新应用、调用API，或触发下游工作流。

这种能力改变了安全问题的性质。聊天机器人可能在回复中泄露机密信息，而Agent还可能移动这些信息、修改业务记录、启动流程，或授予其他系统访问权限。

Eagle Cloud的解决方案是Yunshu AIDR，即AI Detection and Response。该公司表示，该产品通过五个阶段治理Agent：发现、定义、识别、执行和度量。

发现旨在识别Agent及其配置，包括通常被称为影子AI的未授权或未知部署。定义则创建一份运营合同，明确Agent的目的、职责、权限、持续时间和资源限制。

识别为每个Agent分配唯一身份，并关联其创建者、用户和负责所有者。执行会将实时行为与运营合同进行比对，再根据风险发出告警、限制或阻止相关操作。

度量将资源使用情况与工作流、所有者和结果关联起来。Eagle Cloud将这一最终阶段定位为治理功能，同时也是评估Agent是否产出有用工作的方式。

这份融资披露称，新一轮资金将用于持续的平台开发和国际扩张。香港是该计划的核心，Eagle Cloud将香港深圳创新及科技园作为海外基地。

9月融资紧随5月宣布的B轮融资。此前一轮融资规模达数亿元人民币，由Monolith领投，Future Innovation Fund再次参与。

四个月内的两轮融资并不能独立验证该产品。但这表明，投资者正将Agent治理视为基础设施类别，而非短暂的合规功能。

Eagle Cloud眼下面临的挑战是执行。它必须将投资转化为可跨不同身份提供商、软件环境、云平台和监管辖区运行的部署成果。

这使得本次融资比常规网络安全融资公告更具意义。Eagle Cloud押注的是一种特定架构：现有企业控制点可以扩展至治理自主Agent，而无需另建一套安全技术栈。

AI Agent为何让现有安全团队承压

安全团队面对的是一种新型行为主体：它能够持有权限、作出选择，并以快于人工审查流程的速度采取行动。

传统身份与访问管理假设，一个可识别的主体会请求访问某一明确资源。该主体可能是员工、服务账户、工作负载或应用程序。

AI Agent给这一模型带来压力，因为其行动取决于不断变化的指令、检索到的上下文、模型输出和可用工具。Agent可能在一项任务中运行正常，却在下一项任务中采取非预期路径。

在这两项任务中，它的正式权限可能始终不变。因此，安全问题不再只是访问是否被允许。团队还必须判断，被允许的操作是否符合该Agent被分配的目的。

这一区别将授权与对齐区分开来。授权关注某个身份是否有权执行某项操作。对齐则关注该操作在当前条件下是否服务于预期任务。

员工可以解释为何修改某条客户记录。传统应用遵循调查人员可检查的代码。AI Agent则可能动态构建操作序列，使得仅凭普通访问日志更难推断其意图。

美国国家标准与技术研究院已认识到这一缺口。其身份概念论文探讨了既有身份标准和授权实践如何适用于软件和AI Agent。

这份论文的存在具有意义，因为它表明Agent身份并非仅是厂商创造的类别。标准机构正在研究应如何向Agent授予权限、如何约束这些权限，以及组织如何建立问责机制。

在业务部门持续部署Agent的同时，安全团队必须处理这些问题。完全阻止采用通常并不现实。允许Agent继承广泛的用户权限，则会带来另一种、且可能更大的风险。

开发者同样面临压力。他们需要定义Agent可调用哪些工具、每项工具暴露哪些信息，以及凭证如何在工作流中流转。

随后，企业采购方必须确定执行控制发生在哪里。策略可以部署在身份提供商、Agent框架、API网关、云平台或专门的安全产品中。

每个位置只能看到交易的不同部分。身份系统了解谁或什么获得了访问权限；网络工具观察连接；数据工具理解敏感记录；Agent平台则能看到提示词、计划和工具调用。

Eagle Cloud认为，其现有控制点能够连接这些视角。根据该公司的说法，其平台已经覆盖身份、端点、网络、应用和数据。

这一主张具有战略重要性，因为碎片化可见性会延迟决策。若一条告警需要分析师比对多个控制台，便无法在机器速度的操作完成前将其阻止。

因此，安全负责人被迫作出的回应是架构层面的，而不只是流程层面的。他们需要决定，是围绕共享控制平面整合Agent治理，还是集成多种专业产品。

这一决定将长期塑造采购方向，也将决定Agent活动是成为一等安全记录，还是继续散落在传统日志之中。

统一治理与碎片化安全技术栈之争

Eagle Cloud的核心押注是，应由同一控制平面管理人员和Agent，而竞争对手则将问题分配到不同的专业层。

统一方法始于一个简单观察：Agent通常通过企业已经监控的基础设施访问业务系统，包括身份、设备、应用、网络和数据存储。

如果这些控制点共享策略和审计记录，企业理论上便可以追踪一项操作：从发起请求的用户，到Agent，再到受影响的系统。这条链路可使责任归属更容易确立。

Eagle Cloud表示，Yunshu对人类员工和AI Agent采用相同的身份、策略和审计模型。该公司还将默认拒绝、显式授权和操作可观测性描述为其核心护栏。

默认拒绝意味着，除非策略授予权限，否则Agent不会获得任何访问权。显式授权定义获准访问的资源和操作。可观测性则记录Agent尝试了什么，以及平台允许了什么。

这些原则在零信任安全中并不陌生。零信任会持续评估访问请求，而非仅因某个主体进入网络便信任它。难点在于，如何将这些原则应用于不断变化的Agent行为。

Agent在一项任务中可能需要临时访问多种工具。静态权限可能过于宽泛，而反复进行人工审批又可能抹去采用Agent所带来的生产力收益。

因此，统一平台必须足够快速地评估身份、任务上下文、请求的操作、受影响的数据和当前风险，以保留有价值的自动化能力。它还必须生成调查人员日后能够理解的记录。

Cloud Security Alliance发布的运行时治理模型描述了一个相关问题。常见身份协议围绕行为比自主Agent更稳定、更可预测的主体而设计。

这并不意味着既有身份标准已经过时，而是说明仅靠身份无法表达安全团队需要了解的关于Agent当前目的和委托权限的全部信息。

专业厂商正从不同位置弥补这一缺口。Zenity专注于Agent感知的可见性和运行时执行控制。Microsoft则将Agent身份与其Entra、Purview、Defender及AI开发系统连接起来。

Palo Alto Networks正将身份和运行时安全扩展至其更广泛的网络安全平台。其他厂商则专注于模型保护、数据泄露、非人类身份、浏览器活动，或用于Agent工具的网关。

Zenity的Microsoft集成展示了专业化模式。Microsoft提供开发环境和身份集成，而Zenity则增加以Agent为中心的运行时控制和跨Agent可见性。

Eagle Cloud追求的是更高程度的垂直整合。它希望通过一个平台发现Agent、建立其运营合同、执行行为控制、审计操作，并将活动与现有企业基础设施连接起来。

其好处是一致性。共享策略模型能够减少不同工具以不兼容方式描述身份、资源和风险时产生的缺口。

其缺点则是集中化。若平台错误分类某项操作，或无法看见某个应用，它可能在整个环境中形成共同盲区。

专业产品能够为特定系统提供更深入的控制能力，但也会增加集成工作，并可能产生相互冲突的决策。

这正是 Eagle Cloud B+ 轮融资所引发的核心竞争。Eagle Cloud 必须证明，整合能够提升执行质量，而不只是让采购更方便。

单一界面并不等同于共享控制平面。真正的考验在于：一项策略能否在不丢失上下文的情况下，伴随一个智能体穿越身份、网络、应用和数据边界。

五阶段模型仍需独立验证

Eagle Cloud 描述了一套连贯的治理机制，但多数性能和部署声明目前仍主要来自该公司自身。

Eagle Cloud 表示，其服务覆盖 20 多个行业的逾 1,000 家企业，并管理超过 500 万个端点。这些数字载于其公司数据，但公开可得的客户层面证据仍然有限。

该公司尚未披露其中有多少企业已在生产环境中使用 AIDR，也没有将传统办公安全部署与活跃的智能体治理部署分别统计。

这一区分很重要。受管理的端点并不一定连接到 AI 智能体。使用安全访问服务的客户，也不一定已将具有重要业务后果的操作委托给自主软件。

该平台的发现阶段构成首个技术考验。在受支持平台内发现获批准的智能体，与检测通过脚本创建、嵌入式软件功能生成或来自未知外部服务的智能体，是两回事。

不完整的资产清单会削弱后续所有控制。平台无法治理其无法识别的智能体。

运行契约带来了第二项挑战。用途、责任、权限、有效期和预算在设计文档中听起来很明确，但生产任务往往存在模糊地带。

设想一个被分配在销售会议后更新客户记录的智能体。它可能需要总结会议笔记、识别正确账户、添加后续任务，并通知同事。

宽泛的契约会允许智能体接触许多记录和沟通渠道。过于狭窄的契约则可能在会议涉及异常账户结构或跨团队请求时失效。

身份阶段还必须处理委托关系。一个智能体可能代表某位员工、一个部门或另一个智能体行事。它也可能调用使用共享服务凭据而非自身身份的工具。

如果身份链断裂，审计记录或许能显示是哪一个应用发起了请求，却无法说明是谁授权了底层任务。这会限制问责能力。

执行控制带来了最棘手的问题。Eagle Cloud 表示，AIDR 会持续根据运行契约检查行为，并可对智能体发出告警、施加限制或进行拦截。

有效执行不仅需要观察流量。平台必须理解所请求的操作、相关业务上下文，以及阻断操作可能带来的后果。

漏报会放任有害操作。误报则会中断正常工作，并促使用户绕过控制措施。

度量阶段引入了另一项不确定性。将模型使用和工作流成本与结果相连接，有助于预算管理，但不同部门之间很难统一结果质量的衡量标准。

已解决的支持工单、被修改的数据库记录和起草完成的市场分析，并不存在统一且可靠的衡量尺度。成本核算也无法自动证明智能体是否安全或有效地采取了行动。

针对这些能力的独立基准测试仍不成熟。因此，买方应要求与自身系统、工作流和故障场景相关的证据。

有用的测试包括：已撤销的访问权限、已过期的委托、提示词注入、遭入侵的工具、意外数据检索，以及智能体之间的任务转移。买方应观察平台是否能阻止相关操作，并保留清晰可理解的审计线索。

OWASP 更广泛的智能体安全工作为威胁建模提供了有用参考。该倡议研究了智能体进行规划、使用工具、维护记忆并与其他系统交互时所产生的风险。

Eagle Cloud 的融资并不能回答 AIDR 对这些风险的处理效果如何。它只是为公司构建和部署自身答案提供了更多资源。

这一区别至关重要。在客户能够测试其覆盖范围、延迟、兼容性和错误率之前，获得融资支持的安全架构仍只是一项主张。

国际扩张提高了治理门槛

走出中国市场将考验 Eagle Cloud 的统一模型能否适应不同的技术栈和问责规则。

该公司表示，计划扩充团队、进入更多市场并改善本地化交付。它已将香港、澳门和东南亚视为重要增长区域。

MTR Lab 的参与为本轮融资带来了实际的跨境维度。该投资方表示，随着 AI 进入业务流程，Eagle Cloud 在集成化网络安全治理方面展现出潜力。

Northern Light Venture Capital 将这一机遇概括为两大趋势：企业 AI 使用的扩张，以及中国科技公司的国际化增长。这两种趋势都会创造需求，但也会提高部署复杂度。

在多个市场运营的企业，必须管理有关个人信息、安全事件报告、数据传输和自动化决策系统的不同规则。共享审计模型能够提供帮助，前提是它能记录每个司法辖区所要求的信息。

本地化也不仅是翻译界面。平台还必须与区域身份系统、云服务提供商、应用、安全运营体系和服务伙伴集成。

采用 Microsoft 365、Entra 和 Azure 的企业构成一种环境。另一家围绕 Alibaba Cloud、DingTalk 和国内业务软件搭建的企业，则呈现另一组控制点。

跨国组织通常会同时使用两类环境。它们也可能收购过拥有独立身份目录和不一致数据分类的业务部门。

在这种环境中，Eagle Cloud 的整合主张更具价值，但也更难实现。如果集成对身份和资源的解释不同，策略便无法保持统一。

该公司还面临拥有成熟国际销售渠道的既有平台厂商。Microsoft 可以将智能体控制能力部署在企业已经签约的身份和生产力产品旁边。

Palo Alto Networks 可以通过网络和云安全客户关系延伸智能体安全能力。专业厂商则可以与多个平台集成，同时主张自己不依赖任何单一生态系统。

Eagle Cloud 的优势可能来自其 SASE 背景。Secure Access Service Edge 通过云交付基础设施结合网络和安全功能，使平台能够在关键访问点获得可见性。

这一基础有助于发现活动并执行连接层规则，但它不会自动揭示智能体为何作出某项决策，或工具调用是否符合用户意图。

Eagle Cloud 必须将基础设施可见性与智能体特定上下文连接起来。产品需要知道是哪个智能体采取了行动、谁委托了权限、当前执行什么任务、涉及哪些数据，以及适用什么策略。

该公司的“人类加 AI”表述，只有在这条链路保持完整时才有意义。否则，统一治理就会沦为涵盖若干松散连接模块的宽泛标签。

全球扩张将迅速暴露这种差异。国际客户会将 Eagle Cloud 与嵌入其现有身份、云和安全系统中的产品进行比较。

他们还会期待有关数据处理、支持覆盖范围、集成可靠性和事件响应的证据。投资者支持可以为这些能力提供资金，但无法替代本地信任。

因此，最可信的国际化成果将涉及复杂的生产工作流，而非有限的演示。跨越多个身份系统和业务应用的部署，比孤立试点能提供更有力的证据。

三项信号将决定这笔押注是否奏效

客户采用、可衡量的执行效果以及跨平台交付能力，将决定 Eagle Cloud 成为基础设施还是仍停留在雄心勃勃的安全厂商阶段。

第一项信号是生产环境中 AIDR 部署的数量和质量。Eagle Cloud 应将使用智能体治理的客户与使用其既有访问及端点产品的客户区分开来。

具名案例研究最具价值的前提是，它们能描述工作流、权限、涉及的系统，以及平台阻止或批准的操作。汇总端点数量无法提供这类证据。

如果 Eagle Cloud 披露多个行业中的可复制部署，其统一控制平面的论点将更具说服力。如果披露内容继续将传统安全与智能体治理混合统计，产品采用情况仍将难以判断。

第二项信号是技术验证。买方需要在真实的智能体行为条件下，获得可衡量的发现覆盖率、执行延迟、误报率和审计完整性。

测试应涵盖间接提示词注入、权限过度、工具定义变化、授权过期和多智能体委托。测试还应展示平台如何处理不受支持的应用和加密流量。

即使结果暴露局限，公开评估方法也会增强 Eagle Cloud 的地位。安全产品买方期待明确边界。毫无保留的声明往往比清楚记录的缺口更令人担忧。

缺乏独立测试会削弱融资叙事。这将表明资金到位的速度快于关于五阶段模型是否能在生产环境中运作的证据积累速度。

第三项信号是国际集成。应关注香港、澳门和东南亚的合作伙伴关系及客户部署，尤其是涉及混合云和身份环境的项目。

成功的跨平台部署将支持 Eagle Cloud 的主张：现有安全控制可以构成统一的智能体治理层。若成功案例仅限于严格受控的技术栈，这一主张的适用范围就会更窄。

竞争对手的反应也属于这一信号的一部分。Microsoft、Palo Alto Networks、Zenity 及身份厂商都在朝着持续控制智能体行为的方向发展。

Eagle Cloud 无需在每个市场击败每一家厂商。它需要明确其 SASE、身份、数据、端点和智能体控制能力的组合，在哪些场景下能够带来清晰的运营优势。

Eagle Cloud 的 B+ 轮融资为公司争取了证明这一点的时间和资源。由于这是四个月内宣布的第二轮融资，它也提高了外界预期。

企业买方现在应在操作层面要求证据。系统能否识别一个智能体、追踪被委托的权限、评估一次工具调用、阻止不安全的操作，并在事后解释这一决定？

这些问题为每个 AI 智能体安全平台提供了实用检验标准。如果 Eagle Cloud 能在真实客户环境中回答这些问题，其统一治理模型便值得关注。如果不能，市场仍会继续将这一问题分散交给身份平台、安全套件和专业工具解决。