当企业雇了一个”全知助手”，然后发现陌生人也在听
2026年3月10日，微软正式发布 Azure SRE 智能体——一个能访问服务器、读取日志、执行命令的 AI 运维助手。发布公告将它形容为”基础设施运维的未来”。一个月后，安全研究员 Yanir Tsarimi 在自己的博客里写下了另一段话：
“想象一下，你雇用了一位能够访问一切的助手——你的服务器、日志、密码、源代码。现在再想象一下，一个来自完全不相关公司的陌生人，能够无声无息地监听这位助手的每一段对话。这正是我们在 Azure SRE 智能体中发现的问题。”
这段话背后，是一个评分 8.6 分的身份验证漏洞——CVE-2026-32173。
一个”贴心助手”的诞生
Azure SRE（Site Reliability Engineering）智能体是微软 Azure 平台上的一款 AI 运维工具。它的设计理念很简单：替运维工程师干活。它能连接 Web 应用、查询日志、执行命令、读取事件数据，还能直接帮你排查故障、部署新版本。
在真实企业环境里，这类工具几乎掌握着整条基础设施的”钥匙”：部署凭证、数据库连接串、内部 API 地址、源代码仓库权限——凡是需要人肉去查去看的东西，它都能直接给你翻出来。
3月10日正式版发布后，不少企业开始将它接入自己的生产环境。
一个意外发现的漏洞
Tsarimi 是 Enclave AI 的安全研究员。4月22日，他在自己的博客中详细披露了发现过程。
他当时在研究智能体安全，测试 Azure SRE 智能体的数据流。智能体通过一个名为 /agentHub 的 WebSocket 端点传输所有活动数据——用户发送的提示词、智能体思考的过程、执行的每一条命令、返回的每一条输出。
按照设计，这个端点需要 Token 才能连接。Tsarimi 拿自己的 Entra ID 账号试了试——能连上。他又换了一个完全无关的微软账号——也能连上。
问题就出在这里。
/agentHub 端点虽然要求 Token，但底层的 Entra ID 应用注册被配置成了”多租户模式”。这意味着，任何微软 Entra ID 租户下的任何账号，都能获取一个”有效”的 Token 来接入这个 Hub。Hub 收到 Token 后只检查两件事：Token 格式是否正确？受众（Audience）是否匹配？它从来不问第三个问题：这个调用方属于目标租户吗？它有权限访问这条数据流吗？
Tsarimi 写道：”Hub 随后只检查：Token 是否有效？是的。受众是否正确？是的。但它从未追问：这个调用方是否属于目标租户？他们是否被授权使用该智能体？他们是否拥有访问该资源的任何角色？”
连接建立后，Hub 会向所有连接的客户端广播全部事件——没有任何身份过滤。
能截获什么？
Tsarimi 在自己的测试环境里观察到，通过这个漏洞可以获取：
- 用户发送给智能体的完整提示词
- 智能体返回的每一条响应和推理过程
- 每条命令的完整参数和执行输出
- 线上 Web 应用的部署凭证
他写道：”真实攻击目标的监听者同样可以获取相同内容——无声无息，完全不会留下任何提示。”
这不是理论风险。攻击者只要知道目标智能体的子域名（Tsarimi 指出该域名具有可预测性，可以被枚举），再写约 15 行 Python 代码，就能完成监听。整个过程在受害方的日志里完全不留痕迹——没有异常登录、没有未授权访问的告警，什么都没有。
苏黎世金融基础设施运营商 SIX Group 的网络安全研究员 Alexander Hagenah 评价这个漏洞的危害时打了个比方：
“普通 API 问题通常受限于特定端点、数据集或权限检查。而对于 AI 运维智能体而言，智能体本身成为基础设施状态、日志、源代码、事件上下文、命令、输出，乃至故障排查过程中出现的凭证的汇聚节点。实际效果就像是在旁观一位拥有高级权限的操作员在大声思考。”
微软做了什么
Tsarimi 通过正常的漏洞披露程序向微软报告了这个问题。微软确认漏洞存在，并在服务器端完成了修复。官方声明表示，客户无需手动操作，补丁已自动部署。
但有一个群体需要特别注意：在预览阶段（3月10日正式发布前）就已经开始使用 Azure SRE 智能体的企业。微软建议这些组织将预览阶段视为潜在的数据泄露窗口，全面排查可能通过智能体对话或命令行输出传递过的凭证、配置数据和其他敏感信息——能轮换的轮换，能撤销的撤销。
为什么这个漏洞值得警惕
如果用传统的 API 安全思维来看这个漏洞，很多人会觉得：不就一个接口没做租户隔离吗？打个补丁就好了。
但 AI 运维智能体的本质与传统 API 完全不同。传统 API 往往是针对特定功能设计的——查订单的只能查订单，查用户的只能查用户。而 SRE 智能体是一个拥有广泛权限的”中枢”：它把分散在各处的信息汇总到同一个会话里，把运维人员需要的所有上下文都串在一起。
对于攻击者来说，这意味着原本需要好几步才能拼凑出来的”目标画像”，现在只要监听一个会话就全拿到了。而且整个过程无声无息，没有告警，受害方甚至不知道发生了什么。
Tsarimi 在博客中的一句话点出了核心问题：”Token 有效不应成为充分条件。服务必须验证调用方是否属于正确的租户、是否被授权访问特定智能体，以及是否被允许访问特定数据流。”
给企业的教训
这件事暴露的不只是微软的一个配置错误，而是整个 AI 运维智能体领域的安全盲区。
Hagenah 建议，企业在引入这类工具时，应该像对待特权自动化平台一样严格治理，而不是当作普通 SaaS 工具松管。具体来说：
- 严格租户隔离：确保每个租户的数据流只对该租户可见，任何跨租户的访问都要经过独立验证
- 最小权限原则：智能体应该在最小权限的专用托管身份下运行，与日志系统、代码仓库、事件平台的集成应与其他特权系统同等严格审查
- 可观测性：企业需要掌握连接者的身份、访问的会话、执行了哪些命令、返回了什么数据——日志必须可导出至 SIEM 系统
- 如果用过预览版，先假设已经泄露：主动轮换在预览阶段通过智能体传递过的所有凭证
信息来源