Agentic Data Plane

Create a Guardrail

Create a guardrail to inspect and control the requests and responses that flow through an AWS Bedrock LLM provider. You configure the guardrail in a wizard (details, authentication, and policies), attach it to a Bedrock provider, and confirm it blocks.

After reading this page, you will be able to:

  • Create a guardrail and configure its backend and policies

  • Attach the guardrail to an LLM provider and enable it

  • Verify the guardrail blocks a request and trace it through the transcript

Prerequisites

  • An AWS region and Bedrock access. A guardrail reconciles against the AWS Bedrock control plane, so you need either AWS credentials it can use or a Bedrock LLM provider whose credentials it can borrow.

  • At least one AWS Bedrock LLM provider to attach the guardrail to. Guardrails attach to Bedrock providers only. See Configure an LLM provider.

  • For the Sensitive information, Content filters, Contextual grounding, and Automated reasoning policies, confirm the features you need are available in your chosen Bedrock region.

Add the details

Open the wizard and give the guardrail its name and the messages that callers see when a policy blocks a request.

  1. Open Guardrails in the sidebar and click Create guardrail.

  2. On the Details step, set the following:

    Field Notes

    Name

    Required. Lowercase letters, numbers, and hyphens only, 1 to 63 characters. Used in the resource path and can’t be changed after creation.

    Display Name

    Optional. A friendlier name shown in the list and detail views.

    Description

    Optional.

    Blocked Input Message

    Required. The message returned to the caller when a policy blocks a prompt. 1 to 500 characters.

    Blocked Output Message

    Required. The message returned instead of the model’s response when a policy blocks it. 1 to 500 characters.

    Enabled

    Leave off for now. Enable the guardrail after you configure its policies.

  3. Click Next.

Configure authentication

This step, labeled Authentication in the wizard, sets the AWS region and credentials the guardrail uses to reach Bedrock.

  1. Select a region. The region decides which Bedrock models and guardrail features you can reach, because not every feature is available in every region. Use the same region as the Bedrock provider or model you intend to protect.

  2. Choose a credential source:

    • Standalone AWS credentials: Supply credentials for this guardrail directly.

    • Borrow from a Bedrock provider: Reuse the credentials of a Bedrock LLM provider you already configured.

  3. If you chose standalone credentials, choose a credential type:

    • Default provider chain: Use the credentials available in the runtime environment.

    • Static access keys: Supply an access key ID and secret access key, each stored as a secret reference in the ADP secret store.

    • Assume IAM role: Supply a role ARN, with an optional external ID and session name.

  4. Click Next.

Turn on policies

Each policy is optional, but a guardrail must enforce at least one. Turn on the policies you need, then configure each. For the full configuration of every policy, see Guardrail policy reference.

Start from a preset

The Quick start row at the top of the Policies step applies a preset, a bundle of policy settings for a common goal:

  • Content safety: Blocks hate speech, insults, sexual content, violence, and misconduct at high strength.

  • PII protection: Masks emails, phone numbers, names, addresses, card numbers, and US Social Security numbers.

  • Prompt attack defense: Blocks jailbreak and prompt-injection attempts before they reach the model.

Presets are additive: applying one never removes rules you already configured. Apply a preset, then adjust the individual policies it turned on.

Choose individual policies

Turn on each policy you need and configure its rules:

  • Content filters: Harmful-content categories (hate, insults, sexual, violence, misconduct, and prompt attacks).

  • Word filters: Exact words and phrases from your own lists and platform-managed lists such as profanity.

  • Denied topics: Topics blocked by meaning rather than exact words.

  • Sensitive information: PII detected by built-in entity types and your own regex patterns, then detected, blocked, or anonymized.

  • Contextual grounding: Factual grounding and relevance checks for RAG-style output. Output only.

  • Automated reasoning: Formal Bedrock Automated Reasoning policies. Detect only.

Each policy you turn on exposes a separate Evaluate this policy toggle. Turn it off to save the policy’s configuration without enforcing it, which lets you stage a policy before it takes effect.

Two separate toggles control evaluation:

  • The guardrail-level Enabled toggle, on the Details step, turns the whole guardrail on or off. A disabled guardrail keeps its configuration but evaluates no traffic.

  • The policy-level Evaluate this policy toggle controls a single policy within the guardrail. A policy with this toggle off is saved but not evaluated.

A policy acts on traffic only when its guardrail is enabled and its own Evaluate this policy toggle is on.

A policy you turn on needs at least one rule. ADP rejects a guardrail that has no policy turned on, or that turns on a policy with no rules set, such as a content-filter policy with no category configured or a contextual-grounding policy with neither grounding nor relevance enabled.

A staged policy does not count toward this minimum, because a policy with its Evaluate this policy toggle off is not enforced. A guardrail needs at least one policy that is both turned on and evaluated, so if you stage every policy, ADP rejects the guardrail.

When you finish, click Create guardrail.

Attach the guardrail to a provider

A guardrail takes effect only after a provider references it. On an AWS Bedrock LLM provider, set the guardrail field in the provider’s Bedrock settings to the one you created. Only Bedrock providers expose this setting. A provider references one guardrail, and you can reuse the same guardrail across many providers. See Configure an LLM provider.

Enable the guardrail

After you configure the policies and attach the guardrail, set the guardrail to enabled. A disabled guardrail keeps its configuration but skips evaluation entirely, which is useful while you stage a policy or troubleshoot whether the guardrail is responsible for unexpected blocks.

Enabling or disabling a guardrail takes effect within about 30 seconds, because the gateway briefly caches guardrail settings.

Verify the guardrail blocks

Send a request through an attached provider that violates a policy. For example, with the sensitive-information policy set to block on input, send a prompt that contains an email address or other PII.

The request returns your blocked input message instead of a model response. Open the request’s transcript and confirm the guardrail recorded its action. See See what your agent did for the transcript walkthrough and Review blocked requests for how blocked requests surface.

Edit, disable, or delete a guardrail

From the guardrails list or a guardrail’s detail page:

  • Edit the guardrail to change its backend or policies. Changes take effect within about 30 seconds, because the gateway briefly caches guardrail settings.

  • Disable the guardrail to stop evaluation without losing its configuration.

  • Delete the guardrail to remove it permanently. Deletion asks you to confirm by typing the guardrail’s name.

You cannot delete a guardrail while an LLM provider still references it. ADP blocks the delete and names the providers you must detach first. Open each listed provider, clear its Guardrail field, then delete the guardrail. This protects in-flight traffic: if the guardrail were removed while a provider still pointed at it, every request through that provider would fail.

Next steps