← Back to all announcements
★★★★★ 16/06/2026

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

graph TD A{{InvokeGuardrailChecks API}}:::announced B((Agentic AI App)):::external C(Amazon Bedrock):::compute D([Content Filters]):::feature E([Prompt Attack Detection]):::feature F([PII Detection]):::feature G([Numeric Scores 0-1]):::feature H(LLM Foundation Model):::compute I([Custom Action Logic]):::feature B ==>|"per-request call"| A A -->|"detects harmful content"| D A -->|"detects jailbreak/injection"| E A -->|"detects sensitive info"| F A -->|"returns scores"| G G -->|"block/pass/retry/log"| I B -->|"invokes model"| H H -->|"response"| B I -.->|"enforces policy"| B A -->|"runs within"| C classDef announced fill:#ff9900,stroke:#ec7211,color:#fff,font-weight:bold classDef compute fill:#e3f2fd,stroke:#1565c0,color:#1565c0 classDef storage fill:#e8f5e9,stroke:#2e7d32,color:#2e7d32 classDef feature fill:#fff3e0,stroke:#e65100,color:#e65100 classDef external fill:#f5f5f5,stroke:#616161,color:#616161

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 CreateGuardrail step, 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. ApplyGuardrail API: The existing ApplyGuardrail API requires a pre-created guardrail resource with an ID and version; InvokeGuardrailChecks is fully resourceless and stateless, with safeguards specified inline per call.
  • vs. ApplyGuardrail enforcement model: ApplyGuardrail can enforce blocking and redaction decisions server-side; InvokeGuardrailChecks is detect-only, returning scores and delegating all enforcement decisions to the caller's application logic.
  • vs. ApplyGuardrail prompt attack handling: In ApplyGuardrail, prompt attack detection is bundled within the broader guardrail configuration; in InvokeGuardrailChecks, 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; InvokeGuardrailChecks allows 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), InvokeGuardrailChecks can 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."

Tags

Servicesbedrock
Typenew-featurega-launch
Conceptsagentic-airesponsible-ai
Use Casesenterprisedeveloper-tools
GeographyAMERICASAPJEMEA

Related Resources

AI Radar AWS

AWS AI/ML news — curated, researched, explained

An automated intelligence platform that curates, researches, and analyzes AWS AI/ML/GenAI announcements daily. Every report is backed by real research — the system reads linked blog posts and documentation to provide accurate, in-depth analysis.

How Each Report Is Generated

  1. Collection — Daily monitoring of the AWS "What's New" RSS feed
  2. Filtering — AI-powered relevance detection for AI/ML/GenAI topics
  3. Taxonomy Tagging — LLM-based classification across 6 dimensions
  4. Importance Scoring — Point-based system with tag bonuses (1-5 stars)
  5. Research Phase — Follows links to blog posts and documentation
  6. Report Generation — Claude Sonnet produces structured 6-section analysis
  7. Visual Summary — Claude Opus generates Mermaid diagrams for key items
  8. Publishing — Static website rebuilt and deployed via CloudFront

Features

  • Faceted filtering by service, type, concept, and more
  • Multi-dimensional taxonomy with 80+ tags across 6 dimensions
  • Geographic availability badges (Global, APJ, EMEA, AMER) with filtering
  • Timeline visualization of announcement volume
  • PDF export for offline reading
  • Mermaid visual summaries for key announcements
  • Daily automated updates — no manual curation
What makes this different: Each report involves a dedicated research phase where the system reads linked blog posts and AWS documentation pages. This produces analysis that goes beyond the original announcement text.

Technology

Built with Python, AWS Lambda, Amazon Bedrock (Claude Sonnet 4.6, Opus 4.6, Haiku 4.5), S3, CloudFront, WAF, EventBridge, and CDK.

Open Source

This project is open source. Fork it, customize it for your needs, and deploy your own instance.
📦 github.com/bbonik/ai-radar-aws

How Importance Scoring Works

Each announcement receives a point score based on multiple factors. The total score maps to a 1-5 star rating:

1★ < 2 pts 2★ ≥ 2 pts 3★ ≥ 3.5 pts 4★ ≥ 5 pts 5★ ≥ 6.5 pts

Point Breakdown

FactorPointsWhen
Core AI service (Bedrock, AgentCore, SageMaker AI)+4Service named in title
Key AI service (SageMaker, Kiro, QuickSight)+2Service named in title
Other AI-related service+1Default
Blog post link+3Link to aws.amazon.com/blogs/
GitHub samples link+2Link to github.com/aws*
Documentation link+1Link to docs.aws.amazon.com/
New model+1.5Tagged as "new-model"
New service+1Tagged as "new-service"
New feature+0.5Tagged as "new-feature"
Anthropic / OpenAI provider+2Provider explicitly mentioned
Instance / notebook announcement-2Hardware/capacity, not feature
Performance / pricing / security-0.5Incremental updates
Region expansion to APJ+1Expands to Asia Pacific
Region expansion (non-APJ only)-1.5Only expands to other regions

Geographic Relevance Badges

Each announcement card shows a small badge indicating whether the feature is available in your region:

🌐 Global Available in all regions
🌏 APJ Asia Pacific
🌍 EMEA Europe / Middle East / Africa
🌎 AMER Americas (US, Canada, South America)
No badge Geography unknown
How geography is detected: The system detects ALL geographies mentioned in each announcement. If the text mentions specific regions (Tokyo, Frankfurt, Oregon, etc.), the corresponding geography badges are shown. If it says "all regions" or is a new feature with no region specified, it gets the Global badge. Geography is also filterable — click a geo chip to see only announcements available in that region.