Amazon just shipped a resourceless safety API that hands you a score and tells you to decide the action yourself. The InvokeGuardrailChecks API lets you apply content filters, prompt attack detection, and sensitive information scanning at any point in an agentic loop without creating a single guardrail resource.
Why Agentic Loops Broke the Old Guardrail Model
Traditional guardrails work fine for a single request-response. You create one resource, configure policies, and apply it uniformly. AI agents don't work that way. A single user session can involve 10, 20, or more turns, each with different risk profiles. Input evaluation, tool output validation, final response checking, prompt attack detection - each step needs different safeguards.
Before this API, applying a safeguard at an ephemeral step meant a create-invoke-delete lifecycle on every iteration. That scales poorly when you have hundreds of agents. The new API skips that entirely. You call invoke_guardrail_checks with the content and the specific checks you need, and it returns numeric scores. No resource tracking, no version management.
Scores, Not Pass-Fail
The API returns severity scores (0, 0.2, 0.4, 0.6, 0.8, 1.0) for content filters and prompt attack categories, and confidence scores for PII entities. You define the thresholds. A financial services app might block at 0.4; a creative writing tool might tolerate up to 0.8. The response includes precise character offsets for detected PII, so you can mask or redact client-side.
Prompt attack detection is now a standalone check, not bundled inside content filters. You can call it independently for jailbreak, prompt injection, or prompt leakage categories. The API supports multiple checks in a single call - run content filter and sensitive information together, and the results come back with the same keys you sent.
Framework Integration Made Simple
The post shows integration with Strands Agents, a framework that exposes lifecycle hooks. The pattern is clear: evaluate user input for prompt attacks before it hits the model, check tool output for harmful content and PII, validate the final response before returning to the user. All with the same API, no guardrail IDs to pass around.
When to Use InvokeGuardrailChecks vs ApplyGuardrail
If you need uniform enforcement across a traditional request-response app, stick with ApplyGuardrail. If you're building multi-turn agents and want per-step safety logic without operational overhead, InvokeGuardrailChecks is the right call. One creates resources and blocks automatically; the other is resourceless, detect-only, and leaves decisions to your code.
I expect this pattern to become standard as agentic AI workflows mature. The ability to compose safety checks inline, scale to hundreds of agents, and define context-aware thresholds is exactly what production systems need. No more wrestling with guardrail lifecycles in a loop that runs dozens of times per session.
Source: Safeguard your agentic AI applications with the Amazon Bedrock Guardrails InvokeGuardrailChecks API
Domain: aws.amazon.com
Comments load interactively on the live page.