本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 政策中的护栏 本节介绍如何在策略中设置护栏，以便政策的决策取决于请求或响应内容是否包含不安全的材料。内容检查本身由*护栏*执行，Policy 在评估期间会 AgentCore 调用该护栏。如今，护栏由 A [mazon Bedro](https://docs.amazonaws.cn/bedrock/latest/userguide/guardrails.html) ck Guardrails 提供支持。 **护栏状况列举了三件事：**护栏类型、该类型**应评估的**类别**以及要评估的内容。**护栏会返回信心分数，您的保单决定如何处理它。 如果您不熟悉政策中的护栏，请从护[栏入门开始，这将引](policy-guardrails-getting-started.md)导您完成从头到尾的创建过程。有关涵盖 MCP、运行时和每个推理 API 的策略示例，请参阅 [Guardra](example-policies-guardrails.md) il 策略示例。 **Topics** + [护栏状况的基石](#guardrail-building-blocks) + [护栏的区域可用性](#guardrails-regional-availability) + [开始前的准备工作](#policy-guardrails-before-you-begin) + [在政策中写护栏](#defining-guardrails-in-policies) + [保单中的护栏是如何运作的](#how-guardrails-works-with-policy) + [限制](#guardrails-in-policy-limitations) + [护栏入门](policy-guardrails-getting-started.md) ## 护栏状况的基石 中的策略 AgentCore 支持三种护栏类型。每个类别都采用一组类别进行评估，并以不同的方式返回其结果。 `ContentFilter` Harmful-content 类别，例如`VIOLENCE`或`HATE`。返回您命名的每个类别的置信度分数，无论内容是否表现出来。 `PromptAttack` Prompt-manipulation 类别，例如`JAILBREAK`或`PROMPT_INJECTION`。返回您命名的每个类别的置信度分数。 `SensitiveInformation` 敏感实体，例如`EMAIL`或`US_SOCIAL_SECURITY_NUMBER`。返回每个找到的实体的检测结果，而不是每个类别的分数，因此它没有每个类别的分数，需要聚合。 有关每种类型接受的类别，请参阅[支持的护栏](#supported-guardrails)。有关要评估的内容，请参阅[将上下文传递给护栏](#passing-context-to-your-guardrail)。 置信度分数是介于 0 到 1 之间的小数，表示内容表现出评估属性的强度。您决定如何处理该分数，保单将您的决定作为护栏结果的条件——通常是阈值比较，例如。`.confidenceScore.greaterThan(decimal("0.4"))`有关阈值和比较运算符，[请参阅护栏阈值](#thresholds-for-guardrails)。 也可以降低各类别的分数，而不是逐个进行比较。*聚合*是这样做的：`maxConfidenceScore()``minConfidenceScore()`返回分数，同时`count()`返回检测到的数量并`categories()`返回检测到的类别集，因此这两个类别不需要阈值。有关完整列表，请参阅[聚合。](#guardrail-aggregations) ## 护栏的区域可用性 下表显示了哪些 Amazon 地区支持策略中的护栏。 | 区域名称 | 政策中的护栏 | | --- | --- | | 美国东部（弗吉尼亚州北部） | ✓ 是的 | | 美国东部（俄亥俄州） | ✓ 是的 | | 美国西部（北加利福尼亚） | 否 | | 美国西部（俄勒冈州） | ✓ 是的 | | 亚太地区（海得拉巴） | 否 | | 亚太地区（马来西亚） | 否 | | 亚太地区（孟买） | 否 | | 亚太地区（首尔） | 否 | | 亚太地区（新加坡） | 否 | | 亚太地区（悉尼） | ✓ 是的 | | 亚太地区（泰国） | 否 | | 亚太地区（东京） | ✓ 是的 | | 加拿大（中部） | 否 | | 欧洲地区（法兰克福） | 否 | | 欧洲地区（爱尔兰） | 否 | | 欧洲地区（伦敦） | ✓ 是的 | | 欧洲地区（米兰） | 否 | | 欧洲地区（巴黎） | 否 | | 欧洲（西班牙） | 否 | | 欧洲地区（斯德哥尔摩） | ✓ 是的 | | 南美洲（圣保罗） | 否 | | Amazon GovCloud (US-West) | 否 | ## 开始前的准备工作 在开始之前，您需要正确配置您的 IAM 角色。 ### Permissions 除了网关已经拥有的 AgentCore 权限`bedrock:InvokeGuardrailChecks`外，还需要网关的执行角色。有关后者，请参阅 [ AgentCore IAM 权限中的AgentCore 网关和策略](policy-permissions.md)。 中的策略 AgentCore 使用从网关的执行角色派生[的前向访问会话 (FAS)](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_forward_access_sessions.html) 凭据代表您调用 Bedrock Guardrails API，这就是该权限属于该角色的原因。 ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "bedrock:InvokeGuardrailChecks", "Resource": "arn:aws:bedrock:us-west-2:123456789012:guardrail/abc123" } ] } ``` ### 支撑的护栏 - ** 内容筛选条件 ** - **实体类型:** `ContentFilter` - **类别:** `VIOLENCE`, `HATE`, `SEXUAL`, `MISCONDUCT`, `INSULTS` - ** 即时攻击检测 ** - **实体类型:** `PromptAttack` - **类别:** `JAILBREAK`, `PROMPT_INJECTION`, `PROMPT_LEAKAGE` - ** 敏感信息 ** - **实体类型:** `SensitiveInformation` - **类别:** - **个人身份** — `ADDRESS` `AGE`、`NAME`、、`EMAIL`、`PHONE`、`USERNAME`、`PASSWORD`、`PIN`、`DRIVER_ID`、`LICENSE_PLATE`、`VEHICLE_IDENTIFICATION_NUMBER` - **财务** — `CREDIT_DEBIT_CARD_NUMBER` `CREDIT_DEBIT_CARD_CVV`、`CREDIT_DEBIT_CARD_EXPIRY`、`US_BANK_ACCOUNT_NUMBER`、`US_BANK_ROUTING_NUMBER`、`INTERNATIONAL_BANK_ACCOUNT_NUMBER`、`SWIFT_CODE` - **政府和健康标识符** — `US_SOCIAL_SECURITY_NUMBER` `US_PASSPORT_NUMBER`、`US_INDIVIDUAL_TAX_IDENTIFICATION_NUMBER`、`CA_SOCIAL_INSURANCE_NUMBER`、`CA_HEALTH_NUMBER`、`UK_NATIONAL_INSURANCE_NUMBER`、`UK_NATIONAL_HEALTH_SERVICE_NUMBER`、`UK_UNIQUE_TAXPAYER_REFERENCE_NUMBER` - **凭据和网络** — `AWS_ACCESS_KEY`、`AWS_SECRET_KEY`、`IP_ADDRESS`、`MAC_ADDRESS`、`URL` **注意** 此表是 Policy in 支持的护栏和类别的当前列表。 AgentCore 创建策略时，该类别之外的类别无法通过验证。特别是，没有`ACCOUNT_NUMBER`类别——使用`US_BANK_ACCOUNT_NUMBER`或`INTERNATIONAL_BANK_ACCOUNT_NUMBER`。 ## 在政策中写护栏 要在政策中设置护栏，您可以将策略编写为代码，也可以用自然语言进行描述。与其他策略一样，使用条件 (`when guardrails`) 指定效果`permit`，例如。在条件中，提供要启用的护栏、要评估的类别、要评估的内容以及你想要的分数比较。 **护栏定义示例** ``` suppressOutput (principal, action == AgentCore::Action::"___:", resource == AgentCore::Gateway::"") when guardrails { BedrockGuardrails::ContentFilter(["HATE"],[context.output.message])["HATE"] .confidenceScore .greaterThan(decimal("0.2")) }; ``` **注意** `suppressOutput`在工具生成结果后运行，并隐瞒调用者的响应。该工具仍在运行；只有响应被抑制。 `suppressOutput`仅适用于护栏条件。其状况必须仅包括护栏检查。将这些支票写成`when guardrails {…​}`方块或普通`when {…​}`方块。 `suppressOutput`不支持标准 Cedar 或`temporal {…​}`条件。 请注意将目标名称与方法和 URI 分开的三个下划线。有关针对完整参考网关的示例，请参阅 G [uardrail 策略](example-policies-guardrails.md)示例。 ### 创建带有护栏的政策 要创建策略，请将声明放在`definition`属性的`policy`字段中。有关更多信息，请参阅[创建策略](policy-create-policies.md)。否则，它会像任何其他策略一样创建。 **Example** 交互式向导是添加护栏的最简单方法，因为它可以为您构建声明。 1. 在没有旗帜的情况下运行`agentcore add policy`： ``` agentcore add policy ``` 向导会提示输入网关、目标、引擎和策略名称。选择护栏表单作为来源，然后它会提示您输入效果、护栏类别、过滤器和数据路径，并向您显示它在创建之前构建的语句。 1. 部署项目： ``` agentcore deploy --yes ``` 要以非交互方式编写相同内容的脚本，请传递表单标志 — `--form-category`、`--form-filters``--form-effect`、和。`--form-data-path`提供其中任何一个都会跳过向导。要提供自己写的语句，请将其保存到文件中并传递`--source`： ``` agentcore add policy --name BlockViolentReason \ --engine my_policy_engine \ --source block_violent_reason.dw \ --validation-mode IGNORE_ALL_FINDINGS ``` 有关更多信息，请参阅[护栏入门](policy-guardrails-getting-started.md)。 1. 在终端中运行以下 Amazon CLI 命令来创建策略： ``` aws bedrock-agentcore-control create-policy \ --policy-engine-id my_policy_engine-a1b2c3d4e5 \ --name BlockViolentReason \ --validation-mode IGNORE_ALL_FINDINGS \ --definition '{ "policy": { "statement": "forbid (principal, action == AgentCore::Action::\"RefundTool___process_refund\", resource == AgentCore::Gateway::\"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway-a1b2c3d4e5\") when guardrails { BedrockGuardrails::ContentFilter([\"VIOLENCE\"], [context.input.reason])[\"VIOLENCE\"].confidenceScore.greaterThan(decimal(\"0.4\")) };" } }' ``` 1. 运行以下 Python 代码，使用适用于 Python 的 Amazon 软件开发工具包创建策略： ``` import boto3 client = boto3.client("bedrock-agentcore-control") GATEWAY_ARN = "arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway-a1b2c3d4e5" statement = ( 'forbid (principal, ' 'action == AgentCore::Action::"RefundTool___process_refund", ' f'resource == AgentCore::Gateway::"{GATEWAY_ARN}") ' 'when guardrails { ' 'BedrockGuardrails::ContentFilter(["VIOLENCE"], [context.input.reason])["VIOLENCE"]' '.confidenceScore.greaterThan(decimal("0.4")) };' ) response = client.create_policy( policyEngineId="my_policy_engine-a1b2c3d4e5", name="BlockViolentReason", validationMode="IGNORE_ALL_FINDINGS", definition={"policy": {"statement": statement}}, ) # CreatePolicy returns 202 - wait for the terminal status client.get_waiter("policy_active").wait( policyEngineId="my_policy_engine-a1b2c3d4e5", policyId=response["policyId"], ) print(response["policyId"]) ``` 无论使用哪种曲面，都最好使用反向比较将规则表示`permit`为 a。默认情况下，策略评估是拒绝的，因此只有在分数保持较低时`permit`才保持的单一策略既可以授予操作又可以对其进行门禁： ``` permit (principal, action == AgentCore::Action::"RefundTool___process_refund", resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway-a1b2c3d4e5") when guardrails { BedrockGuardrails::ContentFilter(["VIOLENCE"], [context.input.reason])["VIOLENCE"] .confidenceScore.lessThanOrEqual(decimal("0.4")) }; ``` `forbid`当你想限制已经存在的权限时使用，比如其他一些策略允许的操作，比如限制其输入值。A `forbid` 优先于 any`permit`，因此它会从现有补助金中减去。就其本身`permit`而言，它一无所获：默认情况下，该动作会被拒绝，并且从不咨询护栏，因此孤独者`forbid`需要同伴才能执行相同的动作。 **重要** 策略验证会分析引擎中设置的整个策略，它无法解释护栏状况。因此，`forbid`唯一的大门是护栏的A看起来是无条件的，因此，如果引擎中没有其他东西允许该主体、动作和资源，则该集合将被报告为**过于严**格:. `Overly Restrictive: Policy Engine will deny every request for the specified principal (…​), action (…​) and resource (…​) combination if the policy is added or updated` 在默认情况下，`--validation-mode FAIL_ON_ANY_FINDINGS`该保单被拒绝。无论如何都`--validation-mode IGNORE_ALL_FINDINGS`要通过创建它。 由于结果是策略集的属性，而不是任何一个语句的属性，因此您是否看到它取决于引擎已经拥有的内容。 拒绝是异步的。通话返回 202`CREATING`，然后保单以中的原因结清`statusReasons`，因此请对终端状态进行民意调查，而不是将 `CREATE_FAILED` 202 视为成功。 有关改用 AgentCore CLI 的端到端演练，请参阅[护栏入门](policy-guardrails-getting-started.md)。有关每种目标类型的声明，请参阅 [Guardrail 策略示例](example-policies-guardrails.md)。 ### 指定护栏类型 要选择特定的护栏类型，请使用命名空间： BedrockGuardrails | 护栏类型 | 护栏功能名称 | | --- | --- | | 内容过滤器 | `BedrockGuardrails::ContentFilter` | | 即时攻击 | `BedrockGuardrails::PromptAttack` | | 敏感信息 | `BedrockGuardrails::SensitiveInformation` | ### 选择护栏类别 为所选护栏类型选择一个类别（请参阅[支撑的护栏](#supported-guardrails)）。 例如：`BedrockGuardrails::ContentFilter(["HATE"],[context.output.message])` ### 对护栏的影响 要对护栏上的授权请求进行门禁，请使用`permit`和效果。`forbid`它们继续控制请求授权。 ``` forbid (principal, action == AgentCore::Action::"___POST:/invocations", resource == AgentCore::Gateway::"") when guardrails { BedrockGuardrails::PromptAttack(["PROMPT_INJECTION"], [context.input.prompt])["PROMPT_INJECTION"].confidenceScore.greaterThan(decimal("0.6")) }; ``` 要抑制工具、代理或模型的输出，请使用该`suppressOutput`效果。 `suppressOutput`对操作返回的数据进行操作。授权操作完成后，它会对照护栏评估输出，并在违反护栏时抑制输出。 ``` suppressOutput (principal, action == AgentCore::Action::"___POST:/invocations", resource == AgentCore::Gateway::"") when guardrails { BedrockGuardrails::SensitiveInformation(["US_SOCIAL_SECURITY_NUMBER"], [context.output.text]) .count() > 0 }; ``` **重要** 有两条规则限制了护栏可以读取请求的哪一边，这两条规则都是在您创建策略时强制执行的。 授权效果—— `permit` 或 `forbid` ——可能只读`context.input.*`路径。`suppressOutput`效果可能是只读`context.output.*`路径。`context.output`与`permit`或一起使用`forbid`会被拒绝`Guardrail '' references 'context.output' but the policy has an authorization effect`。 单个护栏呼叫不能混合`context.input.*``context.output.*`路径；一次通话中的每条路径都必须位于同一侧。要筛选请求及其响应，请在同一个`suppressOutput`策略中编写**两个护栏调用**，每侧一个。限制是针对每个通话，而不是按策略进行的。 由于策略命名了特定的操作，因此它还必须使用命名特定的网关 ARN。`resource ==`拒绝让资源不受约束。有关更多信息，请参阅[资源特异性要求。](policy-scope.md#policy-resource-specificity) ### 将上下文传递给您的护栏 在护栏条件下，指定数据路径，例如`context.input.message`，用于标识要从操作的有效载荷中提取的值。护栏评估提取的值。您可以根据请求或响应架构指定一个或多个路径。 例如：`[context.input.message, context.input.systemPrompt]` 您可以通过以下两种方式之一提供数据路径： **字段路径** — `context.input.` 或 `context.output.` 当您想要的值是单个字符串（例如工具参数或请求正文的标量字段）时，请使用此选项。字段路径必须解析为字符串；创建策略时，将字段路径指向对象或列表将被拒绝。 **一个 jsonPath** — 一个以开头的字符串文字 `$` 当文本**位于**列表或字段路径无法到达的对象（对话或内容块列表）中时，请使用此选项。以有效载荷为根编写，不带`context.input.`前缀：例如`"$.messages[*].content"`。JSONPath 作为查询进行评估，因此通配符可以匹配许多值，包括嵌套在不同深度的值。这些匹配项被扁平化为单个文本序列，而不是作为列表保存。 您可以为每个呼叫提供多个数据路径。每个路径都是独立提取的，并作为自己的内容块发送到护栏，因此，要将列表评估为不同的项目，请使用单独的路径而不是一个通配符路径来命名这些项目。 **重要** JSONPath 没有方向标记，因此策略的效果决定其方向：`suppressOutput`读取响应，任何其他效果读取请求。因此，使用 JSONPath 的输出护栏必须是 a`suppressOutput`，而输入护栏可以是 a `forbid` 或 a `permit` — 两者都读取请求。不要在下方的同一个调用中混用 JsonPath 和空`context.input.*`字段 `suppressOutput` ——两者暗示相反的方向，请求会被视为附带冲突而被拒绝。 单个 JSONPath 的所有匹配项都连接成一个字符串，它们之间没有分隔字符。这是故意的：分成两个内容块的模式，例如社会安全号码`123-`后面跟着的社会安全号码`45-6789`，保持连续并且不能滑过寻找整个模式的探测器。这也意味着来自相邻匹配项的文本一起运行，因此扫描不相关字段的路径可以生成一个不包含单个字段的值。 只要至少有一条其他配置的路径可以解析，则不匹配任何内容的路径都不会起到任何作用。这使您可以在一次调用中命名多个候选形状，用于结构各不相同的有效负载，并且所使用的路径是存在的有效载荷。 **警告** **创建策略时，JSONPath 未经过验证。**与字段路径不同，它既不 AgentCore 检查其语法，也不检查其是否适合您的架构。格式错误的路径，或者命名有效载荷从未发送过的字段的路径，仍然可以到达`ACTIVE`。评估时会发生什么情况取决于其他问题能否解决。 **如果没有配置的数据路径可以解析范围内的任何位置，****则评估失败关闭**。没有护栏可以运行，因此请求被拒绝`Authorization denied: request missing field(s) required for guardrail evaluation`，并命名了它无法解析的路径。正在运行的交通停了下来。遇到此错误时，请先检查 JSONPath。 **如果至少有一条已配置的路径确实可以解析，**则会跳过包含内容的护栏正常运行和决定，并且只跳过路径未解析的检查。那张支票没有任何作用，也没有提出任何结果，因此在几条工作路径中，一条输入错误的路径会默默地失败，而不是大声失败。 根据应捕获的内容测试每个 JsonPath 护栏，然后从[使用 jsonPath 访问数组内的文本中获取路径，而不是从其他 API](example-policies-guardrails.md#example-policies-guardrails-jsonpath) 改编它们。 有关每个推理 API 路径的示例，请参阅使用 [JSONPath 访问数组内的文本](example-policies-guardrails.md#example-policies-guardrails-jsonpath)。 ### 护栏的阈值 通过内容过滤器和即时攻击检测，护栏会返回置信度分数，该分数是 [0, 1] 范围内的数值，其中 0 表示低置信度，1 表示高置信度。该分数表示护栏检测到违规行为的信心程度。当前可能的分数是离散值 {0.0、0.2、0.4、0.6、0.8、1.0}。 要设置阈值，请向比较运算符提供十进制值，例如`greaterThan(decimal("0.4"))`。 **分数比较运算符** 您可以将以下比较运算符应用于`confidenceScore``maxConfidenceScore()`、或`minConfidenceScore()`： | 运算符 | 用量 | | --- | --- | | `.greaterThan(decimal("X.X"))` | 分数 > 阈值 | | `.greaterThanOrEqual(decimal("X.X"))` | 分数 ≥ 阈值 | | `.lessThan(decimal("X.X"))` | 分数 < 阈值 | | `.lessThanOrEqual(decimal("X.X"))` | 分数 ≤ 阈值 | 您可以在策略中使用聚合来提取和比较护栏返回的分数： **聚合** | 聚合 | 说明 | 示例 | | --- | --- | --- | | `[].confidenceScore` | 访问特定类别的置信度分[数（十进制](https://docs.cedarpolicy.com/policies/syntax-datatypes.html#datatype-decimal)）。不适用于`SensitiveInformation`。 | `["HATE"].confidenceScore` | | `maxConfidenceScore()` | 所有扫描类别的最大可信度（[十进制](https://docs.cedarpolicy.com/policies/syntax-datatypes.html#datatype-decimal)） | `.maxConfidenceScore()` | | `minConfidenceScore()` | 所有扫描类别的最低置信度（[十进制](https://docs.cedarpolicy.com/policies/syntax-datatypes.html#datatype-decimal)） | `.minConfidenceScore()` | | `count()` | 检测到的发现数量（[长](https://docs.cedarpolicy.com/policies/syntax-datatypes.html#datatype-long)）。将其与整数运算符进行比较，而不是`decimal`方法。 | `.count() > 0` | | `categories()` | [护栏检测到的类别[集（字符串集](https://docs.cedarpolicy.com/policies/syntax-datatypes.html#datatype-set)）](https://docs.cedarpolicy.com/policies/syntax-datatypes.html#datatype-string) | `.categories().contains("HATE")` | **重要** `SensitiveInformation`需要一种聚合方法，并且不支持按类别编制索引。使用创建策略`BedrockGuardrails::SensitiveInformation(["EMAIL"], [context.input.text])["EMAIL"].confidenceScore`时，诸如之类的语句会被拒绝`Per-category indexing is not supported for SensitiveInformation`。`minConfidenceScore()`改用`count()``categories()``maxConfidenceScore()`、、或。 `ContentFilter`并`PromptAttack`支持两种形式。 #### 如何选择阈值 如果在提示创作服务时未指定阈值，则 AgentCore 设置默认值。如果您在没有创作服务帮助的情况下编写策略，则必须提供阈值。 以下默认值经过校准，可为大多数工作负载提供广泛的覆盖范围和可接受的精度： | 护栏类型 | 默认阈值 | | --- | --- | | 内容过滤器 | 0.2 | | 即时攻击检测 | 0.4 | | 敏感信息 | 0.2 | ##### 选择自定义阈值 如果默认阈值不符合您的要求，则可以使用以下方法之一确定工作负载的最佳阈值。 **选项 1：根据黄金测试集进行评估** 当你有一组精心策划的测试输入并具有明确的预期结果时，请使用这种方法。 1. 创建您的策略并将策略引擎模式设置为 LOG\_ONLY。 1. 通过策略引擎所连接的网关运行您的测试集。 1. 查看每次评估的日志。每个日志条目都包括评估的内容和护栏返回的置信度分数。 1. 对于每个结果，标注护栏是应该标记内容还是什么都不做（分别为真和假）。 1. 使用这些标签，再加上日志中可用的置信度分数，可以在多个阈值下构建混淆矩阵。比较每个阈值的精度和召回率，选择与误报容忍度与错过检测的容忍度一致的值。 **选项 2：根据生产流量进行评估** 如果您没有预先构建的测试集，并且想要使用真实的流量模式进行校准，请使用此方法。 1. 创建您的策略并将策略引擎模式设置为 LOG\_ONLY。 1. 允许策略引擎评估生产流量。每个日志条目都包括评估的内容和护栏返回的置信度分数。 1. 使用 LLM-as-a-judge 将每个记录的结果标记为 true（护栏本应标记内容）或 false（护栏不应该标记内容）。 1. 使用这些标签，在多个阈值下构建混淆矩阵。比较每个阈值的精度和召回率，选择与误报容忍度与错过检测的容忍度一致的值。 ### 测试保单中的护栏 AgentCore 提供了多种机制，用于在生产流量上强制使用护栏之前对其进行测试。您可以在策略引擎级别、单个策略级别或两者兼而有之地控制强制执行，从而可以逐步验证护栏行为。有关更多信息，请参阅[在 LOG\_ONLY 模式下测试策略](policy-test-a-policy.md)。 ## 保单中的护栏是如何运作的 您可以在任何网关目标的策略中设置护栏。护栏在以下位置运行： + **MCP 目标** — 行动`___`，通过 `POST /mcp` () JSON-RPC `tools/call` 实现 + **AgentCore 运行时目标** — 操作 `___POST:/invocations` + **推理目标** — 每个 API 形状一个目标，因此每个 API 只有一个操作： + `___POST:/v1/chat/completions` + `___POST:/v1/responses` + `___POST:/v1/messages` + `___GET:/v1/models` + **HTTP 代理目标** — 操作 `___:` 当呼叫到达您的网关时，策略评估器会执行以下操作： 1. **匹配范围**-确定哪些带有防护的策略适用于此请求 1. **提取内容** — 从请求正文中提取由`dataPath`（例如`context.input.message`）指定的字段 1. **调用 Bedrock InvokeGuardrailChecks API** — 评估内容并将返回的置信度分数注入策略评估上下文中 1. **使用护栏分数评估策略 — 将返回的置信度分数**与策略中定义的阈值进行比较 1. **将决策**`ALLOW`或`DENY`带有策略注释的决策返回网关 注意：护栏是不确定的，因此相同的输入可能会导致不同的输出。政策是确定性的；相同的评估环境将始终导致相同的政策决策。 ## 限制 + **不支持正则表达式或模式匹配** — 护栏使用 ML 评分，而不是正则表达式 + 方@@ **块中需要护栏——护栏`when guardrails {…​}`块里面必须至少定义一个**护栏 + **护栏调用无法读取请求的两边，**一次调用中的所有数据路径都必须为或`context.input.*`。`context.output.*``suppressOutput`策略可以读取双方，但不能从同一个通话中读取 + **Guardrails 是不确定性的** — 相同的内容在单独的通话中可能得分不同，因此接近你阈值的请求可能会被允许一次，下次则被拒绝 + **`suppressOutput`需要护栏状况——其状况**必须仅包括护栏检查。它不支持标准 Cedar 或`temporal {…​}`条件 + **`$`-jsonPath 数据路径在创建时不会经过验证**，也不会检查其语法及其是否适合您的架构。如果它是唯一的路径并且解析为空，则请求将被拒绝而不是被屏蔽，并且拒绝会命名未解析的路径。如果其他路径确实解析了，则会以静默方式跳过未解析的检查。请参阅[将上下文传递给您的护栏](#passing-context-to-your-guardrail) **注意** 在**授权**效果下（`permit`或`forbid`者），**您可以**将护栏与普通雪松条件合并到一份保单中。 `when guardrails { E }`等同于一个身体`when { E }`叫护栏的平原；`guardrails`标签记录的是意图而不是限制政策。把护栏叫声`when`和请求或主要条件放进去。`unless`通过这种方式，单个策略可以包含护栏呼叫、Cedar 条件和时间条件——请参阅[将护栏与请求条件相结合以及将时间、护栏和请求条件](example-policies-guardrails.md#example-policies-guardrails-combined)[相](example-policies-temporal.md#example-policies-temporal-mixed)结合。 `suppressOutput`是个例外：其状况必须仅包括护栏检查。有关更多信息，请参阅在策略[中编写护栏。](#defining-guardrails-in-policies)