Amazon 和 Google 浏览器智能体面临提示注入难题，尚无完美解决方案

Amazon 和 Google 的浏览器智能体如今面临同样的矛盾：自主性越高，提示注入攻击造成损害的空间就越大。尽管已推出新的防护措施，研究人员仍不断发现能够通过普通网页、电子邮件、表单和社交帖子操纵智能体的方法。这一弱点正成为 AI 浏览器设计的长期限制，而非另一个等待一次干净修复的浏览器漏洞。

眼下最令人担忧的是间接提示注入，即恶意指令隐藏在 AI 智能体读取的内容中。这些指令可能与用户请求相冲突，并影响智能体的下一步行动。传统浏览器只会显示恶意内容；智能体浏览器则可能理解这些内容、跨入另一项服务，并以用户的权限采取行动。

这种区别让 Amazon 和 Google 置身于一场更广泛的安全竞争中，参与者包括 Microsoft、OpenAI、Anthropic、Perplexity 以及专业浏览器厂商。每家公司都希望智能体能够在网络上完成实用任务。然而，每增加一项权限，智能体误判自己应服从谁时所带来的后果就会扩大。

令人不安的结论并不是浏览器智能体无法使用，而是厂商不能将提示注入检测视为完整的安全边界。企业必须假设部分恶意指令会穿透防线，并限制遭入侵智能体能够访问、更改或披露的内容。

Amazon 和 Google 浏览器安全竞赛发生了什么变化

提示注入已从理论上的模型弱点，演变为实际运营中的浏览器安全问题。

安全研究人员已多次证明，恶意内容无需利用浏览器传统的代码执行路径，也能将智能体引向错误方向。攻击者瞄准的其实是模型对内容的理解。隐藏指令可能出现在网页、电子邮件、文档，甚至用户界面元素中。

当智能体能够使用已认证的浏览器会话时，攻击就会变得严重。它可能读取收件箱、打开另一标签页、提交表单，或从已连接服务中获取信息。正常任务中看似便利的操作，会成为攻击链中的有用环节。

Zenity 研究人员将这类更广泛的智能体浏览器弱点称为 PleaseFix。他们的测试针对的是智能体在网站和本地资源之间移动时遵循自然语言目标的方式。根据浏览器安全研究结果，研究人员发现不同产品采用了不同设计和防护措施，但仍在商用智能体浏览器中识别出攻击路径。

重要变化在于攻击者的路径。传统浏览器攻击通常依赖软件漏洞、恶意扩展、被盗凭据或诱导点击。提示注入则可以从智能体原本应在普通请求中处理的内容开始。

用户可能要求助手总结一个产品页面。该页面可能包含视觉上隐藏、但模型仍可读取的指令。攻击者也可能将指令置入公开帖子、新闻订阅表单，或通过浏览器工具获取的内容中。

这并不意味着每一条注入指令都会成功。模型、分类器、权限系统和操作检查能够阻止许多尝试。问题在于，这些控制措施面对的是能不断调整措辞、呈现方式、时机和上下文的自适应对手。

Google 自身的测量进一步印证了这一转变。其安全团队扫描公开网络内容中已知的间接提示注入模式，并报告称，2025 年 11 月至 2026 年 2 月期间，恶意内容检测量相对增长了 32%。该公司还发现大量看似攻击的良性文本，使可靠分类变得更复杂。

这项网络威胁研究之所以重要，是因为浏览器防御必须处理两种相互竞争的错误。如果漏掉恶意内容，智能体可能遭操纵；如果拦截过于激进，正常页面和合法指令就会无法使用。

Amazon 是通过其云端智能体平台而非面向大众的浏览器来应对这一问题。Bedrock AgentCore Browser 为开发者提供隔离环境，让智能体能够浏览网站、填写表单和提取信息。即使底层浏览器会话已被隔离，这些能力仍会使智能体接触不可信内容。

因此，Amazon 和 Google 的比较反映了两种不同的分发模式。Google 正在向人们直接使用的浏览器添加智能体功能；Amazon 则提供基础设施，供企业构建自己的浏览器自动化系统。两者都必须处理开放网络内容与具备特权的智能体操作之间的同一冲突。

浏览器智能体为何削弱了一条旧有安全边界

核心弱点出现在同一模型通过共享推理过程接收可信指令和不可信数据时。

网络浏览器花了数十年时间将不同网站彼此隔离。同源策略通常会阻止一个源随意读取另一个源的敏感信息。沙箱、权限提示、进程隔离和内容安全策略则提供了进一步屏障。

AI 智能体可以跨越这些边界，因为用户授权它执行任务。它可以读取一个页面、查询另一项服务，并将结果结合起来。这种能力是产品的核心价值，但也形成了一座恶意内容可能试图控制的桥梁。

模型并不需要直接突破同源策略。它可以使用对用户合法开放的浏览器功能。如果恶意页面说服智能体打开收件箱、读取消息并传输信息，那么每一个单独步骤看起来都可能已获授权。

这有时被称为“混淆代理人”问题。一个受信任组件拥有合法权限，但攻击者操纵它将该权限用于错误目的。浏览器智能体使这个代理人变得可对话、具有概率性，并且能够规划多个步骤。

针对开源浏览器智能体的研究已展示，这种模式如何导致凭据泄露和未授权操作。一项学术研究报告称，在一个浏览器自动化框架中发现了提示注入、域验证绕过和凭据外泄问题。其浏览器智能体分析还包括一个已披露漏洞及可运行的概念验证。

当智能体在任务之间保留记忆时，问题会进一步扩大。恶意指令并不总是需要立即造成损害。它可能试图改变存储的上下文、创建误导性偏好，或在敏感资源可用时影响之后的决策。

视觉理解带来了另一条路径。能够解读截图的智能体，可能遇到嵌入图像或界面元素中的指令。仅过滤原始页面文本，无法捕捉多模态模型可感知的每一条信息。

攻击者也可以避开“忽略之前的指令”等明显措辞。他们可以将恶意步骤包装成用户原始目标的必要部分。例如，订阅新闻通讯的请求，可能成为获取数据或打开另一项工具的借口。

这一手法之所以重要，是因为许多防御措施会寻找用户目标与恶意指令之间的冲突。攻击者反而可以让恶意操作看似符合该目标。措辞会变得不那么可疑，而所请求的能力仍然危险。

提示注入与 SQL 注入有一个关键区别。软件可以通过严格语法和参数化查询，将 SQL 命令与数据分离。自然语言智能体依赖上下文理解，因此指令与信息之间并不总存在清晰的技术边界。

结构化消息和来源标签可以改善这种分离。开发者可以标记哪些内容来自用户、网页、工具或应用程序。然而，当任务依赖外部内容的含义时，模型仍需要理解这些内容。

以BrowseSafe发表的研究评估了浏览器智能体中的提示注入风险，并考察了现实环境下的防御措施。这项工作反映出一种新兴共识：检测有所帮助，但浏览器架构和权限设计决定了最终影响。

这也是为何完美分类器也无法解决全部问题。分类器同样需要处理模糊语言，攻击者也可以测试新的变体。防御者需要多种彼此独立的控制措施，避免一次错误判断就解锁用户的整个浏览器会话。

Amazon 和 Google 的防御措施选择控制，而非追求完美检测

Amazon 和 Google 都在构建分层防御，因为两家公司都无法依赖单一提示注入过滤器。

Google 曾介绍一种在智能体操作抵达浏览器前对其进行检查的架构。其 User Alignment Critic 是一个独立组件，旨在评估拟议操作是否符合用户明确表达的目标。这种分离有助于防止主智能体自行批准其风险解读。

Google 还使用来源信息、操作确认、模型训练和检测系统。敏感操作可能需要用户明确批准。浏览器可以限制传递给智能体的信息，并围绕凭据保留安全边界。

在其智能体 Chrome 设计中，Google 承认，接触不可信网络内容会带来固有的间接提示注入风险。这一表述意义重大。该公司将此问题视为需要持续缓解的架构性威胁。

操作确认很有用，因为它能在关键步骤前恢复人类判断。用户可以拒绝意外的购买、消息、登录或数据传输。然而，频繁提示也可能变得司空见惯，造成与 Cookie 提示和权限对话框相同的疲劳。

因此，确认应聚焦于具有实质意义的转变。向新域名发送数据，应比滚动页面受到更严格审查。打开密码管理器的风险高于提取一条公开标题。扁平化审批模式会将不等价的操作视为相同。

Amazon 强调围绕其托管浏览器环境的策略执行。使用 Bedrock AgentCore 的开发者可以应用 Chrome 企业策略，限制智能体的浏览范围。这些规则在浏览器层运行，独立于智能体的提示或推理过程。

这种区别很重要。模型可能遭操纵，但确定性的网络或浏览器策略仍会阻止被禁止的目的地。Amazon 的浏览器策略控制让构建者能够在智能体开始工作前定义允许和阻止的位置。

对于范围狭窄的企业工作流程，允许列表可以显著降低风险敞口。采购智能体可能只需要访问一小组获批准的供应商门户。客户服务智能体可能只需要支持平台和内部知识系统。

这些边界对于通用研究而言更难维持。负责比较产品或追踪新闻的智能体需要广泛的网络访问权限。任务越开放，严格的目标地址白名单就越不实用。

隔离提供了另一层保护。托管浏览器会话可以将智能体活动与员工日常使用的浏览器配置文件分开。如果智能体遭到入侵，它不应自动继承用户可用的所有 Cookie、已打开标签页、已保存凭据和扩展程序。

隔离并不判断一条指令是否恶意。它限制的是错误决策发生后可调用的资源。这与容器、虚拟机和受限服务账户背后的实用逻辑相同。

最小权限原则将这种方法延伸到工具和数据层面。只需要读取公开网页的智能体，不应获得发送电子邮件的权限。起草交易的智能体，不应被允许批准该交易。读取文档的智能体，也不应自动获得访问所有已连接文件夹的权限。

因此，Amazon 和 Google 的防御路径最终指向一项共同原则：模型仍会出错，因此安全措施必须存在于模型之外。浏览器策略、身份边界、审批关卡、日志记录和隔离会话，能够遏制检测机制未能阻止的错误。

真正的权衡：能力与遏制

每一项能够可靠降低提示注入影响的防御措施，都会限制智能体自主性的一部分。

当浏览器智能体能够在服务之间自由移动、记住上下文并完成多步骤任务时，它会变得更有用。这些能力同样会增加攻击者能够影响的决策数量。这种安全权衡已内嵌于产品的价值主张之中。

设想一个被要求安排旅行的智能体。它可能搜索航班、比较酒店、查看日历、获取会员信息并准备预订。如果外部内容改变了计划方向，智能体可能泄露个人详情，或选择由攻击者控制的目的地。

一个严格受控的系统可以通过将智能体限制为只读搜索来避免这种结果。然而，它将无法完成预订。加入购买权限会恢复便利性，同时也会提高错误操作的影响。

同样的模式也适用于企业内部。销售智能体可以研究客户并起草外联内容，风险相对较低。赋予它发送消息、更新客户记录和附加内部文档的权限，会带来更有价值的自动化，也会扩大故障影响半径。

这正是为什么应将提示注入视为能力安全问题。团队应当询问：智能体在接受恶意指令后能够做什么。模型的攻击成功率很重要，但获准造成的后果更重要。

只读摘要工具与连接支付系统的智能体，呈现的是不同风险。两者都可能产生误导性输出。只有后者能够在没有其他控制措施的情况下，将错误理解转化为外部交易。

供应商有时会将更高的检测率宣传为安全性提升的证据。这些结果可能具有价值，但它们取决于测试集、攻击者知识、模型版本和获准使用的工具。自适应攻击可以针对基准测试未涵盖的情况。

误报同样会带来运营成本。防御模型可能拒绝看似注入尝试的合法内容。安全团队可以通过提高敏感度来减少漏报，但用户随后会遇到更多被阻止的任务和不必要的确认。

这一设计问题没有固定终点，因为智能体能力持续变化。针对网页摘要测试过的防护措施，并不会自动覆盖视觉导航、文件下载、操作系统对话框或与新工具协议的交互。

浏览器更新可能引入额外行为。模型升级可能改变智能体对模糊指令的理解方式。已连接服务可能暴露新的操作，而浏览器供应商并不控制其界面。安全测试必须覆盖完整系统，而非某一个模型快照。

第三方扩展和集成会进一步使情况复杂化。它们可能扩展智能体可见的内容，或提供新的执行路径。企业可能会谨慎配置主浏览器，却忽视了一个拥有广泛页面访问权限的扩展程序。

因此，持怀疑态度是必要的。分层防御能够降低风险，但有关“安全智能体”的公开说法不应被解读为免疫。公司应披露已测试的环境、被阻止的操作、用户确认规则以及剩余攻击面。

与此同时，断言所有 AI 浏览器都绝对不安全，也过度简化了这一决策。风险取决于智能体的权限、可访问数据、隔离措施和任务。即使采购智能体不适合，受限的研究助手仍可能适用于低风险环境。

安全团队需要部署分级，而不是一种笼统的批准。低风险智能体可以在隔离的只读会话中运行。中等风险系统可以起草操作供人工审核。高风险工作流应要求模型外部的确定性授权。

这种结构承认核心权衡，而不是假装它已经消失。用户仍能获得自动化，但只有当周边控制措施能够吸收模型故障时，自主性才会提升。

谁正受到提示注入问题的压力

浏览器供应商面对新闻头条，但企业身份和应用团队承担了很大一部分实际负担。

Google 必须保护那些浏览器配置文件中已包含高价值会话的用户。Chrome 可以将智能体连接到电子邮件、日历、文档、购物账户和工作场所工具。因此，一个界面可能暴露许多不同的信任域。

Amazon 的客户面临不同责任。Bedrock AgentCore 提供托管组件和控制措施，但开发者仍决定智能体可以访问哪些目的地、身份、工具和数据。安全的服务可以支撑不安全的应用配置。

Microsoft、OpenAI、Anthropic 和 Perplexity 面临同样的竞争压力。用户期望浏览器智能体处理更多工作，而安全研究人员会测试每一项新能力。与允许更广泛自动化的竞争对手相比，限制性设计可能显得不那么有用。

这一竞争周期可能促使供应商以快于企业更新治理机制的速度扩展权限。新的智能体功能可以通过熟悉的浏览器和生产力工具到来，从而绕过独立应用通常需要的采购审查。

安全团队应将智能体功能作为能力，而非产品名称进行盘点。相关问题包括：对已认证会话、本地文件、已连接应用、记忆、消息、下载和代码执行的访问权限。

应用负责人也需要重新审视网页内容。内部仪表板过去主要是为人类读者设计的。如果智能体将其文本同时视为信息和潜在指令，内容来源就会成为应用安全的一部分。

身份团队必须决定智能体是共享人类凭据，还是获得独立的服务身份。共享会话较为方便，但会削弱可追责性。独立身份支持更严格的权限、更清晰的日志和更快的撤销。

开发者需要能够解释智能体看到了什么、又为何采取行动的事件记录。传统浏览器历史记录会显示访问过的页面，但可能无法捕获智能体操作背后的精确内容、模型决策、工具调用和授权。

事件响应人员面临另一项困难。成功的提示注入可能看起来像正常用户活动，因为智能体使用的是有效凭据和合法浏览器功能。检测必须审视意图、顺序、目的地和数据流动。

员工也需要更清晰的信号。他们应知道智能体何时读取页面、进入另一项服务、访问私密信息，或准备不可逆操作。一个小型动画图标无法传达完整的信任转换。

企业采购方应询问供应商：当内容是视觉化、混淆、多语言或分散在多个步骤中时，防御措施如何运作。他们还应询问安全检查是否独立于主智能体运行，以及模型变化后策略是否仍可强制执行。

最有力的评估应包括针对组织实际工作流的对抗性测试。通用基准无法复现每个内部应用、数据源和权限组合。红队应测试现实目标，同时改变恶意内容。

采购合同也需要明确的事件条款。买方应了解日志保留、漏洞披露、模型更新实践以及不安全配置的责任归属。提示注入跨越了供应商行为与客户设计之间的边界。

没有任何公司能仅靠一次模型更新解决这一共同责任问题。供应商必须提供可强制执行的控制措施，而客户必须围绕具体任务进行配置。双方都需要证明这些控制措施能够协同工作。

接下来关注 Amazon、Google 和 AI 浏览器供应商的什么

下一阶段将由遏制证据来评判，而不是由“提示注入已被消除”的承诺来评判。

第一个信号是，供应商是否发布覆盖完整浏览器工作流的可复现评估。测试应包含隐藏网页文本、图像、跨标签页操作、存储记忆、已连接账户和多步骤意图操纵。单一的拒绝基准提供的视角过于狭窄。

结果应将检测与影响区分开来。影响摘要的攻击，与发送数据或完成购买的攻击不同。买方需要知道智能体遵循敌对内容的频率，以及哪些控制措施能阻止由此产生的操作。

第二个信号是对确定性限制的更广泛采用。Amazon 的浏览器策略提供了一个例子，因为无论模型如何推理，它们都可以阻止目的地。Google 的操作检查和权限关卡，则围绕用户意图发挥类似作用。

关注这些控制措施是否更容易以细粒度方式配置。企业需要基于目的地、数据敏感性、操作类型、身份和任务的策略。单个覆盖整个浏览器的开关无法表达这些差异。

第三个信号是供应商如何处理新披露的攻击链。即使漏洞类别仍然存在，快速修补依然重要。发行说明应解释修复改变的是检测、权限范围、隔离，还是底层智能体架构。

研究人员会持续发现新的变体，因为智能体行为具有非确定性。阻止某个短语或网页模式的补丁，并不能解决不同上下文中的意图冲突。持久改进应从不可信路径中移除能力，或加入独立授权。

据报道，Google 发现恶意网页模式有所增加，这为此项工作增添了紧迫性。该公司的扫描显示，攻击复杂性仍然有限，但活动增加给攻击者带来了更多测试已部署产品的机会。浏览器智能体的更广泛采用，会使成功技术更具价值。

Amazon 与 Google 的竞争也将揭示用户接受哪些安全妥协。Google 可以直接在 Chrome 中放置确认提示，让个人用户看到它们。Amazon 可以向开发者提供基础设施策略，但每位客户都必须决定这些策略应有多严格。

对于企业部署，近期标准应当很简单：隔离智能体，为其赋予独立身份，限制目的地，最小化工具，并在产生重要后果的操作前要求审批。记录从不可信内容到特权行为的每一次转换。

知识工作者应尽可能避免在实验性代理会话中使用敏感账户。他们还应审查拟发送的消息、交易、下载内容和数据传输。更新浏览器固然重要，但无法消除底层的理解问题。

开发者应将每个网页、电子邮件、上传文档和检索到的笔记都视为不可信输入。他们应假定主模型最终会误判其中的部分内容。模型之外的控制机制必须决定接下来会发生什么。

“没有完美修复方案”这一结论令人不安，因为它改变了部署时需要提出的问题。团队不应再问浏览器代理是否能免疫提示注入，而应问：一次成功的注入是否能够触及任何重要内容。

在启用下一项自主功能之前，应梳理其被允许执行的最坏操作，并判断其收益是否足以证明这种风险暴露是合理的。如果答案尚不明确，就应让代理保持只读，或要求人工批准。Amazon 与 Google 的竞逐将带来更好的防御措施，但负责任的采用仍取决于有效隔离。