谷歌云Vertex AI平台存在一个设计层面的权限漏洞。Palo Alto Networks Unit 42的研究人员发现，部署在该平台上的AI代理（AI Agent）可能被攻击者武器化，窃取敏感数据并渗透整个云环境。
这个漏洞的核心在于"服务代理"（Service Agent）的默认权限过大——它像一把万能钥匙，本只想开个抽屉，结果能打开整栋楼的门。
Unit 42研究员Ofir Shaty在报告中描述了一个危险场景：「一个被误配置或入侵的代理会变成'双面间谍'——表面上执行正常任务，暗地里却在窃取敏感数据、破坏基础设施、为攻击者留后门。」
具体而言，问题出在Vertex AI的"每项目每产品服务代理"（P4SA）。当开发者用Agent Development Kit（ADK，代理开发工具包）构建AI代理并通过Agent Engine部署后，每次调用代理都会触发谷歌元数据服务，暴露服务代理的凭证、托管项目信息、代理身份及机器权限范围。
研究人员实测：利用窃取的凭证，他们能从AI代理的执行环境跳转到客户项目，绕过隔离机制，获得该项目内所有谷歌云存储桶（Cloud Storage Buckets）的无限制读取权限。
权限溢出：从"租户隔离"到"内部基础设施裸奔"
Vertex AI Agent Engine运行在谷歌管理的"租户项目"（Tenant Project）中。理论上，这应该是一道隔离屏障——客户数据和谷歌内部基础设施各住各的"公寓楼"。
但Unit 42发现，窃取的P4SA凭证还能访问租户项目内的云存储桶，获取更多平台内部架构细节。虽然这些凭证最终缺乏实际访问暴露存储桶的权限，但攻击面已经打开。
更棘手的是第二重漏洞：同一套P4SA凭证允许访问受限的谷歌自有Artifact Registry（制品仓库）代码库。这些代码库在Agent Engine部署过程中被暴露，攻击者可借此下载构成Vertex AI Reasoning Engine核心的私有容器镜像。
「获取这些镜像的访问权限，可能让攻击者发现额外的漏洞、敏感配置信息，或获得对Vertex AI平台内部运作的未授权洞察。」Unit 42在报告中指出。
第三重漏洞接踵而至：被入侵的P4SA凭证不仅能下载部署日志中列出的镜像，还能暴露Artifact Registry代码库的其他内容——包括多个其他受限镜像。
攻击链完整还原：从"正常调用"到"核心代码库沦陷"
让我们把攻击路径串起来：开发者部署Vertex AI代理 → 用户正常调用 → 元数据服务暴露凭证 → 攻击者横向移动至客户项目 → 读取所有存储桶 → 尝试访问租户项目 → 发现Artifact Registry入口 → 下载核心引擎镜像。
这个链条中，没有一步需要复杂的0day漏洞。攻击者只是顺着平台设计的"正常通道"走了下去，就像酒店房卡能刷开隔壁房间——问题出在钥匙的权限设计，而非门锁被撬。
Unit 42将这一发现通报给谷歌后，谷歌采取了缓解措施：限制P4SA访问Artifact Registry仓库的权限，并移除对Cloud Build（云构建）日志的读取权限。
但研究者指出，P4SA仍保留对Cloud Storage的广泛访问权限，「这凸显了持续审查和最小权限原则在保护云原生AI工作负载中的重要性」。
行业隐喻：AI代理的"权限膨胀"通病
这个漏洞并非谷歌独有。随着AI代理从"聊天机器人"进化成能调用工具、访问数据库、执行代码的"数字员工"，权限管理正在成为新的安全雷区。
传统软件的安全模型是"用户请求→系统验证→执行操作"。AI代理的加入让链条变长："用户意图→AI理解→工具选择→系统验证→执行操作"。每一步都可能产生权限漂移——AI为了"完成任务"，往往需要比人类用户更广泛的访问权。
Vertex AI的P4SA设计，本质上是把AI代理的权限打包成了一个"超级用户"。方便开发者开箱即用，也方便攻击者一锅端。
Unit 42建议组织采取三项措施：审查和限制AI服务代理的权限范围；监控异常的数据访问模式；将AI工作负载隔离在独立的云项目中。
谷歌尚未公开披露受影响用户规模或是否已有实际攻击案例。但对于正在把AI代理接入核心业务的组织来说，一个值得追问的问题是：你的AI代理今天访问了多少它本不需要的数据？
热门跟贴