随着 Amazon Google 安全竞争升温，AWS 为 AI Agent 设下硬性限制

AWS 为 AI Agent 设置了可强制执行的限制，即使攻击者或受污染的数据可能操纵其推理过程。这一举措加剧了 Amazon Google 围绕哪家云平台能安全地将 Agent 连接到高价值业务系统的竞争。

Amazon Bedrock AgentCore Policy 会在 Agent 请求的工具操作抵达底层服务前进行检查。被操纵的 Agent 仍可能生成危险请求，但当该请求与外部策略冲突时，应会被拒绝。

这一区别至关重要，因为提示词过滤从未构成完整的安全边界。模型通过同一套概率机制处理指令和不受信任的数据。AWS 现在将模型视为不受信任的决策者，而非最终权威。

Google Cloud 和 Microsoft 也正通过各自的身份、网关和信息流控制机制遵循同样的大方向。新兴竞争不再仅限于模型质量。云服务商必须证明，Agent 能够采取行动，而不会继承对每个已连接系统的无限制访问权限。

AWS 将授权置于 Agent 之外

AWS 正在将 Agent 想要执行的操作，与基础设施允许其执行的操作分离开来。

Amazon Bedrock AgentCore 中的策略在 Agent 与工具之间的交互周围建立了一道保护边界。该服务会拦截经由 AgentCore Gateway 路由的请求，然后在允许工具调用前评估每个请求。

AgentCore Gateway 通过托管接口将 Agent 与 API、函数及其他工具连接起来。策略引擎位于该连接旁，而不是 Agent 的提示词或编排代码之中。

这一部署位置改变了安全模型。系统提示词或许会要求 Agent 永远不要检索受限的客户记录。然而，提示词注入可能说服模型忽略该指令，或以不同方式解读它。

外部授权引擎不需要模型认同。它会使用显式规则、经过验证的身份、工具参数和可用的请求上下文来评估拟议操作。

AWS 使用其开源授权语言 Cedar 来表达这些规则。一项 Cedar 策略会识别发出请求的主体、所请求的操作、受保护的资源，以及任何必需条件。

该服务遵循默认拒绝语义。除非策略明确允许，否则操作不会获得访问权限。匹配的禁止规则也会覆盖原本可能允许该请求的任何更广泛权限。

AWS 在其 AgentCore 策略指南中解释了这些机制。该指南称，每个经路由的 Agent 请求都会在授予工具访问权限前接受评估。

开发者可以直接编写 Cedar，也可以用自然语言描述需求。自然语言编写服务会将这些需求转换为候选 Cedar 策略。

AWS 表示，该服务会根据网关的工具架构验证生成的策略。它还会检查看似过于宽松、过于严格或无法满足的规则。

这一生成过程并不会使含糊的需求变得安全。AWS 警告称，自然语言策略仍需使用精确、无歧义的措辞。安全团队必须审查生成的 Cedar，而不能将生成的策略视为不容置疑的代码。

创建策略的模型也与执行策略的机制相互独立。部署后，正式策略将控制授权决策，而不是再向另一个模型征询意见。

设想一个内部支持 Agent，它拥有读取账户和发放退款的工具。一家公司可以允许每位支持代表读取其负责的账户，但只允许主管批准金额较大的退款。

若电子邮件中包含要求退款的恶意指令，Agent 可能尝试执行该操作。当经过验证的员工缺少所需角色，或金额超出策略范围时，网关仍可拒绝该操作。

被拒绝的请求无需抵达支付系统。这一结果比要求 Agent 识别恶意指令的每一种变体更可靠。

根据 AWS 发布文档，AgentCore Policy 已在 13 个 AWS 区域全面推出。集中式策略可以一致地应用于通过关联网关连接的多个 Agent 和工具。

CloudWatch 集成会记录授权决策，以便进行监控和审计。这些记录让安全团队能够更清楚地了解 Agent 请求、获准或被拒绝了哪些操作。

因此，眼下的变化是架构性的，而非表面修饰。AWS 正在不确定的模型行为与影响重大的企业系统之间设置一个确定性的检查点。

为什么提示词注入改变了 Amazon Google 的竞争格局

Amazon Google 的云竞争如今取决于能否遏制遭入侵的 Agent，而不仅仅是改进它们的回答。

当 AI Agent 能够检索私密信息、调用 API、发送消息或更改记录时，它们才真正有用。这些权限同样决定了遭操纵后可能造成的损害。

提示词注入会将敌对指令插入模型所处理的内容中。直接注入来自用户请求，而间接注入则可能隐藏在网站、文档、电子邮件或工具响应中。

研究供应商的 Agent 可能会遇到嵌入网页中的指令。这些指令可能要求它检索机密文件，并通过另一个已连接工具发送出去。

内容过滤器或许能检测到熟悉的攻击模式，但也可能漏掉不寻常的表述、经过编码的命令，或分散在多次交互中的指令序列。

底层问题并不限于恶意提示词。模型可能臆造一项操作、误解业务规则，或将单独来看可接受的工具组合成不可接受的工作流。

OWASP 将这一情况描述为过度代理权限。当 LLM 获得足以在产生意外输出后造成有害影响的功能或权限时，风险便会出现。

授权机制限制了由此造成的影响范围。系统假定 Agent 最终会做出错误决策，然后阻止该决策变成不受限制的操作。

这种方法类似于既有的云安全实践。应用程序应仅获得完成任务所需的权限，而敏感操作应面临额外检查。

Agent 让这一原则变得更复杂，因为它们会动态选择工具。它们还可以将多次调用串联起来、在步骤间保留上下文，并在没有直接监督的情况下运行更长时间。

因此，拥有广泛权限的静态服务账户可能成为严重负担。无论涉及的用户或任务为何，Agent 实际上都会获得附加到该凭证的每一项能力。

AWS 可以将 AgentCore 请求连接到 OAuth 用户或 AWS Identity and Access Management 实体。策略随后可以考虑请求背后的身份，而不只是依赖 Agent 共享的服务角色。

随着 Google 扩展基于 Gemini 的 Agent 和 Model Context Protocol 连接，它也面临同样的问题。MCP 是一种标准接口，可让模型发现并调用外部工具。

Google 的 MCP 安全指南建议对生产访问使用拒绝策略、严格限定权限、清理输入并进行监控。该指南还警告，否则安全性可能完全依赖于 Agent 编程。

这种趋同非常重要。Amazon Google 的竞争长期聚焦于模型可用性、基础设施、数据平台和开发者工具。Agent 授权正成为另一项重要采购标准。

企业客户很少将 Agent 作为孤立的聊天机器人部署。他们希望 Agent 连接数据库、代码仓库、支持平台、云控制台和内部知识库。

每一项连接都同时带来价值与暴露面。若云服务商让连接变得容易，却提供薄弱的授权控制，便会将运营风险转回客户身上。

AWS 正将 AgentCore Policy 定位为可跨框架和模型复用的执行层。开发者可以将 AgentCore 用于通过多种主流编排框架构建的 Agent。

这种开放性让 AWS 得以主张：即便企业更换模型，安全策略也应保持稳定。组织可以替换一种基础模型，而不必重写每一条权限规则。

Google 也可通过其云身份控制、Model Armor 和资源级权限提出类似主张。它的优势在于与 Google Workspace、Gemini 及广泛的数据平台紧密相连。

Microsoft 则通过 Entra identity、Copilot 和其 Agent 开发技术栈施加压力。市场正演变为一场三方竞争，争夺对 AI 推理与企业执行之间边界的控制权。

对采购方而言，相关的 Amazon Google 问题并不是哪种模型总能拒绝恶意提示词。没有供应商能够可信地承诺，在每一种输入和工具组合下都能完美拒绝。

更好的问题是：当拒绝失效后会发生什么。安全的平台应限制遭入侵 Agent 可使用的工具、记录、参数、目标位置和操作序列。

Amazon Google 安全策略在工具边界相遇

AWS、Google 和 Microsoft 正趋向确定性执行，但它们组织这类执行机制的方式不同。

AWS 将 AgentCore Policy 直接置于网关路径中。每个受覆盖的 Agent 到工具请求，都会在所请求的调用继续前到达策略引擎。

Cedar 为 AWS 提供了一种可供团队检查、验证和分析的正式语言。AWS 已在 Agent 之外使用 Cedar 概念，这有助于将 Agent 授权与成熟的应用安全实践相连接。

该公司的安全研究人员对模型本身作出了直截了当的假设。其 Cedar 安全分析称，组织应在纵深防御设计中将 LLM 视为不受信任的参与者。

这并不意味着模型具有恶意。它意味着授权系统不能依赖可预测的模型行为，因为模型具有概率性，并容易受到被操纵上下文的影响。

Google 已发布的指南目前强调围绕 MCP 服务器和 Google Cloud 资源的分层控制。这些控制包括拒绝策略、范围狭窄的凭证、独立测试环境、经清理的输入以及受限的生产访问。

Google 还建议，除非工作流确有需要，否则应阻止读写工具触及生产资源。恢复能力仍然很重要，因为即使经过授权的操作也可能产生不希望出现的结果。

实际差异可能体现在开发者体验上。AWS 提供专用的 AgentCore 策略引擎，并在其托管网关中通过 Cedar 支持的评估进行控制。

Google 可以利用成熟的 Cloud IAM 和产品专属策略。不过，开发者仍需确保每一条相关工具路径确实都经过预期的控制机制。

这一限制同样适用于 AWS。AgentCore Policy 管控的是通过关联 AgentCore Gateway 路由的流量。若某个 agent 存在另一条执行路径，就可能绕过这一特定检查点。

例如，某项策略可以阻止通过托管 MCP 工具执行的 S3 操作。但该限制不会自动覆盖能够发出等效命令的独立 shell 工具。

因此，架构审查必须枚举实际能力，而不只是列出工具名称。安全团队需要追问：agent 是否能通过 SDK、命令行、浏览器、函数或次级 agent 访问同一资源。

Microsoft 正通过信息流控制开发另一种变体。其 FIDES 中间件会按完整性和保密性为内容打标签，并在工具调用过程中携带这些标签。

Microsoft 的 FIDES security model 可以阻止不可信内容影响敏感操作，也可以限制私有数据流向公开目的地。

这种方法弥补了单一操作授权的弱点。数据库查询或许被允许，发送电子邮件也可能被允许；但当私有查询结果流入外部邮件时，危险行为才真正显现。

AWS 一直在将其策略扩展至具备会话感知能力的评估。时序控制可以审视 agent 最近的操作，而非将每项请求视为孤立事件。

这一方向很重要，因为攻击者可以把有害目标拆分为多个看似合法的步骤。一个操作序列可能揭示风险，而单个操作本身并不会暴露这种风险。

某个 agent 可能先读取一份机密投资组合，再计算摘要，最后尝试向外部发送。在没有将这些操作串联起来时，每次工具调用看起来都可能有效。

对于比较 Amazon 和 Google 安全设计的客户而言，覆盖范围比术语更重要。如果高风险执行路径仍处于强制执行范围之外，正式的策略语言提供的保护也十分有限。

身份传播同样重要。策略引擎需要可靠地了解用户、工作负载、资源、操作及相关业务上下文。

当一个 agent 服务于多名员工时，泛化的“agent”身份并不充分。它可能向每位用户授予该 agent 的最高权限集，并抹去常规访问控制所提供的可追责性。

组织应保留每项委托请求背后的人类用户或工作负载身份。同时，也应为 agent 分配自身受限的身份，而不是将其隐藏在共享凭据中。

这种分离有助于回答两个不同的问题。第一个问题是，用户是否可以请求该操作；第二个问题是，该 agent 是否可以通过这一特定工具执行该操作。

集中式策略也能减少团队之间的不一致。缺少这种机制时，每位开发者都可能在提示词、自定义中间件或单独的工具处理器中实现授权逻辑。

这些分散的检查会变得难以审计。随着 agent 获得新工具、新模型和新的工作流分支，它们也会逐渐偏离一致性。

共享网关无法取代所有资源级权限，但它可以提供一个一致的控制点，让组织在 agent 意图到达下游服务之前应用策略。

策略的强度取决于其覆盖范围

AgentCore Policy 可以降低风险，但它并不能证明托管在 AWS 上的 agent 是安全的。

该服务控制的是经过已配置网关和策略引擎的请求。它无法管控开发者置于该边界之外的工具、凭据或网络路由。

这带来了覆盖范围问题。安全团队可能认为自己已阻止某项危险操作，但另一种工具仍可能提供通往同一资源的替代路径。

宽泛的 IAM 权限会加剧这一缺口。如果 agent 的运行时角色能够直接调用服务，那么网关限制必须与资源策略配合，以阻断未经授权的路径。

策略设计本身依然困难。自然语言编写降低了语法门槛，但无法解决模糊的业务要求或缺失的安全假设。

“允许分析师查看适当的报告”并不是精确的授权规则。组织必须定义哪些分析师、报告、分类、地区、客户和运行条件才算“适当”。

生成的 Cedar 策略需要经过审查、测试和变更控制。团队应测试预期允许、预期拒绝、格式错误的请求、缺失的上下文，以及刻意构造的对抗性参数组合。

拒绝一切的策略会造成运营故障；悄然允许一切的规则则会带来相反的问题。这两种结果在语法上都可能是有效的。

开发者还需要考虑由 agent 提供的授权上下文。安全敏感属性应来自可信身份令牌、资源元数据或受控基础设施。

不应允许模型自行声明某笔交易风险较低，或某份文档属于公开内容。这些说法需要在模型推理过程之外加以验证。

审计日志也带来另一项责任。记录每项决策有助于调查，但团队必须主动监控这些记录，并保留有用的上下文。

一次被拒绝的操作可能表明安全控制成功生效。反复被拒绝也可能暴露工作流已遭入侵、策略存在错误，或 agent 正持续重试某个被禁止的目标。

获准操作同样值得关注。攻击者可以滥用单项来看正当的权限，尤其是在策略不考虑会话历史或数据流动时。

对于不可逆或高影响操作，人工审批依然有用。然而，当 agent 为请求的操作提供误导性描述时，审批界面也可能失效。

界面应展示来自实际工具请求的可信细节。审核者需要看到目的地、资源、参数、数据分类和预期影响。

安全团队还必须保护策略管理平面。agent 不应能够编辑自身规则、关联更弱的策略引擎，或获得访问范围更广的凭据。

职责分离在此很有帮助。开发者可以提出策略变更，而安全负责人则通过受控工作流审查和部署这些变更。

同样的纪律也适用于内部知识系统。构建 可搜索知识库 的团队，应在向 agent 暴露内容之前保留文档权限。

检索应根据请求用户的授权筛选记录。模型只应接收用户本可直接访问的信息子集。

这种设计能够避免一种关键失效模式。即使模型遭到成功操控，它也无法泄露从未进入其可访问上下文的信息。

组织不应将全部信心寄托于提示注入检测。检测能够增加有效防御，但陌生的攻击方式和看似无害的指令仍可能躲过分类器。

AWS 支持在策略层使用 Bedrock Guardrails 来评估网关输入和输出。该功能是对 Cedar 强制执行的补充，而非替代。

区别很直接：护栏会估计内容是否看起来具有危险性，而授权则决定请求的操作是否被允许。

概率式检测与确定性强制执行解决的是不同问题。将二者结合，可以缩小攻击面，而无需假装任一层都能捕获所有失效情况。

Amazon 与 Google 的安全竞赛，将奖励那些让这些层级难以被绕过的供应商。关于安全 agent 的营销说法，远不如可证明的强制执行覆盖范围重要。

客户应通过红队演练测试这些说法，演练应涉及间接注入、受损工具、替代执行路径和多步骤数据流动。

他们还应验证失效行为。被拒绝的工具调用必须停止受保护操作，且不能通过错误信息或回退路径暴露敏感细节。

AWS 通过将策略置于 agent 代码之外，建立了更强的默认模式。剩下的问题是，客户是否会以同等谨慎程度配置周边身份与路由。

企业采购方接下来应关注什么

下一阶段将检验策略覆盖范围、会话感知能力，以及跨竞争性 agent 平台的可移植性。

第一个信号是客户采用时序策略的速度。单请求规则非常适合明确限制，但许多 agent 攻击是通过一系列已获授权的操作浮现的。

时序评估可以检测 agent 在尝试外部传输前是否读取过敏感数据，也可以在特定操作序列发生后要求额外审批。

困难之处在于状态管理和解释。系统必须追踪足够的历史信息，以识别危险轨迹，同时又不能阻塞正常工作流或引入过高延迟。

采购方应寻找公开技术文档，了解究竟会评估多少会话历史。他们还应询问状态如何在不同用户、agent 和并发任务之间隔离。

第二个信号是 Google 和 Microsoft 如何通过其托管 agent 平台暴露等效控制。三家提供商都认识到，仅靠提示词指令无法保护已连接的系统。

Google 的回应将十分重要，因为 Gemini agents 可以紧密连接 Workspace 内容、云数据和开发者基础设施。强大的资源权限已经存在，但面向 agent 的组合能力仍不可或缺。

Microsoft 可以将 Entra identity 与 Copilot、Agent Framework 和信息流标签结合起来。其优势将取决于能否在 Microsoft 工具和第三方工具之间实现一致的强制执行。

Amazon 与 Google 的比较应聚焦端到端路径。采购方需要证据证明，策略会从用户身份出发，经由 agent 推理、网关执行，直至最终资源访问，全程跟随操作。

第三个信号是独立安全测试。供应商文档描述的是预期行为，而红队会揭示遗漏路径、身份混淆、不安全的默认设置和意料之外的工具组合。

测试应包括恶意网页、被投毒的支持工单、受损的 MCP 响应，以及获批存储库中的恶意文档。每一种来源都可能将间接指令带入 agent 的上下文。

研究人员还应测试，agent 是否能够将被禁止的请求转化为技术上不同的操作。被阻止的导出可能变成浏览器上传、shell 命令、编码消息，或向另一个 agent 发出的请求。

结果将决定外部策略究竟能否形成有意义的遏制，还是仅仅增加一层配置。最有力的证据将来自那些改变模型行为、但仍无法跨越授权边界的攻击。

企业无需等待这些结果才改善其架构。他们可以从清点每个 agent、工具、凭据、数据源和出站目的地开始。

每个工具都应获得尽可能狭窄的操作范围。只读访问应与修改、删除、外部共享或财务执行保持分离。

在短期委托可行时，团队应移除长期有效凭据。他们应在工具调用间保留用户身份，并记录尝试过和已完成的操作。

高影响操作应要求可信的审批上下文。安全团队应定期测试通往受保护资源的替代路径，而非只验证预期的网关路由。

对于 Amazon、Google 的云端决策而言，仅比较模型基准测试已远远不够。采购方还应比较默认拒绝行为、身份传递、策略分析、审计细节、会话控制和执行覆盖范围。

他们还应询问：当模型和框架发生变化时，策略如何延续。与某一种 Agent 实现紧密绑定的授权机制，迁移期间维护成本高，也更容易被绕过。

AWS 已作出明确的架构押注。它假定 Agent 的推理过程仍可能被操控，因此通过 Agent 外部的确定性控制措施来限制后果。

这一假设比承诺模型会完美服从更可信。它承认错误和攻击终将发生，同时为工具和数据保留独立的授权控制权。

这种方法仍依赖严格的配置管理。狭窄的网关策略无法弥补权限过大的运行时、未受管理的 Shell，或在授权过滤前就已被检索的数据。

企业团队现在应端到端测试一项具体工作流：操控 Agent，观察其请求执行的操作，并确认受保护的操作会在外部边界被拒绝。

这项测试为 Amazon、Google 及其他所有 Agent 平台提供了一个实用标准：模型可以被欺骗，但基础设施仍必须说“不”。