# Bedrock Guardrails

Bedrock guardrails integrate OneByZero Neo with AWS Bedrock Guardrails — Amazon’s managed service for applying safeguards to generative AI applications. Rather than using a prompt-based approach, Bedrock guardrails apply deterministic and ML-based filters that are maintained and updated by Amazon.

[![Create AWS Bedrock Guardrail form — section navigation and Basic Information](../../images/foundry-guardrails-bedrock-v2.png)](../../images/foundry-guardrails-bedrock-v2.png)

## Creating a Bedrock Guardrail

Click **+ Create** on the **Bedrock** tab to open the configuration form.

**Basic Information**

- **Name** — a unique, descriptive name for the guardrail.
- **Description** — what the guardrail is for. Required.
- **Blocked Input Message** — the message returned when the guardrail blocks a prompt. Required.
- **Blocked Output Message** — the message returned when the guardrail blocks a model response. Required.
- **Tags** and **Labels** — metadata for organisation and governance.

**Content Filters**

Content filters screen for harmful content categories. For each category you can configure the sensitivity level (None, Low, Medium, High) independently for inputs and outputs:

- **Sexual** — sexually explicit or suggestive content.
- **Violence** — violent, threatening, or graphic content.
- **Hate** — hate speech targeting protected characteristics.
- **Insults** — personal insults, bullying, and offensive language directed at individuals.
- **Misconduct** — content that promotes illegal activities or unethical behaviour.
- **Prompt Attack** — attempts to manipulate the agent through prompt injection or jailbreak techniques.

**Denied Topics**

Define specific subjects the agent should refuse to discuss. Each denied topic includes a name and a description that helps the Bedrock model understand what content falls into that category. Common uses:

- Preventing agents from discussing competitor products
- Blocking topics that are out of scope for the agent’s use case
- Enforcing communication guidelines specific to your industry

**Word Filters**

Explicit control over specific words and phrases that should be blocked or flagged:

- Profanity and offensive language lists
- Competitor names
- Restricted terminology
- Custom blocked phrases

**Sensitive Information Filters**

The Sensitive Information Policy protects personally identifiable information (PII) and other sensitive data. You can enable filtering for a comprehensive range of entity types and configure the action per entity:

- **Block** — prevent the content from being processed or returned.
- **Anonymize** — replace the sensitive information with a placeholder (e.g. `[EMAIL_REDACTED]`).
- **None** — permit the content without modification.

Supported PII entity types include:

*Personal identifiers:* email addresses, phone numbers, names, postal addresses, age, date of birth.

*Financial information:* credit and debit card numbers, CVV codes, card expiry dates, bank account numbers.

*Government IDs:* Social Security numbers, driver’s license numbers, passport numbers, national insurance numbers (UK), social insurance numbers (CA), and other regional variants.

*Healthcare information:* health insurance numbers, medical record numbers.

*Cloud credentials:* AWS Access Keys, AWS Secret Keys, API tokens.

**Custom regex patterns** are also supported. For each pattern, provide a name, description, regular expression, and the action to apply (Block, Anonymize, or None). Use regex patterns to detect organisation-specific sensitive data formats not covered by the built-in entity types — internal employee IDs, account reference numbers, and similar structured identifiers.

**Contextual Grounding**

Contextual grounding policies check whether agent responses are grounded in the source material provided (e.g. from a knowledge base or retrieved documents). Content that diverges from the source — hallucinated facts, unverifiable claims — can be blocked or flagged. This is particularly important for:

- Customer support agents that must provide accurate information
- Agents that reference specific policy documents
- Any use case where factual accuracy is non-negotiable

## Applying Bedrock Guardrails to Agents

Bedrock guardrails are applied from the agent’s Settings tab in the same way as In-House guardrails. They can be applied to inputs, outputs, or both. Multiple guardrails can be layered on a single agent.

## Best Practices

- Use Bedrock guardrails for regulated industries (healthcare, finance, legal) where PII protection and content safety must be demonstrably enforced with auditable infrastructure.
- Combine Bedrock guardrails with In-House guardrails for coverage that a single system cannot provide. For example, use a Bedrock guardrail for PII masking and an In-House guardrail for company-specific topic restrictions.
- The Sensitive Information Policy with **Anonymize** action is often preferable to **Block** for customer-facing agents — users see a response with placeholders rather than a hard rejection, which is a better experience while still protecting data.
- Review and update denied topics and word filters regularly. An organisation’s list of competitors and restricted terminology changes over time.