> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Compliance Features Including Guardrails Part 3
> Configuring Amazon Bedrock guardrails to enforce safety, PII masking, profanity filters, versioned policies, and deployment patterns for centralized compliance
In this lesson we cover how to configure Amazon Bedrock Guardrails to define allowed and blocked behavior for generative AI. Guardrails let you specify fine-grained policies that apply to inputs, model outputs, and to topics or phrases you want to restrict. This helps enforce consistent safety and compliance across applications that call Bedrock.
You can create denied topics (for example, a topic named "investment" with a rule such as "do not offer financial investment advice") and populate those topics with sample phrases for matching. Guardrails also support custom word filters and sensitive-information filters, so you can combine protections like profanity filtering with PII masking or blocking.
For example, you can enable or disable a profanity filter and add your own custom words or phrases that aren’t in Amazon’s built-in lists. You can also configure sensitive-information handling to mask or block personally identifiable information (PII) such as credit card numbers, Social Security numbers, customer IDs, names, phone numbers, and email addresses. Each sensitive type can be configured to act on the request input (before the model runs), the model output (after the model responds), or both—letting you choose different actions depending on the data and use case.
Input-action filters run before the text is sent to the model; output-action filters run on the model’s response. You can mask on input, on output, on both, or choose alternate actions per sensitive type to meet privacy and compliance needs.
Guardrails are versioned and immutable. When you publish a guardrail version it cannot be modified; instead you create a new version. This immutability provides clear auditability and traceability: you can see who created each version and when. Applications select which guardrail version to use by specifying the guardrail version ID in requests. This lets teams move applications from one guardrail version to another intentionally and consistently, ensuring predictable behavior across deployments.
How you make guardrails available to developers affects enforcement, usability, and risk. Common deployment patterns include:
| Pattern | Enforcement level | Pros | Cons |
| - | - | - | - |
| App-level (optional) | Optional per request | Flexible; developers can test multiple guardrail configs | Relies on correct implementation by each developer; can be omitted |
| IAM-enforced (mandatory per account) | Enforced via IAM policies | Prevents bypass at account level; consistent for all callers in account | Requires IAM policy management |
| Organization-level enforcement (mandatory across accounts) | Enforced across AWS Organization | Centralized governance across many accounts; ideal for enterprises | Requires org-wide configuration and coordination |
Below is an example that demonstrates how an application references a specific guardrail version ID in a Bedrock-style request payload. The exact API field names depend on the SDK or API you use, but the pattern is the same: include the guardrail identifier and version.
```json theme={null}
{
"modelId": "my-foundation-model",
"input": "Provide investment advice for a $10,000 portfolio.",
"guardrail": {
"name": "enterprise-safety-guardrail",
"versionId": "gv-2026-08-01-01"
}
}
```
If developers are solely responsible for attaching guardrails, some applications may omit them. Enforce guardrails via IAM or organization-level controls to guarantee consistent, non-bypassable protections.
Adopting enforced, centralized guardrails provides tangible benefits:
* Consistent enforcement of filtering and safety policies across applications.
* Reduced risk of harmful or non-compliant outputs because policies apply centrally to every request.
* Scalability—safety controls that work across many accounts and many applications.
* Stronger evidence and audit trails for compliance or regulatory requirements.
Key takeaways
* Guardrails shift safety from ad-hoc, per-application logic into centrally enforced, runtime policies managed by Amazon Bedrock.
* Without guardrails, safety depends on individual application logic and prompt engineering; with guardrails, multiple applications using the same guardrail are filtered consistently.
* Centralized, enforced guardrails reduce friction when moving from experimentation to production by removing the need to implement and maintain duplicate filtering logic across apps.
If your prototype lacks app-level filtering, you can immediately add an Amazon Bedrock Guardrails configuration to requests to obtain centralized filtering and compliance—greatly reducing the effort needed to move to production.
This lesson concludes the Guardrails overview. You will get hands-on practice in two parts:
* Implement a simple application-side filter (Python example below) using lists and string matching to block or flag phrases.
* Implement Amazon Bedrock Guardrails and observe how the app-side filter and Bedrock Guardrails interact (e.g., app filter + centralized guardrail = layered defense).
Example: simple Python application-side filter
```python theme={null}
# naive_filter.py
DENIED_TOPICS = {"investment", "medical", "legal"}
DENIED_PHRASES = ["financial investment advice", "how to treat", "legal contract"]
def contains_denied_topic(text):
lower = text.lower()
for topic in DENIED_TOPICS:
if topic in lower:
return True
for phrase in DENIED_PHRASES:
if phrase in lower:
return True
return False
user_input = "Can you give me financial investment advice?"
if contains_denied_topic(user_input):
print("Blocked by app filter: topic or phrase not allowed.")
else:
# proceed to call Bedrock with guardrail reference
print("Proceeding to model call.")
```
Example: request payload with a guardrail reference (JSON)
```json theme={null}
{
"input": "Can you give me financial investment advice?",
"model": "text-generator-1",
"guardrail": {
"name": "no-investment-advice",
"versionId": "gv-2026-08-01-01"
}
}
```
Additional resources and references
* Amazon Bedrock documentation: [https://docs.aws.amazon.com/bedrock](https://docs.aws.amazon.com/bedrock)
* AWS IAM policies: [https://docs.aws.amazon.com/IAM/latest/UserGuide/access\_policies.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)
* Guidance for handling PII and data protection: [https://aws.amazon.com/compliance/data-privacy/](https://aws.amazon.com/compliance/data-privacy/)
You’ll gain practical experience using both application-side filtering and centrally enforced Amazon Bedrock Guardrails to build safer, more auditable GenAI applications.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.