Amazon AWS 重新思考 Bedrock Guardrails：以基于风险的检查取代持续代码扫描

Amazon AWS 发布了七项实践建议，帮助团队在使用 Bedrock Guardrails 时，避免让反复的安全检查压垮代码生成工作流。

该指南回应了一个在编程助手超越小规模试点后逐渐显现的矛盾。持续扫描能提供广泛覆盖，但较长的输出和并发的代理会话会迅速耗尽可用的护栏容量。

AWS 现在建议，应在内容跨越信任边界时进行检查，而不是评估每一段中间内容。这些边界包括用户输入、完成的代码、危险的工具调用、文件写入和仓库提交。

这一变化的影响不止于 Bedrock。Claude Code、Kiro、OpenAI Codex 以及其他编程代理正越来越多地通过长时间、多步骤的会话开展工作。它们的行为已不像一次简短的聊天机器人交互。

这一新蓝图将安全验证视作 pre-commit hook。团队仍会在代码变为持久内容或可执行内容之前进行检查，但避免反复审查未变化的上下文和临时推理。

其中的权衡十分明确。选择性评估可以降低延迟、配额压力和重复工作量，但也要求工程团队承担更多责任，识别每一个有实质意义的信任边界。

Amazon AWS 瞄准了小规模试点掩盖的扩展难题

核心变化在于架构：AWS 希望开发者将护栏部署在会产生实际后果的操作周围，而不是围绕生成过程中的每一个 token。

AWS 于 2026 年 7 月 23 日发布了这些建议。该公司将其描述为对编程助手和代理式开发工作流所产生的特殊吞吐模式的回应。

一段简短的对话回复可能仅包含几百个字符。AWS 表示，代码生成一次输出可能产生 5,000 到超过 50,000 个字符。

编程会话还会复用系统提示、工具定义、此前消息和现有代码。内联护栏可能会在每一轮交互中重新评估其中大量未变化的内容。

这种重复在试点期间很容易被忽视。两名开发者偶尔发起请求，可能永远不会触及配额边界，也察觉不到轻微的延迟增加。

AWS 以一个场景说明这一问题：15 名开发者通过 Amazon Bedrock 使用 Claude Code，每个生成的函数大约包含 5,000 个字符。

根据 AWS 指南 所述的默认流式配置，护栏每 50 个字符评估一次输出。这意味着每个函数会产生 100 次评估。

如果 15 名开发者同时生成代码，该场景将达到 1,500 次评估请求。配置的三项安全措施还会使相关文本单元消耗成倍增加。

一个文本单元代表由一种策略类型评估的 1,000 个字符。因此，针对三种不同安全措施处理 1,000 个字符，会消耗三个文本单元。

内容过滤类别的计算方式不同。在同一个内容过滤策略中启用多个类别，对于每个 1,000 字符区块仍只计为一个策略单元。

倍增发生在策略类型之间，例如内容过滤器、禁止主题和敏感信息过滤器之间，而不会发生在单个过滤器内的每一种类别之间。

这一区别使护栏设计成为一项容量规划工作。输出长度、评估频率、并发会话数和启用的策略类型，都会影响最终负载。

AWS 表示，这个假设团队在扩大部署后遇到了 ThrottlingException 响应。代码补全随后在流式传输期间停滞，尽管较小规模的试点看似运行良好。

该示例用于说明问题，并非已发布的客户案例研究。不过，其中的计算表明，某种配置可以通过功能测试，却仍可能在真实并发条件下失效。

内联扫描通过 Converse 或 InvokeModel 等 API，直接将护栏附加到模型推理过程。Bedrock 随后会将输入和流式输出作为该次调用的一部分进行评估。

当应用需要在任何输出到达用户前立即完成审核时，这一模式仍然有用。但当代理会产生大量临时工作时，它的效率会下降。

代码代理可能会检查文件、推理不同方案、修改函数并丢弃早期草稿。扫描每一种中间状态并不一定能改善最终产物。

因此，AWS 按照后果对生成内容进行划分。临时推理具有一种风险特征，而进入代码仓库的代码则具有另一种。

该提案并未取消安全检查，而是将全面评估移至内容可能影响数据、基础设施、用户或生产系统的位置附近。

这一转变构成了本文的核心张力。降低评估频率可以让护栏在大规模条件下持续运行，但前提是团队能正确划分具有实际后果的操作。

为什么编程助手会给护栏容量带来压力

编程助手会给安全系统带来压力，因为它们在同一工作负载中结合了冗长输出、重复上下文、并发和自主操作。

传统聊天机器人的护栏通常假设交互较为紧凑：用户发送提示，模型返回答案，双方都只接受有限次数的检查。

编程助手则维持更长的会话。它可能读取一个代码仓库、生成多个候选修改、运行测试、修订文件并准备提交。

代理式工作流会增加更多中间步骤。代理循环是指模型进行推理、调用工具、观察结果并决定下一步行动的一系列过程。

AWS 表示，这样的循环可能在生成最终代码之前包含五到十个推理步骤。评估每一个步骤，可能会将容量消耗在几分钟后就会消失的内容上。

重复上下文同样重要。系统指令和工具模式可能很大，但通常在整个会话中保持不变。

基础的内联配置可能会在每次新请求中重新扫描这些指令，也可能重复评估此前护栏调用已经检查过的对话历史。

这种模式会产生冗余工作。即使大部分文本没有提供新信息，安全容量仍会随着处理文本量的增加而消耗。

流式传输让这种不匹配更加明显。以每 50 个字符一次的间隔计算，一个 5,000 字符的函数会产生 100 次评估事件。

AWS 建议，当流式检查仍有必要时，将间隔提高到 1,000 个字符。同一个函数将从 100 次评估降至 5 次。

一个 50,000 字符的文件则会从 1,000 次评估降至 50 次。AWS 将这一配置调整描述为最多可将评估频率降低 20 倍。

这并不自动意味着总成本或延迟也降低 20 倍。实际结果取决于启用的策略、内容长度、区域配额和应用行为。

不过，这一频率变化揭示了更广泛的设计问题。一次包含 600 个字符的评估，与一次包含 1,000 个字符的评估一样，都会消耗完整的文本单元边界。

因此，小型内容块可能会浪费未利用的容量。将内容批处理到接近 1,000 字符边界，可让每个计费或计入配额的单元承载更多有用内容。

并发会进一步放大这种影响。开发者通常会在相近时间开始工作，而自动化代理则可能持续在多个代码仓库中运行。

一个对单名开发者表现良好的工作流，可能在团队范围内形成集中的突发流量。这些突发流量会与模型推理及其他应用流量竞争资源。

这会以不同方式影响平台团队、安全工程师和开发者。平台团队必须预测容量，安全团队则必须保留有意义的覆盖范围。

开发者会通过补全延迟或会话失败感受到后果。如果安全层经常中断正常编程，他们也可能寻求绕过方法。

AWS 实际上是在要求这些群体停止将护栏视为单一开关。正确的配置取决于每个阶段的内容、操作和后果。

这一论点也给编程助手供应商带来压力。它们需要提供可观察的工具边界，以及客户能够插入策略检查的可靠钩子。

隐藏中间操作的封闭式助手，会使基于风险的评估更加困难。具备明确文件、shell、部署和网络工具的平台则提供了更清晰的控制点。

这一转变也会影响组织记忆。团队必须记录每一个检查点存在的原因，以及适用哪些策略。

可搜索的工程知识库可以将这些决策与架构说明、威胁模型和事件发现一同保存。

没有这些记录，后续优化可能会移除某项用途已不再明显的检查。护栏架构需要像应用代码一样具备明确的所有权、版本控制和审查机制。

Bedrock Guardrails 策略将检查移至信任边界

当评估遵循信任转换进行，尤其是在内容变为持久内容或可执行内容之前时，Amazon Bedrock Guardrails 最适合代码生成场景。

AWS 确定了三个主要检查点。团队可以验证新的用户输入、检查完成的代码产物，并在保存或提交更改前再进行一次检查。

第一个检查点保护模型免受不可信指令影响。它可以在推理开始前检测提示攻击、被禁止的请求和敏感信息。

第二个检查点审查已组装完成的输出。它有助于发现凭据、个人信息、禁止主题或违反组织规则的内容。

第三个检查点的作用类似于 Git pre-commit hook。当代码即将进入共享仓库或变得可执行时，它会对代码进行评估。

这种安排与既有的软件保障实践类似。开发者不会在每输入一个字符后都运行所有 linter 和安全扫描器。

他们会在编辑期间运行轻量级检查，然后在提交、构建、审查和部署阶段应用更广泛的验证。每个阶段都让投入与后果相匹配。

AWS 建议在这一架构中使用独立的 ApplyGuardrail API。该 API 会根据已配置的护栏评估文本，而不调用基础模型。

根据 ApplyGuardrail 文档，调用方会将内容标记为 INPUT 或 OUTPUT。这一标记告诉 Bedrock 正在评估工作流的哪一侧。

团队可以仅将最新的用户消息作为 INPUT 进行验证，然后在无需将静态上下文重新发送给同一护栏的情况下运行模型推理。

生成之后，团队可以将完成的产物作为 OUTPUT 提交。这一设计将安全评估与模型推理的时间安排及提供方分离开来。

这种解耦还意味着 Guardrails 可以评估由 Amazon Bedrock 之外生成的文本。AWS 表示，独立 API 不依赖所选的基础模型。

这种灵活性对同时使用多种编码助手的组织而言至关重要。共享的策略层可以覆盖不同模型的输出，而无需采用完全相同的推理集成方式。

AWS 还建议对未变更的文件使用基于哈希的缓存。加密哈希充当紧凑的指纹，使应用能够识别已通过验证的内容。

如果文件未发生变化，工作流将跳过再次评估。已修改的文件会获得新的哈希值，并返回相应的检查点。

缓存必须始终绑定到确切的护栏版本和策略配置。根据旧版策略获批的文件，不应在规则变更后悄然继承批准状态。

风险分类提供了另一层保障。AWS 建议对 IAM 策略、凭证处理代码、数据库迁移和身份验证逻辑进行更深入的评估。

简单的用户界面组件在生成过程中可接受较轻量的处理，随后在提交前进行全面检查。该产物仍须经过最终关卡。

危险的代理工具同样值得重点关注。文件写入、Shell 执行、基础设施变更和部署操作都可能立即产生后果。

只读搜索或语法高亮通常带来的直接风险较低。团队可以将其内容推迟到后续的产物级评估中处理。

这是 AWS 提案中最有力的部分。它将安全投入映射到一个关于信任、持久化和执行的明确模型上。

它也呼应了最小权限设计。代理应只获得完成当前任务所需的权限，而高风险操作则触发更严格的检查和审批。

敏感信息过滤器可以阻止或掩盖已识别的个人数据。自定义正则表达式可以定位组织特有的机密、标识符或凭证格式。

被禁止的主题可以中止涉及违规活动的请求。内容过滤器可以识别不当行为、暴力或提示攻击等类别。

这些控制措施不能取代传统的代码安全机制。护栏或许能检测到暴露的密钥，但它并不是完整的静态分析器或依赖扫描器。

团队仍需要代码审查、密钥扫描、软件成分分析、测试、沙箱和部署策略。每种控制措施捕捉的故障类别各不相同。

因此，最佳设计是将 Bedrock Guardrails 与现有工程控制措施分层结合。它并不要求单一的概率性过滤器来认证一个应用是否安全。

选择性评估带来新的安全权衡

将检查从连续流中移开可以减少浪费，但也会提高漏掉检查点或错误分类风险的代价。

AWS 将中间推理描述为通常不会跨越信任边界的短暂内容。跳过这类内容可以消除许多低价值的评估。

然而，并非每个中间操作都是无害的。代理可能在生成最终答案前执行 Shell 命令、发送网络请求或修改文件。

只检查最终响应的工作流可能会遗漏先前造成的损害。因此，正确的分析单位应是操作，而不只是可见输出。

团队必须在执行前拦截危险的工具调用。当代理已经获得生产凭证时，不应等到最终代码产物出现才采取措施。

这一要求使工具插桩变得必不可少。每个工具都需要定义风险级别、允许的参数、权限范围、日志策略和失败行为。

护栏响应同样需要执行路径。如果应用仍以同样的文件写入或命令继续运行，检测到干预并没有太大意义。

当评估超时或返回错误时，应用应默认进入安全状态。正确的回退方式取决于操作的潜在影响。

延迟的用户界面建议可以继续进入后续检查。而生产部署或身份策略变更通常应在评估成功前停止。

误报也会带来另一项担忧。生成的代码天然包含可能类似凭证、攻击指令或被禁止活动的词语、字符串和示例。

安全软件可能包含用于防御性测试的漏洞利用描述。身份验证代码必然会讨论访问控制、令牌和绕过防护能力。

自定义过滤器需要针对具有代表性的代码仓库进行测试。团队应衡量干预率、开发者覆盖操作、漏检情况和审查结果。

AWS 建议进行容量规划，但同样的严谨性也应覆盖策略质量。较低的请求量并不保证作出更好的安全决策。

该公司的数值示例也需要谨慎解读。15 名开发者的场景展示的是架构行为，而非已观察到的客户性能报告。

20 倍的改进涉及将间隔从 50 个字符调整为 1,000 个字符时的评估频率。它并非通用的性能保证。

区域服务配额可能不同，账户分配也可能发生变化。AWS 建议客户检查实际限制，而不是假定已公布的默认值适用。

策略消耗在已配置的各类防护措施之间仍然呈乘法关系。更大的流式传输间隔可降低调用频率，但全面检查仍会处理所选内容。

选择性评估还可能造成可见性缺口。安全团队可能失去对从未进入提交阶段的问题中间生成内容的详细记录。

为了隐私和效率，这种损失可能是可以接受的。但在代理出现意外行为后，它也可能限制取证分析。

组织应决定保留哪些中间元数据，同时避免存储私密的思维链内容。工具请求、策略决策和产物哈希可提供更安全的审计信号。

Guardrails 文档描述了多种策略组件，但组织仍需自行定义可接受使用的边界。Bedrock 无法推断每一家公司的特定风险。

正式策略检查同样存在局限。Amazon Bedrock 提供自动推理功能，用于根据已定义的规则验证自然语言声明。

推理检查使用形式逻辑返回结构化发现。处于策略定义范围之外的陈述仍不会得到验证。

上下文基础检查解决的是另一类问题。它们将响应与所提供的源材料进行比较，并评估其与用户查询的相关性。

AWS 指出，基础性检查面向摘要、改写和问答等任务。它们并不是通用的代码正确性测试。

这些机制均无法证明生成的代码安全、正确或可维护。它们只是根据配置的策略和支持的检测方法评估内容。

这一边界应在内部文档中保持明确。否则，“已通过护栏”可能成为安全审查的误导性替代品。

更深层的教训是，安全覆盖有两个维度。团队既需要合适的策略，也必须在每一次产生实质后果的转换之前调用这些策略。

持续扫描让人更容易想当然地认为第二个条件已经满足。选择性扫描则要求对其进行工程化设计和验证。

Amazon AWS 客户接下来应关注什么

只有当真实部署既能减少限流事件，又不让危险的代理操作逃避评估时，这一蓝图才能成功。

第一个信号是来自更大规模编码助手部署的运营数据。团队应按检查点追踪护栏调用、文本单位、延迟、限流和干预率。

成功的部署应减少重复评估，同时在文件写入、提交、命令和部署环节维持或提高检测能力。

如果限流下降但未经审查的操作增加，说明该架构优化了错误的目标。容量和安全指标必须出现在同一个仪表板上。

第二个信号是编码代理与策略检查点之间更强的集成。供应商需要在工具、产物、代码仓库操作和执行环境周围提供明确的钩子。

清晰的钩子将强化 AWS 的信任边界模型。隐藏或不一致的代理操作会削弱它，因为客户无法可靠地部署检查。

模型提供商还需要披露哪些内容会变得可见、持久化或可执行。这些状态决定了评估是否可以安全地延后。

第三个信号是关于代码特定场景下策略准确性的证据。组织需要公开测试结果，覆盖机密、基础设施代码、身份验证变更和防御性安全工作。

仅有干预计数并不足够。团队应审视真阳性、误报、覆盖操作、逃逸缺陷，以及下游扫描器发现的事件。

这些发现可以指导风险分层。IAM 策略可能接受所有已配置的防护措施，而普通展示代码则等待产物级审查。

该蓝图还需要定期进行负载测试。两人的试点无法揭示一个部门同时启动代理会话时的突发行为。

团队应模拟真实的输出规模、多步骤工具使用和重复上下文。还应测试护栏调用和模型推理中的故障。

每个检查点都需要针对 GUARDRAIL_INTERVENED、限流、访问拒绝、超时和格式错误内容定义响应。未定义的错误往往会变成宽松的错误。

配置变更也应受到同等控制。护栏版本、过滤阈值、自定义表达式和工具分类应经过审查和分阶段发布。

开发者可以通过让威胁模型和评估结果贴近实施决策来支持这一流程。个人知识系统可以帮助连接分散的规范、事件和测试发现。

Amazon AWS 已识别出一个真实的扩展失配问题。代码代理产生了过多重复、临时的材料，使短对话式安全模式难以继续高效运行。

其提出的解决方案并非默认降低覆盖范围，而是在内容获得实质影响的时刻集中提供覆盖。

这一区别将决定团队能否负责任地采用该模型。只有当危险操作仍受到单独保护时，跳过中间推理才是合理的。

在更改 Bedrock 配置之前，团队应绘制从提示到持久化或可执行操作的每一条路径。随后，他们应分配策略、负责人和失败模式。

接下来，他们可以在仍需立即扫描输出的情况下测试 1,000 个字符的流式传输间隔。他们可以将这一设计与解耦的输入和产物检查进行比较。

最后，他们应在真实并发条件下验证系统。重要的问题并不是护栏能否在一次请求中正常工作。

问题在于，Amazon AWS Guardrails 能否支撑全团队范围的编码工作流，同时阻止最重要的操作。