黑进 Google Bard——从提示注入到数据外泄
一位安全研究人员展示了如何通过读取一个带有隐藏指令的共享 Google Doc，并将这些指令转化为会回传数据的 Markdown 图片 URL，诱使 Google Bard 外泄用户私密对话的部分内容。评论者借此展开讨论，把提示注入视为当前 LLM 架构的根本性弱点，认为系统提示、微调或检测模型都无法可靠地阻止这类攻击。许多人得出的结论是：在架构演进到能够将指令与数据分离之前，LLM 应被视为不可信组件并严格置于沙箱中，尤其是在连接邮件、文档或其他敏感系统时。
Bard 漏洞与数据外泄
- Bard 会渲染 Markdown 图片，并且可以读取 Google Docs 作为上下文。
- 一个共享文档可以包含隐藏指令，诱使 Bard 生成带有私密对话部分内容编码的图片 URL。
- 当 Bard 的 UI 加载这些图片时，受害者的对话就会被发送到攻击者的服务器。
- 一些读者起初误解了这一点；另一些人澄清说，被外泄的数据是用户此前与 Bard 的对话，而不是随机的新数据。
提示注入作为一个根本性问题
- 像“只服从文本框中的内容”或“绝不做 X”这样的系统提示，被认为并不可靠；攻击者之后可以在不受信任的内容中加入“忽略之前所有指令”。
- 有报道称，对提示进行净化的尝试（例如类似 “addslashes” 的转义、将“指令”和“数据”拆分）在实践中都会失败。
- 多位评论者将这比作 XSS、SQL 注入或带内信号传递：代码与数据共享同一条未加区分的通道。
安全模型、权限与沙箱
- 许多人认为，LLM 必须被视为不可信组件，并像移动操作系统应用一样，放在严格的沙箱和权限控制之中。
- 对于那些能读取邮件、文档、日历等内容，然后又会对用户可访问但不可信的内容中的恶意隐藏指令作出响应的助手，大家表达了强烈担忧。
- 有人建议让 LLM 只访问用户本来就有权限查看的数据；也有人指出，这并不能解决不可信输入或外泄风险。
检测方法及其局限
- 一家公司声称其检测器可以捕捉这种攻击；批评者则回应说，这类分类器和杀毒软件一样是概率性的，既会误报也会漏报。
- 对于严重的数据外泄威胁，评论者认为“也许能抓到”是不够的；真正稳健的架构性防御仍然缺失。
- 像“保姆 LLM”审查输出之类的想法被认为最终仍会被精心构造的提示攻破（“无穷递归”）。
架构层面的争论
- 一些人建议，未来的模型必须将指令与数据分离，例如采用双重 token 流、不可执行的数据通道。
- 另一些人怀疑这在当前的 Transformer 设计下是否可行，因为一切都只是一个 token 序列，而且模型实际上是图灵完备的。
- 还有人认为这类似于从早期不安全架构演进到具有不可执行数据的架构，但也承认这一问题尚未解决。
对 LLM 和 Bard 的情绪
- 令人兴奋的是，这被视为一个“真实”的 AI 安全问题，而不是更抽象的对齐讨论。
- 对 LLM 的看法分歧很大：有人把它们贬为“暴力猜测器”；也有人强调它们已经走得很远，并预计还会继续进步。
- Bard 本身则因其可被破解（例如通过上下文溢出）以及对自身能力的表述混乱而受到批评，这进一步加深了人们对其产品成熟度的怀疑。