AI Agents 在需要网关之前，先需要身份

Hush Security 凭借一项鲜明主张登上 Google News：企业应先识别每个 AI agent，再为其流量部署网关。这一分歧很重要，因为许多 agent 仍在借用人类权限或共享凭证。网关可以检查连接，但当每个调用方看起来都相同时，它无法建立责任归属。

这一观点紧随 Hush Security 在 2026 年 7 月宣布融资并扩展其非人类身份平台之后。该公司筹集了 3,000 万美元，并推出 Identity Gateway，旨在发现 agent、分配身份、协调有限访问权限并记录其操作。其核心理念很简单：在知道哪个 agent 正在行动之前，安全控制无法可靠地治理它。

这一立场挑战了正在企业 AI 领域兴起的网关优先方法。Cisco、Palo Alto Networks、Microsoft 及其他安全厂商如今都在 agent 与工具之间部署控制措施。然而，网关看到的是请求，未必能看到请求背后完整的身份、所有者、委托权限或执行历史。结果是一个熟悉的安全边界，却面临陌生的归因问题。

这并不是在讨论网关是否重要。它们仍是用于身份验证、策略检查、流量检测和工具限制的有用执行点。问题在于，企业是否在为每个通过检查点的主体发放独立凭证之前，就先安装了检查点。

Google News 标题指向更大的身份转变

Hush Security 正在将 AI agent 安全重新定义为仅靠网关无法解决的身份问题。

该公司于 2025 年结束隐身模式，重点聚焦非人类身份。这包括服务账户、API 密钥、访问令牌及其他由软件而非员工使用的凭证。Hush 最初解决的是一个长期存在的企业问题：组织往往积累了难以盘点、轮换和撤销的机器凭证。

自主 agent 提高了风险等级。它们可以理解指令、选择工具、检索数据，并在一次任务中跨多个系统采取行动。传统自动化遵循预先确定的步骤。agent 在接收新信息后可以改变路径，因此其实际权限更难预测。

在 7 月 30 日的报道中，VentureBeat 介绍了 Hush 如何将早期工作扩展至 agent 身份网关。该平台位于 agent 与企业资源之间。Hush 表示，它可以发现 agent、将其关联至人类所有者、授予特定任务访问权限、记录活动，并集中撤销某个 agent。

Hush 将其访问模型称为“最小代理权限”（“least agency”）。这一术语借鉴了最小权限安全原则，即仅向用户或工作负载授予完成任务所需的访问权限。最小代理权限将 agent 的目标、执行上下文和委托权限也纳入决策。

设想一个被要求诊断生产环境错误的编程 agent。它可能需要日志、源代码和部署元数据的读取权限。但它不应自动获得修改账单记录、下载客户数据库或重写自身安全策略的权限。

同样的区分也适用于生产力 agent。准备会议简报的助手可能会搜索日历、笔记和获准文件。它不需要不受限制地访问启动它的员工可用的所有邮箱、云盘或管理控制台。

网关可以阻止被禁止的目的地或格式错误的请求。然而，当多个 agent 使用同一个 OAuth 令牌或服务账户时，其策略会变得粗糙。它或许知道某个获批准的凭证请求了一个文件，却未必知道是哪个 agent 发起请求、其行动原因，或该行动是否仍在原始委托范围内。

这正是 Google News 标题比一般融资新闻更具分量的原因。Hush 不只是增加了另一层检测机制。它主张，身份必须成为记录 agent 所有者、用途、权限、会话和操作的组织性基础。

这一模型也改变了事件响应方式。安全团队通常会以“谁访问了资源”作为调查起点。共享凭证可能将答案缩小为某个应用、员工或服务账户。独立的 agent 身份则提供了更精确的起点，尤其是在多个自主流程都在同一个人的权限下运行时。

共享凭证让网关只能猜测

网关对策略的执行精度，取决于附加到每个请求上的身份和上下文精度。

许多早期企业 agent 的部署方式与脚本类似。开发者存储一个 API 密钥、分配一个服务账户，或直接传递人类用户的 OAuth 令牌。这种方法能让原型快速运行，但也将多个参与方合并为一个安全身份。

员工、agent 宿主、模型、单个 agent 和工具会话，都可能使用同一授权身份出现。如果 agent 创建子 agent，链路就更难重建。下游服务可能收到一个有效令牌，却不知道是哪个组件发起了操作。

VentureBeat 在 2026 年 6 月对 107 名企业受访者进行的调查发现，69% 的受访者在 agent 部署中使用共享 API 密钥。其 agent 安全研究还发现，82% 的受访者主要依赖模型提供商或超大规模云服务商提供的控制措施。

这些控制措施提供了有用保护。提示词过滤器可以检测已知的注入模式，数据丢失防护系统可以标记敏感内容，云策略可以限制对托管资源的访问。但这些功能都不会自动为每个 agent 实例创建独立身份。

该调查显示，Microsoft Entra Agent ID 在受访者中的采用率为 13%。其他专门面向身份的产品采用率仅为个位数。这一差距表明，企业部署通用 AI 防护措施的速度快于 agent 专属的责任追溯机制。

当 agent 获得过多权限时，这种失衡会变得更加严重。共享管理员凭证并不会因为有网关监控就变得安全。如果策略允许该凭证执行某项操作，网关可能会批准一个在技术上有效但危险的请求。

提示词注入正说明了这一问题。agent 可能读取不可信文本，而文本指示其检索机密材料或更改配置。该指令可以通过文档、网站、电子邮件、工具响应或数据库记录进入。语言过滤器随后面临艰难任务：区分合法意图与被操纵的意图。

身份控制针对的是不同层面。它们不需要判断每一句话是否恶意。无论模型作出什么决定，它们都可以限制 agent 可获得的最大权限。

例如，只有只读权限的研究 agent 在遇到恶意指令后无法删除源代码仓库。临时支持 agent 在其工单关闭后无法继续保留客户数据访问权限。获授权起草付款的财务 agent 也不能同时批准该付款，除非策略授予其两项操作权限。

短期凭证可进一步降低暴露风险。身份系统不必将可重复使用的密钥放进 agent 环境，而是可以为一次任务、一个资源和一个时间窗口签发令牌。令牌会自动过期，也可在会话结束时撤销。

该模型也有助于生成更完善的日志。审计记录应识别 agent、其人类发起人、任务、策略决定、所用凭证及最终操作。仅记录网关请求，会让调查人员在事件发生后不得不进行过多推断。

企业在管理重要的人类活动时已经会保留上下文。它们会记录用户、设备、应用、会话、身份验证方法和资源。自主软件至少也需要同等程度的细节，因为它可以在无需停下来接受人工审查的情况下执行许多操作。

挑战在于数量。一个组织创建、复制或终止 agent 的速度可能快于招聘员工。身份配置因此必须自动化。手动注册会造成延迟、鼓励绕过流程，并让影子 agent 游离于治理之外。

这种压力使生命周期管理变得必不可少。每个 agent 身份都需要创建事件、所有者、获批准用途、策略集、到期规则和撤销路径。如果任何一项未定义，网关接收到的流量就来自一个组织无法完整解释的行为主体。

网关控制流量，身份确立权限

最强的架构将身份视为权限来源，而将网关视为执行该权限的一个场所。

AI 网关通常调解模型、agent、工具和数据服务之间的通信。它可以验证连接、检查请求、应用速率限制、过滤内容并生成日志。MCP 网关为 Model Context Protocol 连接执行类似工作。

MCP 是一种开放协议，使 AI 应用能够通过通用接口发现并调用外部工具。它减少了对自定义集成代码的需求，但标准化连接也可能扩大 agent 可触及的范围。

网关之所以有用，是因为它提供了一个集中式策略检查点。安全团队可以在许多工具前部署规则，而不必修改每个后端。这种架构便利性并不能回答 agent 是谁，或其权限从何而来。

身份提供了这一基础。独立身份可以将 agent 绑定到其代码、宿主、所有者、任务和获批准能力。授权机制随后便可决定该身份在当前条件下可以做什么。

这种区别类似机场检查点。对每位旅客进行安检很有价值，但该过程依赖于知道是哪位旅客出示了每份证件。只检查行李而不确认身份，会产生一份不完整的安全记录。

美国国家标准与技术研究院在 2026 年将相同组成部分纳入更广泛的框架。其 agent 身份项目将 agent 识别、授权、委托、日志记录、透明度和数据来源列为相互关联的工作领域。

NIST 还指向既有技术，而非提出单一专有方案。OAuth 可以承载委托授权，OpenID Connect 可以表达身份验证信息，SCIM 可以支持身份配置。SPIFFE 和 SPIRE 可以向软件工作负载签发可通过加密验证的身份。

这些技术分别解决问题的不同部分。OAuth 说明令牌所承载的访问权限。OpenID Connect 有助于描述已通过身份验证的主体。SCIM 可以创建或停用身份记录。SPIFFE 可以证明，在受控基础设施中运行的工作负载确实是其所声称的工作负载。

它们都无法独立捕捉自主 agent 的完整生命周期。企业仍需要将工作负载身份与人类委托、策略、任务范围和操作历史关联起来。

这种缺失的连接解释了：仅仅给一个智能体赋予名称为何远远不够。请求中的自我声明标识符可以被更改或复制。可信身份必须由接收服务所接受的系统签发或验证。

身份还必须能够跨基础设施迁移。智能体可以运行在桌面应用、云容器、开发者环境、托管平台和第三方服务中。仅扎根于某个集群的凭证，在智能体跨越组织边界时可能失去意义。

OpenID Foundation 关于智能体身份管理的一篇论文描述了这一可移植性挑战。论文指出，MCP 客户端标识符未必是可靠的工作负载或智能体身份；同时也说明，当智能体跨越信任域时，基于基础设施的证明会变得更加困难。

这一问题将身份验证与代理权区分开来。身份验证确认某个软件组件控制着一项凭证。代理权则说明该组件为何行动、代表谁行动，以及它当前拥有何种委托权限。

网关需要同时掌握这两类信息。它应拒绝未经验证的调用方，也应拒绝超出受委托任务范围的已验证智能体。通过身份验证不能等同于获得执行发起用户所有可用操作的权限。

Hush 的方法是在访问资源之前部署由策略驱动的身份代理。网关随即成为这一代理授权的执行机制。与先从流量中识别身份的网关相比，这一顺序能够支持更严格的权限划分和更清晰的归因。

该架构仍依赖集成。应用程序和工具服务器必须遵守所接收的身份声明、范围或能力令牌。如果下游系统将每个请求都归并至同一个高权限后端账户，身份记录就会失去执行价值。

安全厂商正向同一个控制点汇聚

市场正转向智能体身份，但不同厂商对于应由身份、网络流量还是端点行为主导执行存在分歧。

Hush 并非唯一将智能体视为新型非人类参与者的公司。Microsoft、Cisco、Palo Alto Networks、1Password、Okta、Ping Identity 和多家初创企业都已推出面向智能体的身份或治理功能。

Cisco 的 Duo Agentic Identity 将智能体注册为与人类所有者关联的独立对象。其更广泛的安全架构能够通过 MCP 网关路由工具调用。Palo Alto Networks 则在 Prisma AIRS 中展示了智能体注册表、面向智能体的身份提供商以及网关控制机制。

Microsoft 将智能体治理分布在 Entra、Purview、Defender 和 Sentinel 中。Entra Agent ID 专注于创建和治理智能体身份。Microsoft 的其他服务则处理数据控制、威胁检测和监控。

CrowdStrike 强调端点活动。这种方法跟踪软件进程在设备上的实际行为，而非仅依赖模型表达的意图。它可在身份验证成功后帮助检测文件变更、进程启动及其他具体操作。

这些不同路径彼此互补，但也在竞争成为主要控制平面。身份厂商认为，每项操作都应始于可信主体和受限授权。网络厂商将网关视为核心检查点。端点厂商则聚焦可观测的执行行为。

RSAC 2026 展现出这些类别正在快速汇聚。VentureBeat 对智能体安全框架的评述发现，主要厂商已推出注册表、网关、身份对象和运行时监控。

尚存的缺口揭示了为何单一控制手段并不足够。一个智能体可能通过所有凭证检查，却仍修改约束其自身行为的策略。网关可能看见每一次工具调用，却无法重建委托链。端点传感器可能观察到某项操作，却不知道该智能体是否拥有有效的业务授权。

多智能体委托构成了最困难的情形。假设一名采购智能体要求一名研究智能体比较供应商。研究智能体随后创建一个浏览智能体，由其向第三方服务请求文档。

每次交接都应缩小或保持授权范围，绝不能悄然扩大。最终服务需要拥有足够证据，以判断谁发起了任务、哪些智能体参与其中，以及请求的操作是否符合原始目的。

传统的用户模拟在此表现不佳。如果每个子智能体都继承员工身份，下游系统就无法区分原始用户与自主代理。撤销一个已受损子智能体，可能需要终止整个用户会话。

更好的模型是赋予每个智能体独立身份，同时保留签名委托链。子智能体仅获得完成其任务所需的权限子集。日志保留人类所有者、父智能体、子智能体与最终操作之间的关系。

这种结构类似于安全云工作负载交换短期凭证的方式。然而，智能体带来了不确定的行为和自然语言目标。策略必须同时考虑技术身份和不断变化的任务上下文。

此外还存在实际的集成问题。企业已经在运行身份提供商、特权访问系统、API 网关、服务网格、端点代理和安全监控平台。增加单独的智能体身份层，可能会产生又一个控制台和事实来源。

胜出的方案需要与现有身份基础设施连接。安全团队会抵制那些要求每个应用都采用专有协议或维护重复员工目录的系统。

这种压力有利于基于标准的声明、短期令牌和可移植的审计记录。它也有利于能在影子智能体申请正式登记前发现它们的产品。

发现能力很重要，因为员工可以在未经安全团队批准的情况下安装编程助手或连接本地智能体。对于组织根本不知道存在的智能体，再完美的身份策略也无能为力。网络、端点、云和身份遥测都能帮助发现这类部署。

因此，市场的汇聚支持 Hush 的前提，但并不能验证其每一项产品声明。身份正变得不可或缺，但它将与网关、沙箱、端点监控和数据控制并行运作。真正的竞争在于哪一层定义权威记录。

身份并不能让智能体变得安全

经过验证的身份能够提升控制力和可追责性，但无法证明智能体的行为值得信赖。

这一限制是对“身份优先”叙事最有力的挑战。已认证的智能体仍可能作出糟糕决策、遵循恶意指令、暴露数据或调用不安全工具。身份能告诉防御者是谁采取了行动，却不能保证该行动合理。

传统安全提供了警示。合法账户造成了许多破坏性事件，原因包括攻击者窃取凭证、员工获得过多访问权限，或获批软件出现意外行为。有效身份只是策略决策的起点。

智能体系统增加了不确定性，因为其计划可能在执行期间发生变化。模型在读取新信息后可能选择不同工具，也可能误解约束条件，或将不可信内容视为指令。

这正是沙箱仍然重要的原因。沙箱隔离执行环境，使受损或出错的智能体无法随意影响主机系统。身份可以限制允许访问的资源，而隔离则从技术上约束进程能够触及的范围。

提示词和输出控制同样仍有作用。在请求抵达另一系统之前，它们可以捕捉已知攻击模式、敏感数据或被禁止的内容。其弱点在于将语义解释视为唯一防线。

完整的架构需要纵深防御。身份层确立行为主体及其受委托权限。网关执行连接策略。沙箱限制执行。端点和云监控记录实际行为。数据控制限制敏感信息。

策略引擎必须始终处于智能体控制之外。如果智能体能够编辑定义自身权限的规则，那么有效身份或许能帮助调查人员追溯损害归因，却无法阻止损害发生。

凭证保护也带来另一项风险。为每个智能体提供独立的长期密钥会改善归因，但也会增加攻击者可窃取的密钥数量。身份系统应签发短期凭证，并将可复用密钥置于智能体环境之外。

组织还必须避免永久性的智能体泛滥。自动创建身份固然有用，但非活跃身份需要自动过期。否则，企业只会用未受管理的智能体账户替换未受管理的 API 密钥。

人类所有权同样可能产生误导。将智能体映射到某名员工，并不意味着该员工审核了每一项操作。问责记录应区分发起支持、审批、运行和执行。

管理者可能批准某项工作流，开发者部署智能体，而另一名员工启动任务。将这三种角色压缩为一个“所有者”字段，可能制造虚假的确定性。

数据来源也需要同样谨慎。智能体可能组合文档、生成文本、工具响应和记忆上下文。安全日志应保留哪些信息影响了重要操作，同时避免收集超过必要范围的敏感内容。

对于知识工作者而言，这一问题超越了网络安全。智能体正越来越多地处理个人笔记、项目文档、转录内容和既往决策。组织良好的个人知识库可以改善上下文，但访问仍需要明确边界。

准备每周更新的智能体可能需要选定的项目记录。它不应仅因所有信息都属于同一用户，就继承对每一条私人笔记的不受限访问权限。身份和任务范围有助于将有用上下文与不必要暴露区分开来。

因此，Hush 的声明需要在生产环境中得到独立验证。采购方应询问：其系统是否以密码学方式识别智能体实例、是否与现有身份提供商集成，以及是否将身份传播至下游工具。

他们还应测试撤销速度、策略故障时的行为、委托追踪和日志完整性。若某个控制平面在工具调用期间丢失上下文，或在故障期间默认授予广泛访问权限，便可能重现它所承诺降低的风险。

该公司的融资和产品发布表明的是市场意图，而非已衡量的安全结果。公开证据尚未显示，该平台在每一种桌面、云和托管智能体环境中的表现。

这种不确定性并不会否定身份优先架构。它界定了评估产品时应采用的标准。有用的问题不在于仪表板是否列出了某个智能体，而在于身份是否能够持续限制、归因并终止该智能体的授权。

Google News 读者接下来应关注什么

三个信号将表明智能体身份会成为真正的基础设施，还是停留在安全营销类别。

第一个信号是生产环境中独立身份的采用。安全团队不应只关注被发现或登记的智能体数量。真正有意义的衡量指标是：有多少活跃智能体不再使用共享凭证或不受限制的人类令牌。

变革的证据将包括短期凭证、任务范围内的访问权限、自动到期机制，以及保留下游服务中代理标识符的能力。如果共享密钥依然普遍存在，单靠部署网关无法弥合问责缺口。

当企业报告共享服务账户减少、可撤销的代理会话增多时，这一信号将强化“身份优先”的论点。如果身份产品仍局限于资产清单仪表盘，而运行时访问方式没有变化，这一论点则会被削弱。

第二个信号是对委派链的支持。企业代理将越来越多地创建子任务、调用专业代理，并跨越组织边界。产品必须在这些交接过程中保留权限关系。

可信的实现方案应能展示最初的人类授权者、每个参与的代理、所转移的权限以及最终执行的操作。每个子身份获得的权限，不应超过其父级身份可委派的范围。

关注标准组织和供应商是否提供可互操作的方式来表达这些关系。专有的委派记录或许能在单一平台内运作，但企业会使用来自多个提供商的代理。跨平台验证将决定身份能否在供应商环境之外保持完整。

如果 MCP 工具、代理平台和身份提供商能够交换可验证的委派证据，这一信号将强化该论点。如果每个平台在边界处都把代理重新转换为普通用户令牌，则会削弱这一论点。

第三个信号是事件遏制能力。当代理行为失当或遭到入侵时，身份的重要性最为凸显。供应商需要证明，防御团队能够隔离单个代理，而无需禁用员工、应用程序或整个工作流。

有价值的测试包括立即撤销权限、拒绝现有会话、阻断子代理，以及重建操作链。组织还应验证：当身份基础设施不可用时，策略执行是否能够安全地失效。

安全团队应比较身份系统、网关、终端和下游应用程序中的日志。如果这些记录无法关联，企业仍然缺少一份可靠、统一的事件说明。

成功将通过证明代理身份能够改变结果而不仅仅是提升可见性，来强化 Hush 的立场。反复发生涉及已认证但未被遏制代理的事件，则表明市场高估了身份作为独立防御措施的作用。

Google News 的表述在顺序上大体正确。企业应先明确代理是谁、它承载的是谁的授权，以及该授权持续多久，再将网关视为充分的治理手段。

下一步应落到实践：从创建到最后一次工具调用，对一个生产环境代理进行审计。你的团队能否识别它的所有者、任务、凭证、权限、子代理、数据访问范围和撤销路径？如果任何答案依赖共享令牌或从流量中推断而来，那么网关的部署就早于身份基础的准备。