CrowdStrike Blueprint Alliance 以厂商协同应对 AI 智能体身份缺口

CrowdStrike 与另外 11 家创始厂商加入了一个新联盟，聚焦企业已无法回避的矛盾：AI 智能体需要广泛访问权限才能发挥作用，但同样的权限也令其难以治理。CrowdStrike Blueprint Alliance 旨在通过共享安全架构弥合这一缺口。

这一联盟正式名称为 Blueprint Alliance，于 2026 年 9 月 22 日成立。成员覆盖身份、云基础设施、网络安全、数据平台、应用开发及企业软件等领域。这种覆盖范围至关重要，因为智能体在完成一项任务时，可能横跨其中多个领域。

这项公告并不只是 CrowdStrike 又一项 AI 智能体安全合作。它要求在企业预算上彼此竞争的厂商支持一套共同的运营模式。该模式将智能体视为可识别的参与者，并赋予其受限权限、可追溯委派、持续监控和可逆遏制能力。

更棘手的问题在于，共享原则能否转化为可互操作的控制措施。企业需要的不只是厂商在术语上的一致，还需要在原本并非作为统一系统设计的产品之间，实现一致的发现、授权、日志记录和关停行为。

CrowdStrike Blueprint Alliance 连接智能体技术栈的 12 个环节

该联盟将 AI 智能体安全从产品级功能，转变为跨厂商架构问题。

12 家创始成员包括 AWS、CrowdStrike、Databricks、Docker、Google Cloud、Lovable、Okta、Proofpoint、Salesforce、ServiceNow、Wiz 和 Zscaler。GE Appliances 和 World Central Kitchen 担任战略顾问。

根据官方联盟公告，成员将共同开发开放的多厂商参考架构。这项工作扩展了 Okta 于 2026 年 3 月首次提出的安全蓝图。

该架构始于四个运营问题：

• 组织内有哪些智能体？

• 每个智能体可以做什么？

• 每个智能体正在做什么？

• 防御团队应如何响应？

这些问题听起来很基础。但多数公司无法在云账户、软件平台、开发环境、数据系统和员工自行安装的工具之间，对它们给出一致答案。

AI 智能体是一种软件，能够理解目标、收集上下文、选择工具，并在有限监督下采取行动。一个客户服务智能体可能会阅读支持工单、查看账户历史、批准退款，并更新 CRM 记录。

每一步都会引入不同的控制点。智能体在认证前需要身份；访问客户记录前需要授权；任务运行期间其行为需要监控；任务结束时必须撤销其访问权限。

创始原则反映了这一顺序。成员表示，每个智能体都应获得一级身份，而不是借用人类凭证。访问权限应限定于某项任务，而非永久授予。当一个智能体调用另一个智能体时，委派关系应保持可追溯。

该联盟还呼吁持续进行运行时监控。运行时监控会观察智能体运行期间的实际行为，而不是仅依赖执行前的批准。如果行为变得不安全，遏制措施应立即且可逆。

CrowdStrike 从企业安全的检测与响应一侧参与这一安排。Okta 提供身份控制，而 AWS 和 Google Cloud 代表基础设施。Salesforce 和 ServiceNow 则运营着智能体可在其中发起业务操作的应用环境。

Databricks 覆盖数据基础设施，而 Docker 和 Lovable 涉及开发与部署工作流。Proofpoint、Wiz 和 Zscaler 则围绕通信、云暴露面和网络访问补充控制能力。

这种角色分工说明，任何单一成员都无法交付完整架构。身份平台可以认证智能体，但无法自动看到所有下游操作。终端或云安全产品可以检测可疑行为，却无法控制上游的每一项权限。

因此，该联盟首先作出了可信的诊断。智能体安全横跨不同团队所有、不同厂商提供的系统。尚未解决的问题是，这些厂商能否足够深入地连接各自的控制措施，从而实现持续治理。

为什么 AI 智能体会将熟悉的访问问题转化为更快速的失效

智能体会放大旧有的身份弱点，因为它们能够复用权限、串联操作，并且运行时间长于一次人工会话。

传统企业自动化早已使用服务账户、API 密钥和工作负载身份。安全团队知道，当所有权不清晰或权限无限期保持有效时，这些凭证会变得多么棘手。

AI 智能体为这一既有问题加入了不确定的决策路径。它们的下一步行动可能取决于模型输出、检索到的内容、工具响应，或由另一个智能体提供的指令。软件可以在不改变既定目标的情况下改变行动路径。

这种灵活性正是智能体价值的来源。也正因如此，广泛且长期有效的访问权限带来了尤为严重的风险。遭入侵或被操纵的智能体可以利用有效权限，却以背离运营者意图的方式行事。

NIST 已将这一身份问题列为优先事项。其智能体标准计划涵盖自主智能体的安全、身份、互操作性及行业主导标准。

该机构将智能体描述为能够在电子邮件、日历、软件开发、购物及其他工作流中自主行动的系统。其效用取决于与外部系统及内部数据的连接。

这些连接带来了多个相互交织的问题。组织能否区分智能体与启动它的员工？能否识别智能体的所有者及软件来源？能否证明某项具体操作依据的是哪一种权限？

凭证共享让这些问题更难回答。员工可能使用个人企业令牌连接助手。下游应用随后看到的是员工身份，即使是智能体选择并执行了该操作。

这种安排削弱了问责性。应用可能记录了一项有效的用户请求，却无法显示是否由人批准了这笔具体交易。安全调查人员得到的是技术上准确、但缺少最重要上下文的日志。

当智能体委派工作时，风险会进一步扩大。主智能体可能调用专业智能体，后者又通过独立服务调用工具。每一次转移都可能模糊原始用户、已批准任务和剩余权限范围。

任务级访问提供了更好的模式。智能体只获得完成一项任务所需的资源和操作权限。当任务完成、发生实质变化或违反既定条件时，该权限即告失效。

不过，当所需路径无法完全预测时，最小权限会变得更难实现。研究智能体可能在开始工作后才发现需要某个数据源。授予所有可能的权限将违背任务范围限定的初衷。

因此，企业需要动态授权。随着工作流变化，策略系统必须评估身份、任务、资源、上下文和所请求的操作。高风险步骤可以要求重新批准，同时不必中断每一个常规操作。

这就是 Blueprint Alliance 在实践层面的推动力。企业希望智能体能跨越碎片化的软件环境采取行动。安全团队则需要这些操作在每次交接中都保持可归责、且受边界约束。

核心取舍在于有用的访问权限与可控的权限范围

只有在不将每个工作流都变成反复人工审批的前提下限制智能体权限，该联盟才能成功。

没有系统访问权限的智能体，不过是一个对话界面。拥有不受限制访问权限的智能体，则可能成为未受监控的管理员。企业部署必须在这两个极端之间运作。

以准备每周销售更新的智能体为例。它可能需要读取 CRM 记录、检索产品数据、分析近期会议、起草建议并发布摘要。该工作流跨越多个系统和业务团队所拥有的信息。

智能体不需要删除客户记录或更改销售区域的权限。它可能需要读取账户详情，却只需临时获得发布一份文档的权限。其权限范围应随任务而定。

身份为这些决策提供锚点。组织需要为智能体、其所有者、其开发者及获批能力建立唯一记录。当智能体委派部分工作时，这一身份也应保持可见。

NIST 的身份指导指出，智能体应拥有唯一标识符、凭证和授权权利。这些属性应始终与运营该智能体的人员或系统保持关联。

现有技术已提供部分基础。OAuth 可以在不共享密码的情况下委派有限访问权限。工作负载身份系统可以认证软件进程。策略引擎则能够依据既定条件评估资源访问。

然而，这些工具不会自动捕捉智能体的意图。有效令牌可以显示软件获准调用某个 API，却无法证明由此产生的操作符合用户批准的任务。

这种区别将身份认证与治理区分开来。身份认证回答的是谁或什么提交了凭证。授权决定该身份可以做什么。治理则将这些权限与所有权、目的、监督和审查联系起来。

运行时行为又增加了一层复杂性。智能体可能一开始符合策略，随后却从文档中检索到恶意指令。当不可信内容通过智能体被要求处理的数据操纵模型时，就会发生间接提示注入。

安全架构必须假定，执行前批准并不足够。监控应将智能体的操作与其声明的任务及允许边界进行比对。防御人员还需要具备暂停或终止执行的能力。

可逆性尤其重要。停止智能体可防止更多操作，但无法撤销已经发送的消息、数据库变更或外部交易。只要底层应用支持，系统就需要具备回滚机制。

有些操作无法逆转。已泄露的秘密无法重新变为私密信息。发送到组织外的付款可能无法立即追回。破坏性命令可能在监控发出警报前就已删除数据。

Blueprint Alliance 无法通过单一控制措施解决这些因应用而异的限制。它可以定义产品如何交换身份、授权、遥测和响应信号。每个平台仍必须执行与相关操作对应的控制。

这就是为什么核心矛盾是一种取舍，而非简单的技术缺口。更广泛的访问权限会提升智能体的能力。更严格的限制能降低暴露风险，却也可能中断工作流并增加审批负担。

最佳结果既不是无限自主，也不是持续的人类确认，而是有条件的自主：低风险操作可继续执行，而敏感步骤则触发更严格的检查。要在 12 家供应商之间实现这种平衡，仅靠原则共识远远不够。

CrowdStrike AI Agent Security 现已覆盖多个联盟

CrowdStrike 正在构建广泛的代理安全布局，但重叠的联盟也可能造成交付成果上的混淆。

Blueprint Alliance 与 CrowdStrike 于 2026 年早些时候加入的 Open Secure AI Alliance 并不相同。两者名称相似，也都聚焦 AI 安全，但其宣称的方法有所不同。

CrowdStrike 在 7 月 27 日称自己是该开放安全联盟的首批合作伙伴。该由 Nvidia 支持的项目强调开放模型、共享研究、安全工具、评估和集体防御。

Blueprint Alliance 则更聚焦于面向企业代理的多供应商架构。其核心主题包括发现、身份、范围受限的访问、可追溯的委派、运行时监控和遏制。

CrowdStrike 还提供自己的代理构建和安全产品。Charlotte AI AgentWorks 允许组织在 Falcon 平台内构建定制安全代理。CrowdStrike 表示，该环境包含治理机制和防护措施。

该公司的 AgentWorks ecosystem 支持来自多家提供商的模型和基础设施。这使 CrowdStrike 对企业代理治理规则拥有直接的商业利益。

同时参与产品、双边合作和联盟，能够增强 CrowdStrike 的影响力。这让该公司得以进入技术讨论的多个层面，从开放安全研究到企业级执行。

但这也可能分散注意力。企业如今面对多个联盟、框架、产品架构和拟议标准。相似的术语并不保证实现兼容。

参考架构记录组件及其关系，但未必提供协议、认证、测试套件或生产集成。买家应区分架构层面的共识与已经验证的互操作性。

如果成员能在其系统之间提供可用的连接，Blueprint Alliance 的广度将成为优势。如果每家供应商只是把这些原则映射到既有产品上，却没有共同的技术行为，它就会成为弱点。

例如，每个成员都可以支持代理发现的理念，却采用不同的标识符和库存格式。每个成员都可以认可遏制，却暴露出彼此不兼容的关闭控制方式。

该组织需要具体定义。什么算是代理？短暂存在的子代理如何注册？哪个系统拥有权威身份？被委派的权限如何跨越云端和应用边界传递？

它还需要一个共同的事件模型。如果一种产品无法理解另一种产品的遥测数据，运行时监控的价值就会降低。当团队必须从互不相关的日志中重建身份和授权链条时，事件响应将变慢。

独立验证同样重要。创始供应商有动力围绕自己的平台塑造新兴市场。它们的参与很有价值，但不能替代客户、研究人员或标准机构的测试。

战略顾问 GE Appliances 和 World Central Kitchen 可以帮助确保这项工作贴近真实运营。制造环境、人道主义物流和企业软件对延迟、自主性和故障有着不同的容忍度。

不过，两家顾问机构无法代表每一种部署模式。金融交易、医疗工作流、软件开发和消费者代理会带来各自的问责要求。该架构必须保持适应性，同时不能变得含糊。

对于企业买家而言，审慎的回应应是保持关注，但不作预设。成员名单表明主要供应商认识到了共同问题，但尚未证明其产品能够作为一个受治理的系统协同运行。

参考架构尚不是可执行的标准

最大的不确定性在于，该联盟是否会发布可测试的接口，而不是一份与供应商立场一致的设计文档。

发布公告确立了原则和联盟结构，但并未确立强制性标准。它也没有说明认证机构或具有约束力的合规流程。

这种差异很重要，因为自愿架构可以改善规划，却未必改变产品行为。一家公司可以声称符合最小权限和持续监控等广泛概念，但实施方式可能各不相同。

该联盟所预测的规模也需要谨慎归因。其公告援引 Gartner 的预测：到 2028 年，全球《财富》500 强企业平均将使用超过 15 万个代理。公告还称，只有 13% 的组织认为自己具备合适的治理能力。

这些数字是通过联盟公告呈现的。即使代理数量快速增长，代理的定义也会显著影响任何总量。持久型助手、短生命周期子代理、自动化流程和工具调用不应被一概而论。

在组织规模接近这一数字之前，发现工作就已变得困难。员工可以在没有中央部署的情况下授权外部助手。开发人员可以在测试期间创建临时代理。SaaS 产品也可能通过常规更新增加嵌入式代理。

因此，资产清单必须结合多种信号。身份系统可以显示凭据和应用授权。云平台可以显示工作负载。安全工具可以观察进程、网络活动和 API 行为。

没有任何单一信号能可靠捕捉所有代理。一个代理可能仅短暂存在、使用共享凭据，或在另一个应用内运行。这正是联盟采用多供应商结构的原因。

然而，互操作性也会带来自身的信任问题。供应商必须决定交换哪些身份数据、授权上下文和行为遥测信息。客户需要控制有多少敏感信息在平台之间流动。

误报带来另一种风险。如果监控错误解读异常操作，自动化遏制可能中断合法工作。遏制不足则会让危险代理保持活跃。该架构需要根据影响和置信度校准响应的方式。

人工控制也需要谨慎设计。要求对每个决定都进行批准，会削弱大部分生产力收益。允许操作人员批准广泛类别，则可能以另一种名称重新建立常驻访问权限。

联盟应定义可衡量的属性。参与产品可以证明其在交接过程中保留委派历史。另一项测试可以验证：在规定时间内，撤销的权限会停止在已连接服务中的访问。

测试套件将使客户能够比较不同实现。共享模式将帮助平台交换库存和活动数据。认证可以表明产品满足基线要求，但不意味着具备完整安全性。

联盟还应记录故障行为。安全架构通常描述预期路径，却较少关注策略服务不可用、遥测延迟或权限部分撤销的情况。

当某项控制无法访问时，代理不应获得更广泛的权限。然而，默认拒绝的响应可能中断关键业务流程。适当的故障模式取决于任务及其后果。

在这些机制出现之前，Blueprint Alliance 仍是一项严肃的提案，而非经验证的安全层。它的价值在于让合适类别的供应商围绕正确的问题达成一致。执行效果将决定这种一致是否能改变风险。

三个信号将显示联盟能否兑现承诺

下一项考验不是另一份成员公告，而是证明该架构可在独立运营的产品之间发挥作用的证据。

第一个信号是公开发布技术规范。联盟应定义代理身份字段、委派记录、授权上下文、遥测格式和响应接口。

详细的规范将增强成员有意构建共享控制机制的可信度。若只是高层框架和针对产品的映射，则会削弱这一点，因为客户仍需要进行定制集成。

第二个信号是可运行的多供应商演示。一个可信示例应能在身份、云、数据、应用和安全系统之间跟踪同一个代理。

该演示应展示任务范围内的权限、委派工作、运行时监控和权限撤销。它还应展示调查人员如何在不安全操作发生后重建整个链条。

这些证据将揭示 CrowdStrike AI agent security 是否能够接收其他联盟成员提供的身份和活动上下文，也将显示这些系统是否能根据 CrowdStrike 的检测结果采取行动。

第三个信号是独立测试。NIST、企业设计合作伙伴、安全研究人员或其他中立组织应评估该架构如何处理凭据共享、间接提示注入、过度权限和被攻陷的代理。

独立结果将增强联盟的安全主张。测试延迟、封闭演示或仅靠自我证明，都会让核心问题悬而未决。

买家无需等到那时才改善自身控制措施。他们可以盘点当前代理、消除共享凭据、明确指定负责人，并缩小持久权限范围。

团队还应记录哪些操作需要人工批准，哪些可自动执行。每个敏感工作流都需要将代理、用户、任务、权限、工具和结果关联起来的日志。

构建内部代理的组织可以将源材料、批准记录和运营决策保存在可搜索的 AI knowledge base 中。这类记录不能替代安全遥测，但可以保留代理部署背后的业务背景。

CrowdStrike Blueprint Alliance 的重要性在于，它识别出了企业缺失的控制平面。代理必须可被发现、可单独识别、获得严格限定的授权、受到持续观察，并能被迅速遏制。

其成员如今需要将这种共识转化为可互操作的行为。企业团队应向供应商索要模式、测试、权限撤销保障以及跨平台演示。这些答案将表明，该联盟是在构建共享基础设施，还是仅仅共享一套词汇。