Micha Rave，Hush Security 首席执行官兼联合创始人 – 访谈系列

Micha Rave，Hush Security 的首席执行官兼联合创始人，是一位经验丰富的网络安全与技术高管，职业生涯涵盖软件工程、产品管理、企业网络、云安全和身份管理。在 2024 年共同创立 Hush Security 之前，他在 Proofpoint 工作超过五年，担任云安全产品管理高级总监，负责 Zero Trust Network Access (ZTNA) 和 Secure Web Gateway (SWG) 产品线。此前，他曾在 Meta Networks 担任产品管理副总裁，专注于企业网络和安全，并在 HARMAN International、Redbend、SanDisk、Hola、Jungo 和 Elbit Systems 担任产品及工程领导职务。他的背景融合了动手的软件开发经验和二十余年构建及商业化安全、网络、虚拟化和嵌入式技术产品的经历。

Hush Security是一家专注于通过将长期凭证和静态密钥替换为基于身份、受策略控制的访问来保护 AI 代理及其他非人类身份的网络安全公司。其平台能够发现 AI 代理，包括影子代理和内部开发的代理，为其分配可验证的身份，并使用范围化、即时授权的权限、集中式策略以及可审计的活动记录来管理它们与企业系统的交互。公司由 Meta Networks 背后的安全资深团队创立，Meta Networks 于 2019 年被 Proofpoint 收购。2026 年 7 月，Hush 完成了 3000 万美元的 A 轮融资，Akamai Technologies 作为战略投资者加入， alongside Battery Ventures 和 YL Ventures，使公司累计融资达到 4100 万美元，并在扩展其治理企业 AI 代理和非人类基础设施的技术。

在创立 Hush Security 之前，您多年致力于构建和领导安全产品，包括 Proofpoint 的云安全。您在市场上看到什么需求促使您创办 Hush？随着代理式 AI 的快速崛起，最初的理念又有何演变？

在 Proofpoint，我们看到企业解决了人类身份问题，却仍让所有非人类身份依赖静态密钥。服务账号、工作负载、流水线，都使用无人拥有、永不过期的密钥进行身份验证。行业的回应是更好的保险库。这是更好的保险箱，而不是根本解决方案。

创立的核心理念是将非人类访问从密钥转向身份。可验证的工作负载身份、即时签发的短期凭证、内联策略强制执行。无需代码重写。

代理式 AI 让这一需求变得紧迫。代理是一种非人类身份（NHI），在运行时自行推理并决定调用哪些工具。若给它一个静态密钥，就等于让自主软件对生产环境拥有永久访问权，而代理往往在任何变更流程之外部署：开发者在周二接线 MCP 服务器，到了周五就已经在触及客户数据。

理念本身没有改变，范围却扩展了。基于身份的访问是工作负载的正确答案。对于代理来说，它是唯一可行的方案：了解所有存在的代理，默认赋予每个代理最小的权限，并审计每一次操作。人类拥有身份提供者（IdP），代理也需要同样的身份提供者，这正是 Hush 所提供的。

Hush 主张企业 AI 代理应拥有自己的身份和委派权限，而不是简单继承使用它们的人类的访问权。传统的身份与访问管理（IAM）系统为何难以应对自主代理？需要做哪些改变？

最显而易见的情况是代理代表用户行动。更棘手的情况是完全没有用户的代理：计划任务、自治的 SOC 响应器、能够自行推理并执行的流水线。没有人可以进行委派，团队只能回退到唯一可用的工具——拥有广泛权限且永不过期的静态服务账号。这正是十年来一直在破裂的共享密钥模型，如今被用于即兴发挥的软件上。

另一端的系统让问题更糟。大多数内部 API、数据库和 MCP 服务器并未进行真正的授权检查，它们只验证你是否持有有效令牌，而不判断你能用该令牌做什么。拥有即等于拥有权限。

需要改变的地方：每个代理都应拥有自己的身份，使用加密方式颁发，无论背后是否有人类。访问应按动作授予，短期且有范围，策略在内联层面强制执行，而不是信任目标系统。当存在用户时，代理的权限是用户权限与该代理在特定任务中被允许的权限的交集；当不存在用户时，代理自身的身份和策略即为全部说明。人类实现了最小特权，代理则需要最小代理权。

您在讨论 AI 安全时使用了“最小代理权”概念。它与传统的最小特权原则有何区别，组织应如何准确确定 AI 代理在特定任务中应被允许的操作范围？

代理的行为并非固定。若给它 CRM 的读取权限和邮件的写入权限，你并不是授予了两项权限，而是授予了它们之间的所有可能路径。最小特权限制了代理可以触及的范围，却未规定它应如何使用这些权限。

最小代理性添加了缺失的维度：哪些操作、针对哪个任务、在何时。一个处理工单的代理需要读取并发表评论。它不需要关闭、删除或触及计费，即使令牌允许也如此。当任务结束时，访问也随之结束。

决定允许什么首先要观察，而不是猜测。运行代理，观察它实际调用了哪些内容，并以此确定基准线。随后使用三个输入进行收紧：它存在的任务、它代表的用户（永远不超过用户本身的权限），以及每个操作的影响范围，因为发布评论和发起付款不应共享同一审批路径。

最小特权决定谁拥有钥匙。最小代理性决定他们进入后能做什么。

我们常常把身份“借给”代理，但我们不希望代理拥有与我们相同的权限——这正是最小代理性的定义。

Hush 最近完成了 $30 百万 A轮 融资，使总融资额达到 $41 百万，Akamai 作为战略投资者加入，与 Battery Ventures 和 YL Ventures 并列。Akamai 的参与除了资本之外还能带来什么？您预计这次合作将如何影响 Hush 在企业 AI 代理安全领域的扩展？

Akamai 位于全球大多数企业的流量路径中，这正是代理安全必须存在的地方。你不能事后在仪表板上管理代理。必须在代理调用工具或 API 的瞬间进行内联治理。Akamai 的业务正是基于这种模式构建的。

除资本之外，他们还带来了三件事：向已经在询问如何控制代理和 MCP 流量的 CISO 进行分发；验证代理身份是一个真实的类别，而非仅仅是一个功能；以及在全球规模上保障机器对机器流量的数十年经验，这正是代理对工具流量即将成为的方向。

模型上下文协议（MCP）正迅速成为连接 AI 代理与工具及企业数据的重要层。站在安全角度，MCP 引入了哪些新风险，组织应如何考虑代理、MCP 服务器与底层资源之间的身份与授权？

MCP 让将代理连接到工具变得极其简单。这正是风险所在。开发者只需在配置文件中添加一个服务器，模型便可以读取 Jira、查询数据库或发送电子邮件。没有审查、没有清单、没有策略。安全问题往往在出现故障时才被发现。

现在出现了三个新问题：

1. 影子 MCP——没有人知道有多少服务器在运行或它们触及了哪些资源。
2. 凭证蔓延——大多数服务器使用静态令牌进行身份验证，该令牌授予全部权限，因此代理获得令牌能够执行的所有操作。
3. 链路塌陷——资源只能看到 MCP 服务器的凭证，无法辨别是哪位代理、代表哪个用户发起的调用。身份必须位于每次交互的底层，访问应是短暂的、受限的，并基于代理和用户的权限。

Hush 最初的构想是，静态密钥和长期凭证是机器访问的破碎基石。由于大多数企业基础设施仍严重依赖 API 密钥、令牌和其他密钥，公司如何在不重建整个技术栈的前提下，切实转向基于身份、短期访问的模式？

你不需要重建。那些声称相反的人从未真正面对过企业。我们保护的大多数内容早于“非人身份”这一说法，而且不会被重写。

因此我们并不要求重建。Hush 可以在不更改代码的情况下部署，并位于访问路径中。第一步是发现：每个密钥、使用者、其触及范围以及运行时的实际行为。大多数公司从未见过这样的全景。

随后这是一段旅程，而非一次迁移。发现过程会显示哪些密钥已失效、权限过宽或风险最高。先解决这些问题。然后逐个系统将静态密钥替换为短期、由身份签发的凭证。应用仍认为自己在使用密钥，但该密钥不再是长期的，策略转移到我们这里。

同一模型既适用于已有十五年历史的 Java 服务，也适用于上周新建的 MCP 服务器。先从风险最高的地方入手，验证后持续推进。

AI 代理将越来越多地代表人类工作，并在许多情况下将任务委派给其他代理。随着这些多代理工作流变得愈加复杂，如何保持每一次操作的身份、授权、所有权和问责链条清晰？

失效模式：用户向编排器发出请求，编排器委派给第二个代理，该代理通过 MCP 服务器调用工具，工具使用服务账号访问数据库。经过四次跳转后，日志只显示一个有效令牌。谁发起请求、谁作出决定、谁负责已经不复存在。

解决方案是拒绝在任何跳转点让身份塌陷。每个代理都有自己的加密身份。当它进行委派时，不会交出自己的令牌，而是发放受限的委派：此子代理、此任务、这些操作，代表该用户。每一次跳转都携带完整链路及其相应权限。

问责来源于在操作点进行内联强制执行和日志记录。网关记录了它被允许执行的操作、它调用的内容以及背后的链路。

多代理系统将变得更难以推理。每个操作的所有权链并非必须如此。

提示注入和其他攻击可能会操纵本来合法的 AI 代理，使其执行运营者从未意图的操作。基于身份的访问控制在多大程度上能够限制被破坏或被操纵的代理造成的损害，即使底层 AI 模型行为异常？

你无法在模型层面阻止提示注入。模型本身设计上会读取不可信的内容。假设代理最终会被诱导去做错误的事。关键在于它在这种情况下能够执行什么操作。

基于身份的访问限制了影响范围。被操纵且权限最小的代理只能滥用其在该任务中被授予的操作。如果它只能读取工单并发布评论，则任何注入都不会导致它导出客户数据库。令牌本身没有这种权限。

用户归属保持链路完整：每次调用都记录是哪位用户、哪个代理、执行了什么任务。代理永远不会超出用户的权限，所有操作都可追溯。

异常检测能够捕获政策允许但意图未遂的情况。即使每次调用都已授权，若一个通常只读取五条记录的代理突然提取五千条，也显得格格不入。由于网关内联运行并了解基线，它可以实时标记或阻止此类行为。

模型有时会出错。范围化的身份、归属以及行为基线使错误仍能被容忍。

Hush 主要致力于 AI 安全，但贵公司内部是如何使用 AI 的？在发现非人类身份、分析访问模式、优先级风险或执行策略等方面，AI 是否能够实质性提升安全平台？

只要它能发挥价值，我们就会使用它。

在产品中，难点不在于发现机密，而在于理解机密。密钥会出现在流量中。工作负载身份、供应商集成、开发测试令牌、失效凭证？大型语言模型读取运行时上下文和所有者信号，并给出带有置信度分数的答案。它用通俗的人类语言概括身份实际执行的操作，从而使策略能够被人类批准。它依据真实的影响范围和冲击半径对风险进行排序，而非静态的严重程度。执行保持确定性。AI 帮助编写策略——但在运行时并不拥有投票权。

在 Hush 内部，代理式编程改变了我们的节奏。原本需要一个冲刺才能完成的功能现在需要数天，我们以 Series A 团队难以负担的速度交付集成。大型语言模型对支持工单进行分流、聚类根本原因，并将客户需求呈现用于路线图讨论。我们自研的 MCP 网关位于所有这些之前，帮助客户理解并使用 NHI 与代理风险。

Hush 表示，多家《财富》500 强公司已在使用其技术，而 Kyndryl 已在内部部署 Hush 并开始向企业客户转售。您从这些大规模部署中了解到，当 AI 代理从实验阶段进入生产阶段时，公司在实际治理中会遇到哪些问题？

没人清楚自己拥有多少。每个大型部署的起点相同：安全团队认为生产环境中只有十几名代理，实际发现却有数百个，已经在触及客户数据。治理问题的核心不是策略，而是先进行资产清点。

凭证比代理本身更糟。几乎所有生产代理都运行在早于它们创建的静态服务账户上，这些账户的权限是多年累积、用于其他用途的，未进行范围化授权。

缺乏所有权。询问谁对某个代理或 NHI 负责，得到的最多是一个团队名称、已离职的承包商，或是沉默。

而且采购方变了。这原本是平台团队的问题。现在由于董事会的要求，CISO 接管了它。这使我们从试点转向企业级推广，也正是 Kyndryl 先内部部署再转售的原因。

代理并未产生新的治理问题。它们把企业十年来对服务账户忽视的旧问题放大，导致情况更加糟糕。

感谢精彩的访谈，想了解更多的读者请访问 Hush Security。