员工自建 AI 超越企业管控,Pluto Security 融资达 4200 万美元
Pluto Security 结束隐身模式并融资 4200 万美元。该公司发现,员工自建的 AI 应用可能在安全团队察觉之前就带来严重风险。此次 Pluto Security 融资包括一轮 850 万美元的种子轮融资,以及由 Jump Capital 领投的 3400 万美元 A 轮融资。它也将一个熟悉的职场问题转化为紧迫的安全议题:当几乎任何员工都能构建软件时,谁来控制这些软件?
该公司称,一款新发布的 AI 工具可能在两小时内出现在企业环境中。它还表示,在其客户群中检测到的风险里,约 60% 与非开发人员创建的应用有关。财务团队产生的风险占比最高,其后是营销和法务部门。
这种模式改变了传统的安全版图。过去,开发人员控制着大部分软件创建工作,而安全团队审查的是可预测的系统和部署路径。如今,AI 构建工具、编程助手、扩展程序和智能体将这类活动扩展至整个员工队伍。
Pluto 并非唯一押注于现有控制措施存在重要缺口的公司。Reco、WitnessAI、Prompt Security 及其他供应商都在布局企业 AI 安全的相邻领域。它们不断扩大的融资规模表明,投资者预计智能体活动将成为一个独立的安全市场,而非成熟工具中的另一项功能。
Pluto Security 融资支持更广泛的控制层
此次融资之所以重要,是因为 Pluto 正在为传统安全产品并非为解读的活动出售一层控制能力。
Pluto 于 2026 年 10 月 13 日宣布正式公开发布。其融资包括由 TLV Partners 领投的种子轮,以及由 Jump Capital 领投的 A 轮。Skinos、Ansa Capital,以及多位网络安全领域创始人和天使投资人也参与了投资。
联合创始人兼 CEO Shahar Bahat 告诉 TechCrunch,公司于 4 月开始销售,目前年经常性收入已超过 200 万美元。Pluto 称已拥有超过 30 家企业客户,包括 Oscar Health、Workato、Sixt 和 AlphaSense。这些数据仍为公司披露,尚非经独立审计的结果。
Pluto 在美国和以色列共有 40 名员工。该公司计划将资金用于产品开发、安全研究以及拓展美国市场。其公司发布说明将该业务描述为一个 AI 工作空间安全平台。
这一定位反映出其产品范围比一份获批 AI 服务的基础目录更广。Pluto 称其会观测 AI 工具、编程环境、扩展程序、技能、Model Context Protocol 服务器、应用和自主智能体。Model Context Protocol,简称 MCP,是一种让 AI 系统连接外部工具和数据的标准。
这种区别很重要,因为企业风险已不再局限于员工把机密文本粘贴到聊天机器人中。员工现在可以组装应用、授予其访问业务系统的权限,并让智能体执行操作。每一步都会引入权限、依赖关系、数据流和执行路径。
根据最初的融资报道,Pluto 曾在一家《财富》500 强公司发现一个由员工构建的财务应用,它处理客户和流失信息。该应用据称暴露在公共互联网中。TechCrunch 未披露该公司名称,事件细节由 Pluto 提供。
这一案例说明了员工自建软件为何难以治理。一名财务分析师或许了解客户数据和业务逻辑,却未必理解身份验证、网络暴露或依赖项安全。AI 降低了组装可用应用所需的工作量,但不会自动补齐这些缺失的专业能力。
Pluto 将这一不断扩张的环境称为 AI 工作空间。每个终端都可能成为员工创建软件、安装智能体组件,或将内部数据连接至第三方服务的场所。因此,安全团队必须先追踪现有事物,才能决定应当阻止、限制或批准什么。
这一挑战使 Pluto Security 融资的目的更为清晰。该公司不只是保护一个新的聊天机器人界面,而是试图治理一个分布式软件工厂;它已在各个部门中出现,其扩张速度快于正式开发流程所能跟上的速度。
非开发人员正在扩大攻击面
AI 已将软件创建转向目标是运营效率而非安全部署的员工。
过去的影子 IT 问题,是员工采用未经批准的软件订阅或云存储。影子 AI 则增加了能够生成代码、连接业务工具,并通过用户权限采取行动的系统。由此产生的风险,比一个藏在登录界面后的未获批准应用更具动态性。
Pluto 称,财务部门是其检测到的 AI 风险最大来源。营销和法务部门紧随其后,而开发人员排在第四位。这样的排序引人注目,因为安全计划传统上将开发控制集中在工程组织周围。
非开发人员往往接触高价值信息。财务团队可访问预测、交易记录和客户经济数据。营销团队管理客户名单和发布系统,法务团队则处理合同和机密通信。
当这些员工构建 AI 辅助工具时,可能会无意中创建拥有重大访问权限的应用。风险并不需要恶意意图才会发生。一个有用的原型,可能在任何人审查其凭据、存储配置或公共暴露情况之前就已投入运行。
快速采用令发现变得更加困难。Bahat 表示,一款新 AI 工具可在发布两小时内出现。这种速度几乎不给采购、法务审查、数据分类或传统安全测试留下时间。
独立研究支持了对未经授权采用的更广泛担忧。2025 年一项职场 AI 研究发现,44% 的员工以未经授权的方式在工作中使用 AI。在这些员工中,46% 表示曾将敏感公司信息或知识产权上传至公共平台。
这些调查结果描述的是员工行为,而非已确认的安全事件。但它们仍说明,仅封锁一小批热门聊天机器人域名无法解决问题。员工可以使用个人账户、浏览器扩展程序、本地模型、编程工具,以及安全团队从未评估过的新服务。
首席信息安全官面临双向压力。业务领导者希望扩大 AI 采用,因为员工可以自动化研究、分析、沟通和内部工作流程。安全负责人则必须控制其中涉及的数据和操作,同时不能成为否决每项试验的部门。
一刀切的禁令往往会把活动推向更不显眼的渠道。当获批工具不够用时,员工可能会使用个人设备或账户。这种行为削弱了组织识别数据暴露、撤销访问权限或调查事件的能力。
不受限制的访问则会造成相反的失败。员工可以将智能体连接到客户数据库、消息系统、代码库和云资源。智能体随后可能以从用户继承的权限运行,即使其任务只需要其中一个很小的子集。
这正是企业 AI 安全与基础可接受使用政策产生分歧之处。一项书面规则无法揭示智能体调用了哪个连接器,也无法判断某个扩展程序是否引入恶意代码。它同样无法在不安全操作发生时加以中断。
因此,安全团队需要一份实时的工具、组件、智能体和员工自建应用清单。他们还需要了解预期行为的上下文。对于开发人员而言,同一条命令可能司空见惯;但若由无关的营销工作流程触发,则可能显得可疑。
Pluto AI security 围绕这一上下文问题设计。该公司称,它结合了工具发现、风险分析和实时干预。其机会取决于这一方法能否在不过度收集员工数据或干扰正当工作的情况下,为防御者提供有用的控制能力。
Pluto AI Security 从用户转向智能体
Pluto 的核心押注是:安全工具必须在智能体行动期间评估其行为,而不只是验证启动它的人员身份。
传统的终端和身份系统仍然必不可少。它们可以检测恶意软件、管理设备、验证用户身份,并限制对受保护资源的访问。然而,一个获得授权的智能体仍可能通过有效的用户会话采取非预期操作。
Bahat 将这种转变概括为从用户行为转向智能体行为。例如,一名员工可能有正当理由访问客户系统;但为该员工工作的智能体,可能尝试导出记录、联系外部服务或请求更广泛的权限。
Pluto 可与终端安全和设备管理系统连接。它可以通过这些系统部署传感器,也可以直接在设备上安装传感器。据称,该平台收集的信号包括提示词、命令、进程、权限以及此前的用户活动。
该公司称,在终端上运行的轻量级模型有助于解读智能体的意图。如果智能体请求的权限超出用户表面目标,Pluto 可以阻止该操作。它也可以插入指令,要求智能体请求确认。
这种干预模式超越了观察。许多治理工具侧重于发现、分类和政策报告。Pluto 希望在智能体完成高风险任务前,对正在进行的会话施加影响。
一个简单案例展现了其潜在价值。员工可能要求智能体总结近期客户取消服务的情况。读取经批准的记录支持这一任务,而导出完整客户数据库则不支持。
运行时控制可以通过检查权限、命令和上下文来区分这两条路径。它可能允许读取操作,同时阻止向外部传输。困难之处在于,要跨越拥有不同界面和执行模型的工具,持续一致地做出这一判断。
Pluto 还运营 Plutonium,这是一项免费服务,用于检查公开可用的 AI 技能、MCP 服务器、连接器和附加组件。该服务包括一个 MCP 扫描器和一份已评估组件目录。公司称,数千名安全专业人士正在使用它,不过这一数字尚未得到独立验证。
Plutonium 有两个作用。它提供企业可能遇到的组件相关安全研究,也为潜在客户进入 Pluto 的商业平台提供入口。Bahat 表示,入站兴趣目前贡献了公司销售管道的 70%。
这一平台战略反映了 AI 组件传播的速度。员工无需从零开始编写整个应用。他们可以将模型、连接器、下载的技能和访问凭据组合为可运行的自动化流程。
每个导入组件都会扩展信任链。遭入侵的软件包可能窃取机密、篡改提示词、重定向输出,或执行不需要的命令。MCP 服务器同样可能暴露超出智能体预期任务范围的能力。
这一机制解释了为何 Pluto AI 安全同时关注组件与运行时活动。安装前扫描连接器可以识别已知问题;而在执行期间监控智能体,则能应对多个受信任组件交互后才显现的危险行为。
这种方法也带来了显著的隐私问题。提示词、命令和历史活动可能包含敏感的个人或商业信息。企业必须了解 Pluto 收集哪些信息、在哪里处理这些信息,以及数据会保留多久。
如果终端模型在本地处理信号,或许能减少一部分暴露风险。然而,Pluto 尚未公开足够的架构细节,无法确定各类部署方式下确切的隐私权衡。买方需要进行技术验证,而不能只依赖产品说明。
真正的较量是赋能与控制之间的平衡
核心矛盾并不是 Pluto 与某一家竞争对手之间的对抗,而是员工自主性与为集中式软件开发而构建的安全体系之间的冲突。
AI 构建工具承诺,让员工无需等待工程资源便能解决运营问题。这一承诺已经在改变企业内部由谁来创建应用程序,同时也削弱了过去让软件活动保持可见的检查机制。
安全团队可以采取封锁未经批准的工具、禁用连接器,并将智能体限制在狭窄环境中的做法。这种方式能降低即时风险敞口,但也会限制业务领导者期待的生产力收益,并可能促使员工绕开官方控制措施。
另一种选择是受监管的采用模式。员工仍可使用 AI 工具,而安全系统负责发现组件、检查权限,并在行为违反政策时进行干预。Pluto 的产品与传播定位正是围绕这一路径展开。
这种权衡比听上去更难。运行时控制必须足够快地作出决策,避免拖慢员工效率;同时还必须理解足够的上下文,才能区分合法自动化与不安全自动化。
误报可能使赋能平台变成另一套阻断系统。如果用户反复面对不必要的审批,他们可能会放弃获批的工作流程。安全团队也可能因此失去购买该产品原本希望获得的可见性。
漏报则会造成相反的问题。防御人员尚未理解智能体的意图前,它就可能已执行破坏性操作。尤其当工作流跨越本地设备、云应用和外部服务时,对活动进行判断的模型可能缺乏完整上下文。
竞争对手正从不同起点切入市场。Reco 强调身份、权限、已连接应用,以及智能体能够访问的数据。其近期的智能体安全融资获得了 5500 万美元,也进一步印证了这一市场正变得拥挤。
WitnessAI 专注于治理企业用户、AI 系统、数据与智能体之间的交互。其企业 AI 融资总额达到 5800 万美元,投资者包括 Sound Ventures、Fin Capital、Qualcomm Ventures 和 Samsung Ventures。该公司也重点强调数据流控制与智能体治理。
其他厂商则聚焦模型安全、提示词攻击、AI 应用测试或数据泄露防护。成熟的终端、身份和云安全公司可以将其平台延伸至同一领域;它们已经拥有客户关系以及可用的遥测数据访问能力。
因此,Pluto 必须证明,AI 专用控制层能够比现有产品的扩展功能作出更好的决策。它还需要足够广泛的集成能力,以便在碎片化的企业技术栈中跟踪智能体。新的 AI 工具出现的速度,可能快于任何单一厂商构建原生支持的速度。
该公司早期的营收与客户主张表明市场确有真实需求。然而,需求尚不足以证明这是一个可持续的品类。买方最终可能会将智能体控制功能整合进终端、身份、浏览器、云或数据安全平台。
另一项风险与企业智能体本身的成熟度有关。企业正在试用智能体,但许多公司尚未在关键工作流程中大规模部署它们。如果雄心勃勃的智能体项目仍然受限或不可靠,安全支出可能会超过生产环境的采用速度。
这并不意味着当前的影子 AI 问题会消失。员工构建的应用和未经批准的工具已经造成可见性缺口。但这也意味着,Pluto 必须在服务当下混乱使用状况的同时,为更具自主性的系统做好准备。
该公司的干预机制是其最重要的主张,也是最严峻的考验。在演示中拦截过度的权限请求听起来并不复杂;但要在数千种不同工作流中贯彻这一决策,则需要准确的上下文、稳定的集成,以及员工能够理解的政策。
企业 AI 安全买方应要求提供可衡量的结果。实用指标包括发现的工具数量、确认的风险暴露、拦截的操作、误报率、调查时间,以及员工对获批工作流的采用情况。客户标识和融资总额无法替代这些运营证据。
4200 万美元并不能证明什么
Pluto Security 的融资验证了投资者兴趣与早期客户需求,但并不能验证其每一项检测或预防主张。
发布报道中大多数详细的风险数据都来自 Pluto 自身,其中包括非开发人员约占已检测风险 60% 的说法,也包括一家《财富》500 强公司的应用被暴露在互联网上的报道。
这些披露是可信的线索,但公开证据缺乏方法论细节。Pluto 尚未披露支撑这一 60% 数据的数据集规模或构成,也未说明每项发现是否具有相同严重程度,或如何处理重复问题。
该公司还称,每次概念验证都发现了恶意内容。Bahat 向 TechCrunch 表示,一些扩展包或技能在评估期间显示出活跃攻击。由于缺乏具名事件或独立确认,读者应将这一表述视为公司的主张。
“恶意”可以涵盖多种情况。某个组件可能包含蓄意植入的恶意软件、连接到可疑域名、暴露凭据,或符合高风险行为模式。每个类别都需要不同的响应措施,也对应不同程度的确定性。
安全厂商有动机将模糊行为描述为紧急问题,客户同样有动机以保守方式界定不确定活动。独立案例研究将有助于区分常见配置错误与主动入侵。
隐私与劳动问题同样值得重视。监控提示词、命令、进程和历史活动,可能暴露敏感的工作模式;当员工混用个人和企业环境时,也可能捕获个人信息。
组织需要为收集与审查设定清晰边界,应明确哪些信号在本地处理、哪些会发送至中央服务,以及谁可以查看它们。员工告知义务和区域性隐私法规也同样重要。
AI 安全层本身可能成为高价值攻击目标。一个能够观察提示词、权限、工具和用户行为的系统,可能存有对攻击者有用的信息。Pluto 必须展示强大的隔离、访问控制、日志记录和事件响应实践。
该公司的纠正技术也带来另一项不确定性。向智能体会话注入指令可能改变行为,但模型响应具有概率性。控制机制不能完全依赖模型自愿遵循新指令。
对于高影响操作,确定性执行仍然不可或缺。无论智能体接下来生成什么内容,策略引擎都可以拒绝网络请求、撤销令牌或阻止进程。买方应审视 Pluto 在何处使用模型判断,以及在何处实施可强制执行的技术边界。
集成覆盖范围带来了额外挑战。当 Pluto 能够同时观察终端、浏览器工具、云服务、连接器和智能体时,其价值才会提升。漏掉一条执行路径,就可能导致对事件经过的描述不完整。
该公司还必须跟上快速变化的组件生态系统。新的编程工具、智能体框架、技能和 MCP 服务器不断出现。如果研究和产品团队未能迅速更新,检测目录就可能过时。
这些限制并不意味着 Pluto 的方法缺乏合理性,而是界定了客户应在概念验证期间测试的内容。最有力的评估应涵盖已知安全的工作流、预置风险、意外的智能体行为,以及涉及隐私敏感信息的场景。
买方还应将 Pluto 与已有控制措施进行比较。现有的终端检测、身份治理、安全浏览器、数据泄露防护和云访问系统可能已覆盖部分问题。新平台应减少盲区,而不是再制造一个彼此割裂的控制台。
核心考验在于运营,而非概念。安全团队已经认同,不受控制的 AI 活动会带来风险。Pluto 必须证明,其上下文理解足以显著改善决策,从而值得部署到员工设备和业务系统中。
三个信号将表明 Pluto 的押注能否成立
下一阶段将揭示,具备智能体感知能力的安全方案会成为持久的控制层,还是被更大平台吸收的一项功能。
第一个信号是得到独立记录的客户表现。Pluto 需要让客户说明其发现了哪些危险活动、阻止了哪些操作,以及产生了多少误报。具名案例研究的说服力将强于汇总性主张。
来自受监管行业的证据将尤其有价值。医疗保健、金融服务和法律机构需要在严格要求下处理敏感数据。在这些领域的成功部署,将证明 Pluto 能够平衡观察、隐私与执行。
第二个信号是产品在快速变化的 AI 环境中的覆盖能力。Pluto 必须证明,它能追踪从终端经由连接器进入业务应用的活动;同时也需要快速支持新发布的工具与组件类型。
不断扩大的 Plutonium 目录有助于衡量研究广度。更重要的信号包括对新发现威胁的响应时间,以及组件评估的准确性。公开的技术分析文章将使这些能力更易于评估。
第三个信号是成熟安全厂商如何应对。终端、身份、浏览器、云和数据安全提供商已经占据智能体运行所在的系统。如果它们发布可比的运行时控制能力,Pluto 就需要在上下文、准确性或部署速度方面展现明确优势。
竞争对手的融资同样重要,因为它能支持更快的产品开发。Reco 最近的融资和更早前 WitnessAI 的融资表明,Pluto 面临资金充裕的对手。更广泛的初创公司竞赛将迫使每家厂商明确自身控制的是哪一层。
整合也是另一种可能结果。大型平台可能通过收购专业厂商来补充 AI 发现或智能体执行能力。如果这能减少集成工作与告警疲劳,客户可能更倾向于统一控制平面。
Pluto 的早期势头赋予其可信的位置。报道称其拥有超过 30 家企业客户和数百万美元的经常性收入,这表明安全负责人正在配置相关预算。该公司的免费研究平台也可能提升其在从业者群体中的知名度。
然而,市场的胜负并不取决于谁把风险描述得最惊心动魄,而取决于哪些产品能够识别真实活动、防止造成严重后果的错误,并保住推动 AI 被采用的生产力优势。
知识工作者同样关乎这一结果。设计不佳的管控措施,可能让每一次 AI 操作都变成一次审批申请;而设计得当的管控,则能让员工在清晰的技术边界内构建实用工作流。
正在试验 AI 的团队应记录所使用的工具、这些工具能够访问的数据,以及哪些操作需要人工审批。可搜索的 AI 知识库 能够帮助维护这类记录,但它不能替代访问控制或安全审查。
Pluto Security 的融资为受监管的 AI 采用带来了一项重要考验:企业能否让员工创建软件,同时仍对数据、权限和智能体操作保持有意义的控制?接下来的客户证据、产品集成以及现有厂商的回应,应会给出答案。
对于安全负责人而言,眼下的行动很直接:在讨论应由哪个平台治理之前,先梳理员工自行构建的 AI。了解谁在创建这些工具、它们能够接触哪些系统,以及当智能体超出其任务范围时会发生什么。随后,测试 Pluto 或其他企业 AI 安全厂商能否在不妨碍安全工作的前提下发现这些路径。及早回答这些问题的公司,将更清楚地了解自身面临的风险敞口;而那些等到明显事故发生后才行动的公司,只能去重建一个自己从未意识到其存在的 AI 环境。



