Overview
A guardrail enforces an AR policy at runtime. Deployment is two steps: (1) snapshot the tested DRAFT into an immutable numbered version, (2) attach that version to a guardrail (create or update) with the required cross-region guardrail profile. Updating DRAFT later won't affect a guardrail pinned to a number.
Reference: ../../shared/references/ar-api-context.md (deployment section).
Key directives
- Version before deploying.
CreateAutomatedReasoningPolicyVersionneeds the currentdefinitionHash(concurrency token) from a get/create/update response. The script fetches it. - Pin guardrails to a numbered version in production, not DRAFT.
- ⚠️ AR guardrails require a
crossRegionConfig(a guardrail profile, e.g.us.guardrail.v1:0). The script derives the profile ARN from the policy ARN's account+region. - ⚠️ Max 2 AR policies per guardrail.
- Confirm before deploying. This is an outward-facing change. Check what an existing guardrail currently points to before you overwrite it.
- Default
confidenceThreshold= 1.0 (most stringent). Lower only with a tested reason.
Workflow
# 1. Snapshot DRAFT into a numbered version (handles the definitionHash concurrency token)
uv run scripts/create_version.py --policy-arn <ARN>
# 2. Create or update a guardrail attached to that version (idempotent on guardrail name)
uv run scripts/deploy_guardrail.py --policy-arn <ARN> --policy-version 1 \
--guardrail-name my-ar-guardrail --confidence 1.0
deploy_guardrail.py is idempotent: it looks up the guardrail by name and creates or updates it, then
creates a guardrail version. It returns the guardrail id + version to use with ar-runtime-validator.
After deployment
Hand off to ar-runtime-validator to validate LLM outputs with ApplyGuardrail/Converse against the
new guardrail id + version.
Resources
scripts/create_version.py: snapshot DRAFT → numbered version.scripts/deploy_guardrail.py: ensure-guardrail (create/update) + version, with cross-region profile.../../shared/references/ar-api-context.md.