AI注入攻击

当前信息安全领域的一个热门话题是“我们如何防止AI代理被滥用？” 虽然AI带来了令人惊叹的新能力，但它也伴随着从显而易见、平淡无奇到深奥复杂的一系列巨大风险。

作为一名浏览器安全领域的工作者，我最常被问及的是间接提示注入攻击。在这种攻击中，客户的AI（例如，在浏览器内或设备上）被分配与来自互联网的内容进行交互的任务。这里的威胁在于，AI代理可能会错误地将其交互的网络内容视为来自代理用户的指令，从而像被催眠一样，落入该网络内容作者的控制之下。恶意网络内容随后可以指示代理（现在成了一个“混乱的副手”）执行不安全的操作，例如分享用户的私人数据、使用该用户的钱包进行交易等。

太阳底下无新事

注入攻击在网络安全领域随处可见。 最明显的例子是内存安全漏洞，攻击者通过溢出内容数据缓冲区，导致数据被错误地当作代码执行。该漏洞根植于常见计算架构的一个基本设计选择：“冯·诺依曼架构”，其中代码和数据在系统内存中共存。尽管这在许多方面很方便，但它催生了整整一类攻击，而如果采用数据和指令截然分开的“哈佛架构”，这些攻击本可被避免。大约20年前的一项重大发展——数据执行保护/不可执行，是一项处理器功能，旨在更清晰地划分数据和代码，以防止此类错误。多年来，此类“字母汤”般的缓解措施列表只增不减。

注入攻击远不止于底层的CPU架构，而是无处不在，包括在采用了冯·诺依曼式设计的Web平台中，网页的静态文本与内联脚本代码混在一起，从而引发了持续存在的跨站脚本威胁。在这里，我们同样最终采用了一系列保护功能，如XSS过滤器（IE）、XSS审计器（Chrome），以及通过防止内容和脚本以危险方式混合，将“精灵”放回瓶子里的选择加入功能。

我承认，我对LLM AI的运作原理了解得远远不够，无法确定“哈佛架构”对于LLM是否可能实现，但从我收到的问题来看，这显然不是目前常见的架构。

我们能做些什么？

在一个AI易受注入攻击的世界里，我们能做些什么？ 一种方法是确保代理无法加载“不安全”的网络内容。由于我从事SmartScreen（一项阻止访问已知不安全网站的声誉服务）的工作，我经常被问到，我们是否也能像为普通的人类浏览器用户所做的那样，阻止代理访问不良网站。是的，我们应该并且确实这么做，但这还远远不够：SmartScreen阻止被发现进行网络钓鱼、分发恶意软件或实施技术诈骗的网站，但不良网站的集合每时每刻都在增长，而且目前进行提示注入攻击的网站甚至不太可能被识别出来。

如果阻止不良网站行不通，也许我们可以只允许“已知良好”的网站？这也存在问题。目前本身并不存在“可信网站列表”的概念。SmartScreen最接近的是一个“高流量”列表，但这仅仅反映了被认为是SmartScreen所针对的特定类型恶意威胁（例如，网络钓鱼、恶意软件、技术诈骗）不太可能来源的高流量网站列表。情况甚至更糟——许多“已知良好”的网站包含不受信任的内容，如用户生成的评论/帖子、广告、来自其他网站的文本片段等。一个允许不受信任的第三方内容的“已知良好”网站，将构成提示注入攻击的潜在来源。

最后，另一种限制风险的设计可能是限制代理的能力，要么要求监督人员的持续批准，要么采用重度沙盒，让代理在隔离的虚拟机中运行，该虚拟机无法访问任何用户信息或环境权限。如此被“阉割”后，一个被催眠的代理也无法造成太大破坏。

不幸的是，任何在沙盒中运行的代理都无法访问对于实现引人注目的场景（“在一家不错的餐厅预订两人桌位，订购鲜花，并向我的妻子发送日历提醒邮件”）至关重要的资源（例如，用户的数据或凭证），以至于沙盒化的代理对于日常用户来说吸引力可能大打折扣。

题外话：博弈论

尽管智能体AI带来了许多安全风险，产品团队仍在竞相将越来越强大的代理功能集成到他们的产品中（包括完成购买交易）。

AI公司正竞相推出能力越来越强的代理，因为每个人都担心其他AI公司中会有一家推出不那么谨慎的产品，而功能更强大、限制更少的产品将赢得市场。因此，我们最终陷入了类似于20世纪50年代末美国所处的境地，当时俄罗斯拥有4枚可用的洲际弹道导弹，但美国却让我们自己相信他们有1000枚。由于对这种恐惧的回应，美国自己也建造了上千枚洲际弹道导弹，于是俄罗斯也建造了上千枚，如此循环，直到在接下来的几十年里，我们双方基本上把世界搞得破产。