Amazon Bedrock Guardrails Adds InvokeGuardrailChecks — Apply Per-Step Safety Checks Inside Agentic Pipelines Without Managing a Guardrail Resource

Amazon Bedrock Guardrails launched InvokeGuardrailChecks on June 16, 2026, announced on the AWS Machine Learning Blog — a new API designed for builders running multi-step agentic pipelines who need to apply different safety checks at different points in the loop without the overhead of managing guardrail resources.

What InvokeGuardrailChecks does differently. The existing Bedrock Guardrails ApplyGuardrail API requires a guardrail resource — you create, version, and reference a guardrail object by ARN, and it applies a uniform policy across the application. InvokeGuardrailChecks removes that requirement entirely: safeguards are specified inline per request, there is no guardrail ID or version to track, and the check can be called at any step in the agentic flow. AWS describes this as enabling builders to "apply individual safeguards, also referred to as safety checks, at any point in your agentic AI applications."

Detect-only mode and numeric scores. InvokeGuardrailChecks runs in detect-only mode — it does not block or mask content itself. Instead, it returns numeric severity or confidence scores for each safeguard category, with discrete values of {0, 0.2, 0.4, 0.6, 0.8, 1.0}. The application logic reads those scores, compares them against developer-defined thresholds, and decides what to do: block the step, bypass and continue, retry with a modified prompt, or log for review. This gives teams control over how aggressively each stage of a pipeline is guarded — tool-call validation can use a different threshold than final output filtering.

Supported safeguard categories. Three categories are available at launch. Content Filters detect hate, violence, sexual content, insults, and misconduct. Prompt Attack Detection — which can be invoked independently of content filters — detects jailbreaks, prompt injection, and prompt leakage. Sensitive Information Filters cover 31 PII entity types including email, phone, SSN, and credit cards; results include character offsets (`beginOffset`, `endOffset`) for precise identification. The blog notes that prompt attack detection is separated as a standalone check, unlike ApplyGuardrail where it is bundled with content filters.

IAM and regional setup. The required IAM permission is `bedrock:InvokeGuardrailChecks` with `Resource: "*"` — consistent with the resourceless design. The blog's example uses `region_name="us-east-1"` and recommends scoping regional access via `aws:RequestedRegion` conditions in IAM policy. No pricing information was provided in the announcement post; check the Bedrock pricing page for current rates.

Operator relevance. InvokeGuardrailChecks is relevant regardless of which LLM is running on Bedrock. Any multi-step agentic workflow — tool orchestration, retrieval-augmented generation, automated coding loops — can now instrument individual steps with targeted safety checks at the threshold level appropriate for that step, without creating a separate managed guardrail configuration. The tradeoff is that detect-only means the guardrail does not act — the application must act on the scores.