Amazon Bedrock Guardrails announces a new API targeting agentic AI workflows
Apply per-step AI safety checks in agent loops without managing guardrail resources—get numeric risk scores and enforce your own thresholds.
View original announcement →Visual Summary
What's New
AWS has launched the InvokeGuardrailChecks API for Amazon Bedrock Guardrails, a resourceless API designed specifically for agentic AI workflows that allows developers to apply individual safety checks at any point in an agent loop without pre-creating guardrail resources. The API operates in detect-only mode, returning numeric severity and confidence scores (0–1) for each check so developers can implement custom thresholds and define their own response actions—block, pass, retry, or log. It supports content filters, prompt attack detection (jailbreak, prompt injection, and prompt leakage as independent checks), and sensitive information filters for PII detection.
How It Works
- Resourceless invocation: The API requires no
CreateGuardrailstep, no guardrail IDs, and no version tracking—safeguards are specified inline with each API request, eliminating upfront resource provisioning. - Per-request safeguard selection: Callers specify exactly which safeguards to run in each individual request, enabling different safety postures at different steps of the same agent loop (e.g., prompt attack detection on input, PII detection on tool output).
- Detect-only mode: The API never blocks or redacts content itself; it returns a numeric score between 0 and 1 for each safety check, and the application logic decides what action to take based on custom thresholds.
- Content filters: Detects harmful content across categories including hate speech, violence, sexual content, insults, and misconduct, returning per-category severity scores.
- Prompt attack detection: Exposes jailbreak, prompt injection, and prompt leakage as independent, individually invocable safeguards—each can be called in isolation rather than as a bundled check.
- Sensitive information filters: Detects supported PII entity types in both user prompts and model responses, returning confidence scores for each detected entity.
- Flexible placement: The API can be called before sending a prompt to the LLM, after receiving a model response, before executing a tool call, after a tool returns a result, or at any other arbitrary point in the workflow.
Why It's Important
- Agentic workflows have heterogeneous risk profiles: A single agent request may span dozens of steps—planning, tool calls, result processing—each with different threat vectors, making a static, one-size-fits-all guardrail configuration inadequate and expensive to maintain.
- Reduces operational overhead at scale: Eliminating the need to create, version, and track individual guardrail resources per workflow step significantly lowers the operational burden for teams running complex multi-agent systems.
- Enables fine-grained, adaptive safety logic: Numeric scores allow teams to build nuanced response strategies (e.g., route to human review at score > 0.7, hard block at score > 0.9) rather than binary allow/deny decisions.
- Accelerates iteration: Because safeguards are declared per-request rather than managed as persistent resources, developers can add, remove, or reconfigure checks as workflows evolve without infrastructure changes.
- Addresses prompt injection risk in tool-use loops: Prompt injection is a critical attack vector in agentic systems where tool outputs can carry adversarial instructions; the ability to check tool results independently before re-feeding them to the model is a meaningful security control.
How It's Different
- vs.
ApplyGuardrailAPI: The existingApplyGuardrailAPI requires a pre-created guardrail resource with an ID and version;InvokeGuardrailChecksis fully resourceless and stateless, with safeguards specified inline per call. - vs.
ApplyGuardrailenforcement model:ApplyGuardrailcan enforce blocking and redaction decisions server-side;InvokeGuardrailChecksis detect-only, returning scores and delegating all enforcement decisions to the caller's application logic. - vs.
ApplyGuardrailprompt attack handling: InApplyGuardrail, prompt attack detection is bundled within the broader guardrail configuration; inInvokeGuardrailChecks, each attack vector (jailbreak, prompt injection, prompt leakage) is an independently invocable safeguard. - vs. building custom classifiers: Rather than training and hosting custom content classifiers, developers get AWS-managed, continuously updated safety models with no ML infrastructure to maintain.
- vs. static guardrail configurations: Traditional guardrail resources apply a fixed policy uniformly;
InvokeGuardrailChecksallows the safety posture to vary dynamically at each step of a loop within a single user request.
When to Prefer It
- Multi-step agentic loops: When your agent executes many sequential steps (planning, tool selection, tool execution, result synthesis) and each step warrants a different combination of safety checks.
- Rapid prototyping and experimentation: When you want to test different safeguard combinations without the overhead of creating and managing versioned guardrail resources in your AWS account.
- Custom enforcement logic: When your application requires nuanced, threshold-based actions (e.g., soft warnings, human-in-the-loop routing, retry with rephrasing) rather than simple binary block/allow behavior.
- Tool-call security: When you need to inspect tool inputs and outputs for prompt injection or PII leakage before they are passed back into the model context.
- Dynamic or ephemeral workflows: When your agent topology changes frequently (e.g., different tools or sub-agents activated per request) and maintaining a static guardrail configuration per workflow variant is impractical.
- Compliance and audit logging: When you need per-step safety scores logged for audit trails without necessarily blocking content, such as in regulated industries requiring evidence of safety monitoring.
- Lightweight integrations with third-party models: Since Bedrock Guardrails works with self-hosted and third-party models (OpenAI, Gemini),
InvokeGuardrailCheckscan be used as a safety layer in non-Bedrock model pipelines without resource coupling.
Availability
- GA status: Generally available as of June 16, 2026.
- Supported regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (London), Europe (Stockholm), Asia Pacific (Tokyo), and Asia Pacific (Sydney).
- Pricing: Not explicitly stated in the announcement; standard Amazon Bedrock Guardrails pricing is expected to apply—consult the AWS pricing page for current rates.
- Mode limitation: The API is detect-only; it does not perform server-side blocking, redaction, or content modification—enforcement must be implemented in application code.
- Safeguard scope: Supports content filters, prompt attack detection (jailbreak, prompt injection, prompt leakage), and sensitive information/PII filters; other Bedrock Guardrails capabilities such as denied topics, hallucination detection (Automated Reasoning checks), and word filters are not available through this API.
- Documentation: Full usage guide available at the Amazon Bedrock User Guide under "Use the InvokeGuardrailChecks API in your application."