北京
如果你在一个共享办公空间里，只需要一把钥匙就能打开所有人的抽屉，会发生什么？Varonis安全团队在谷歌云的AI对话平台Dialogflow CX里，发现的就是这么一把“钥匙”——不需要管理员权限，只要拿到一个聊天机器人的编辑资格，就能控制整个项目下的所有AI代理。
Dialogflow CX是谷歌用来搭建语音和文字聊天机器人的平台，开发者可以在对话“剧本”里插入Code Blocks，本质上就是自定义的Python代码片段。问题在于，这些代码片段全跑在同一个谷歌托管的Cloud Run服务里，而且是跨代理共享的。研究负责人打了个比方：这不是隔间，这是通铺。
攻击路径比想象中更简单。恶意代码不需要绕过复杂的权限体系，因为它本身就是合法功能的一部分。研究人员解释，Cloud Run环境没有代码限制，文件系统可写、可以连接外部网络，还顶着超额权限在运行。攻击者可以直接覆盖关键文件，植入逻辑炸弹，而聊天记录和会话状态就像摊在桌上一样，随便翻。
更隐蔽的是，攻击者不光能偷看历史对话，还能调用内部函数、伪造大模型生成的回复。设想一下，一个客服机器人在你输入银行卡号后，突然弹出一条“系统升级中，请重新验证支付密码”的消息——这条消息不是来自任何黑客的电脑，而是来自你正在对话的“官方机器人”本身。凭证窃取和钓鱼攻击就这样在眼皮底下发生，受害者几乎不会起疑。
因为Cloud Run环境是按项目共享的，一个代理沦陷意味着项目下所有代理集体被控。而问题检测几乎不可能：Cloud Logging不会记录文件覆盖行为，也不会标记注入的逻辑。研究团队用的原话是“实质上不可察觉”。
时间线追得也清楚。Varonis在2025年11月向谷歌提交了漏洞报告，谷歌在2026年4月放出了初步修复，但直到2026年6月才彻底解决问题。目前还没有证据表明漏洞被野外利用，但研究人员还是给企业客户列了几条保命措施：审查Playbooks更新调用的DATA_WRITE审计日志，检查异常的会话检测错误，以及——最原始但也最管用的一招——逐个手动检查每个代理的Code Blocks，看看有没有不该出现的代码。
这件事的核心矛盾在于：平台在设计上给了开发者极高的灵活性，自定义代码能跑、能写文件、能联网，这本身是功能，不是Bug。但安全边界一旦没有画清楚，灵活性就变成了攻击面。Varonis这次发现的不是一个代码缺陷，而是一个架构设计上的信任假设出了问题——系统默认同一个项目下的所有代理都是“自己人”，但“自己人”的权限是可以被篡改的。
对于正在用或打算用AI代理平台的企业来说，这份报告抛出的不是修补建议，而是一个底线问题：你们对“平台自己人”的信任边界，到底划在哪里？
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
