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.

.. image:: /images/foundry-guardrails-bedrock.png
   :alt: Bedrock Guardrail configuration form
   :align: center
   :width: 100%

|

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.
* **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.