AWS bedrock documentation change
Summary
Updated documentation about guardrail evaluation modes, including renaming 'NONE' action to 'detect mode', clarifying input/output actions, and adding benefits of detect mode for policy testing.
Security assessment
The changes enhance documentation about security-related content filtering capabilities (blocking/masking harmful content) and introduce 'detect mode' as a testing mechanism for security policies. While this relates to security features, there is no evidence of addressing a specific vulnerability or incident.
Diff
diff --git a/bedrock/latest/userguide/guardrails-harmful-content-handling-options.md b/bedrock/latest/userguide/guardrails-harmful-content-handling-options.md index f750128f7..e145e5e79 100644 --- a//bedrock/latest/userguide/guardrails-harmful-content-handling-options.md +++ b//bedrock/latest/userguide/guardrails-harmful-content-handling-options.md @@ -5 +5 @@ -Example: Preview guardrail evaluations +Guardrail evaluation with detect modeExample: Using detect mode to evaluate content filters @@ -9 +9 @@ Example: Preview guardrail evaluations -Each Amazon Bedrock Guardrails filtering policy has `inputAction` and `outputAction` fields that define what your guardrail does at runtime when it detects harmful content. +You can configure what actions your Amazon Bedrock guardrail takes at runtime when it detects harmful content in prompts (`inputAction`) and responses (`outputAction`). @@ -11 +11 @@ Each Amazon Bedrock Guardrails filtering policy has `inputAction` and `outputAct -Guardrails can take the following actions on model inputs and outputs when harmful content is detected: +Guardrails filtering policies support the following actions when harmful content is detected in model inputs and responses: @@ -13 +13 @@ Guardrails can take the following actions on model inputs and outputs when harmf - * `BLOCK` – Block the content and replace it with blocked messaging. + * **Block** – Block the content and replace it with blocked messaging. @@ -15 +15 @@ Guardrails can take the following actions on model inputs and outputs when harmf - * `ANONYMIZE` – Mask the content and replace it with identifier tags (such as `{NAME}` or `{EMAIL}`). + * **Mask** – Anonymize the content and replace it with identifier tags (such as `{NAME}` or `{EMAIL}`). @@ -19 +19 @@ This option is available only with sensitive information filters. For more infor - * `NONE` – Take no action but return what the guardrail detects in the trace response. This option can help you validate if your guardrail is evaluating content the way that you expect. + * **Detect** – Take no action but return what the guardrail detects in the trace response. Use this option, known as _detect mode_ , to help evaluate whether your guardrail is working the way that you expect. @@ -24 +24 @@ This option is available only with sensitive information filters. For more infor -## Example: Preview guardrail evaluations +## Guardrail evaluation with detect mode @@ -26 +26 @@ This option is available only with sensitive information filters. For more infor -Guardrail policies support a `NONE` action, which acts as a detection mode so that you can see how the guardrail evaluation works without applying any action (such as blocking or anonymizing the content). The `NONE` action can help you test and tune content filter strength thresholds or topic definitions before using these policies in your actual workflow. +Amazon Bedrock Guardrails policies support detect mode, which lets you evaluate your guardrail's performance without applying any action (such as blocking the content). @@ -28 +28,16 @@ Guardrail policies support a `NONE` action, which acts as a detection mode so th -For example, let's say you configure a policy with a content filter strength of `HIGH`. Based on this setting, your gurardrail will block content even if it returns a confidence of `LOW` in its evaluation. To understand this behavior (and make sure that your application doesn't block content you aren't expecting it to), you can configure the policy action as `NONE`. The trace response might look like this: +Using detect mode offers the following benefits: + + * Test different combinations and strengths of your guardrail's policies without impacting the customer experience. + + * Analyze any false positives or negatives and adjust your policy configurations accordingly. + + * Deploy your guardrail only after confirming it works as expected. + + + + +## Example: Using detect mode to evaluate content filters + +For example, let's say you configure a policy with a content filter strength of `HIGH`. Based on this setting, your guardrail will block content even if it returns a confidence of `LOW` in its evaluation. + +To understand this behavior (and make sure that your application doesn't block content you aren't expecting it to), you can configure the policy action as `NONE`. The trace response might look like this: