Control: AWS > Bedrock > Guardrail > Settings

Compare the configuration of an AWS Bedrock guardrail against the settings sub-policies and, when set to Enforce: Configured, correct drift to match.

The content section is always managed: the 12 content sub-policies (six filter types with input/output strengths, plus the content tier) default to the AWS console "Default settings" baseline (MEDIUM strength on input and output for the five harmful-content categories, HIGH input on Prompt Attack, CLASSIC tier), so flipping to Enforce: Configured without setting individual sub-policies produces a working baseline guardrail with the same content filtering AWS would auto-configure. Override individual sub-policies to tighten (HIGH) or disable (NONE) per category, or switch the tier to STANDARD for broader language coverage (requires cross-region inference).

Every other section (topic, word, sensitive information, contextual grounding, automated reasoning, cross-region) and the four scalars (blocked messaging, description, KMS key) are opt-in: when all of a section's sub-policies are at their defaults, the section is excluded from the diff and the reconciler preserves the guardrail's existing configuration for that section. Setting any sub-policy in a section causes the reconciler to manage that section. Within a managed section, sub-policies that customers leave at defaults fall back to the guardrail's current values for those sub-fields. The policy declares what it cares about; the rest of the section is preserved untouched. This avoids silently wiping AWS-side state that the policy didn't intend to manage.

Recommended workflow: Check: Configured first to surface any diff against the guardrail's current config, then Enforce: Configured once the diff matches intent.