当地时间 9 月 23 日，在拉斯维加斯的年度大会 Oktane 上，Okta 宣布联合 11 家厂商成立 Blueprint Alliance（蓝图联盟），一起推动一套面向 AI Agent 的开放安全参考架构。创始成员名单挺长：AWS、CrowdStrike、Databricks、Docker、Google Cloud、Lovable、Okta、Proofpoint、Salesforce、ServiceNow、Wiz、Zscaler。GE Appliances 和 World Central Kitchen 作为战略顾问参与。
安全厂商组联盟本身不新鲜。值得单独写一篇的原因是：这次要解决的不是「模型会不会说错话」，而是「Agent 已经进来了，谁给它身份、谁能管它、出事谁负责」。这是从模型安全转向运行治理的一个明确信号。
事实梳理：到底宣布了什么
第一，蓝图本身升级了。Okta 在今年 3 月提出过一份「安全 Agent 企业蓝图」，这次把它扩写成开放的多厂商参考架构，由成员共同署名、对外公开可用。核心是六个原则：
- 每个 Agent 都是一等身份，不是服务账号的附庸，要有明确的负责人或负责团队。
- 权限按任务授予，而不是给常驻权限。
- 委托链可追溯——Agent 代表人生成子 Agent 时，责任要能一路追回去。
- 运行行为持续监控，不只是上线前审一次。
- 具备即时且可逆的遏制手段——能停下来，也能恢复。
- 治理机制要跟得上 AI 的变化速度。
第二，给出了四个必须回答的问题。整套架构围绕四问展开：我的 Agent 在哪？它们能做什么？它们正在做什么？出问题我怎么响应？这四问对应四个能力板块：发现与身份登记、访问策略、运行时授权与监控、主动遏制。
第三，三项能力当天正式可用：
- Agent SSO。基于 Okta 主推的 Cross App Access（OAuth 的扩展协议），让 Agent 一次登录打通多个应用，而不是逐个应用签发长期密钥。现场演示里，一个编码 Agent 要访问 Atlassian、GitHub、Slack 三个系统，不开 Agent SSO 就得手动逐个授权；开启后随 SSO 一起完成，而且整个登录过程可被 IT 监控。
- Agent-to-Agent Connections。定义哪些 Agent 可以互相调用、各自能访问什么，并把每一次交接记录成可审计的调用链。
- Resource Access Certifications。对 Agent 的连接做周期性复核，把多余或过期的权限定期清掉。
第四，还有几项在开发中：
- Agent Gateway。坐在 Agent 和它的工具调用之间，执行策略并记录每一次交互。计划 Q3 可用。
- 端点侧的影子 Agent 发现。找出员工设备上跑着的、没人管过的 Agent。计划 Q3 可用。
- Configuration Designer。用可视化方式画出 Agent 与资源之间的连接关系。计划 Q4。
- 紧急熔断开关扩展。能吊销活跃令牌、终止正在运行的会话。计划 Q4 扩展。
第五，两组值得记住的数字。Okta 引用的预测是：到 2028 年，一家财富 500 强企业平均会有超过 15 万个 Agent 在用（2025 年这个数字还不到 15）；而眼下只有 13% 的组织认为自己已经具备了合适的 Agent 治理能力。这两句话放在一起，就是这次联盟成立的理由。
补一句背景：创始成员里没有 OpenAI、Anthropic 这类前沿模型厂商，但 Okta 方面暗示至少有一家可能加入——Anthropic 负责 MCP 的工程师出现在演讲台上参与对话，也算一个线索。
影响分析：为什么这件事对做 Agent 的人重要
第一，身份系统成了 Agent 治理的锚点。过去两年大家讨论 Agent 安全，集中在提示词注入、越权调用这些「模型层」问题上。这次联盟的思路很明确：模型层的问题要靠模型侧解，但 Agent 部署之后的治理，得落在身份层。理由是身份系统天然具备别处都没有的三样东西——唯一标识、权限分配、吊销能力。而这三样恰好对应 Agent 治理最难的三件事：它是什么、它能干什么、怎么让它立刻停下。
这一点对我们站内写过的一整套治理思路是个印证。Agent 安全七道防线 里把「权限与身份」放在基础层，权限管理怎么做 里讲的「最小权限、工具白名单、子账户隔离」，本质上是同一件事的工程做法。现在有厂商把它做成了标准产品。
第二，Agent Gateway 是这次最值得关注的一项。它本身还在开发中，但位置很关键：所有工具调用都要经过它。这意味着治理的落点从「Agent 内部」挪到了「Agent 外面的一层」——不必信任 Agent 自己会守规矩，而是让它想干活就必须过网关：任何请求都留记录，任何策略都能在这里拦。这和 沙箱隔离 是互补的两种思路：沙箱管「Agent 能碰到什么资源」，网关管「Agent 能发出什么动作」。两个都上，覆盖面才完整。
第三，那四个问题其实就是一张自查清单。不管用不用这类产品，「我的 Agent 在哪 / 能做什么 / 正在做什么 / 出事怎么响应」四问可以直接拿来审自己手上的系统。老实说，很多自建 Agent 连第一问都答不上来——散落在几个脚本、几个定时任务里，没有清单、没有负责人。
第四，周期性权限复核这件事，比的不是技术而是纪律。Resource Access Certifications 做的事情技术上很朴素：定期把 Agent 的连接翻出来，看哪些已经不需要了，删掉。但正是这种「无聊的定期动作」，在企业实践里最容易被跳过。等到出事复盘时，你会发现出问题的权限往往是半年前某次临时调试留下的。审计该记什么、怎么留，站内 审计查询字段怎么设计 和 证据包怎么留 里有可以直接用的清单。
第五，联盟里有竞争对手这件事本身就是信号。名单里 CrowdStrike、Wiz、Zscaler 在别的赛道上直接对打，AWS 和 Google Cloud 在云侧也是对手。愿意坐在一起定标准，说明大家共用一个判断：Agent 治理这个市场现在最大的敌人是「标准太多、谁都对不上谁」，而不是同行。对采购方来说这是好事——标准统一意味着以后不用被单一厂商锁死。
老达点评
第一，这次的主角不是「能不能防住」，而是「出事了能不能停」。我注意到六条原则里有一条是「遏制要即时且可逆」，在研功能里专门列了熔断开关的扩展。这是个很务实的转向。前两年 Agent 安全的话题总在追求「绝对不出事」，但真实系统里出事是概率问题。承认这一点，把「出事之后多久能停下来、能不能回滚」当成一等指标，比反复强调「我们的 Agent 不会乱来」有用得多。对自己的系统也一样：上线前先问一句「如果它今天开始乱发消息，我多久能把它关掉」，答不上来就别急着放量。失败升级规则 和 客户可见动作的最后确认 是同一套思路在流程上的落地。
第二，「给 Agent 发身份」这件事，个人和小团队现在就该跟上。不用等企业级产品落地。哪怕你只有一个跑在自己服务器上的 Agent，也可以先做三件小事：给它一个独立账号而不是复用你自己的密钥；把权限收窄到只够干这件事；在日志里能查清「哪次操作是它做的」。这三件事今天就能做，成本几乎为零，但它们是后面所有治理能力的地基。最怕的就是「先让它跑起来，安全以后再说」——那个「以后」往往变成出事之后。
第三，标准落地要时间，别把「联盟成立」当成「问题解决」。参考架构是文档，网关和熔断要等到 Q3、Q4，跨厂商的互操作更久。而且这类联盟的共同声明，价值在方向，不在时间表——延期甚至缩水都是常事。所以现在该做的是照那四个问题自查一遍，而不是等一个还没上市的网关来救场。等产品到位的时候，你已经把家底盘清、把权限收窄了，接入反而快。
总结
把这次发布压成四条：
- 12 家厂商联合，把「安全 Agent 蓝图」升级为开放的多厂商参考架构，并给出六条共同原则。
- 治理重心落在身份层：每个 Agent 是一等身份、按任务授权、委托可追溯、运行可监控、出事可即时遏制。
- 三项能力已可用（Agent SSO、Agent 间连接、权限周期复核），网关、影子 Agent 发现、可视化配置、熔断扩展还在路上。
- 四个问题可以直接当自查清单用：Agent 在哪、能做什么、正在做什么、出事怎么响应。
最后一句：Agent 治理迟早会从「可选项」变成「上线前置条件」。真到那天，被卡住的不会是那些提前把清单列好、把权限收窄的团队，而是那些连自己有多少个 Agent 都说不清的团队。现在花两小时盘一遍家底，比以后花两周做补救划算得多。
