7.3 Sensitive Information Filters & PII Redaction/Masking

7.3 Sensitive Information Filters & PII Redaction/Masking

This independent study guide by OpenExamPrep helps candidates prepare for the AWS Certified Generative AI Developer - Professional (AIP-C01) examination. Enterprise generative AI applications regularly process customer communications, support transcripts, billing documents, and medical intakes. Inadvertently exposing Personally Identifiable Information (PII) or Protected Health Information (PHI) to foundation model providers, downstream logging systems, or unauthorized users violates global compliance frameworks including GDPR (General Data Protection Regulation), HIPAA (Health Insurance Portability and Accountability Act), and PCI-DSS (Payment Card Industry Data Security Standard).

Amazon Bedrock Guardrails provides Sensitive Information Filters and Word Filters to intercept, redact, or mask sensitive entities in real time. By decoupling sensitive data handling from foundation model logic, developers achieve verifiable compliance without maintaining brittle, bespoke sanitization scripts.

---

Predefined PII Types vs. Custom Regular Expressions

Bedrock Sensitive Information Filters operate via two complementary mechanisms: AWS-managed entity models and user-defined regular expressions.

1. Managed Predefined PII Types

Amazon Bedrock includes pre-trained entity recognition models covering over 30 standard PII categories across international jurisdictions. Key supported entity types include:

• Government Identifiers: US Social Security Number (US_SOCIAL_SECURITY_NUMBER), US Individual Taxpayer Identification Number (US_ITIN), UK National Insurance Number (UK_NINO), US Driver's License (US_DRIVERS_LICENSE), Passport Number (PASSPORT_NUMBER).
• Financial Records: Credit/Debit Card Number (CREDIT_DEBIT_CARD_NUMBER), Credit Card CVV (CREDIT_DEBIT_CARD_CVV), US Bank Account Number (US_BANK_ACCOUNT_NUMBER), US Bank Routing Number (US_BANK_ROUTING_NUMBER).
• Personal Contact Details: Email Address (EMAIL), Phone Number (PHONE), Name (NAME), Mailing Address (ADDRESS).
• Digital Identifiers: IP Address (IP_ADDRESS), MAC Address (MAC_ADDRESS), AWS Access Keys (AWS_ACCESS_KEY), AWS Secret Keys (AWS_SECRET_KEY).

2. Custom Regular Expressions (Regex)

Managed PII models detect standardized patterns, but enterprise systems frequently utilize proprietary identifier formats. Developers can define custom regex filters within the Guardrail configuration:

• Pattern Syntax: Standard Perl-Compatible Regular Expressions (PCRE).
• Parameters: Each regex entity requires a unique name, a natural language description explaining what the pattern matches, the regex pattern itself, and the configured action (BLOCK or ANONYMIZE).
• Common Exam Scenarios:
  • Proprietary Employee IDs: ^EMP-[0-9]{6}[A-Z]$
  • Medical Record Numbers (MRN): ^MRN-[A-Z]{3}-[0-9]{8}$
  • Enterprise Account Numbers: ^ACCT-(?:PREM|STD)-[0-9]{10}$

---

Enforcement Actions: BLOCK vs. ANONYMIZE

When a sensitive entity or custom regex is detected in user input or model output, Guardrails executes one of two mutually exclusive enforcement actions:

Mechanics of the ANONYMIZE Action

When ANONYMIZE is configured on input prompts, Guardrails detects sensitive entities, strips the raw values, and replaces them with standardized bracketed tokens before passing the payload to the foundation model:

Raw User Input:
"My name is Alice Smith, my phone number is 555-0199, and my account ID is ACCT-PREM-1234567890. Please summarize my recent bill."
                                 │
                                 ▼ (Guardrail Anonymization Engine)
Anonymized Payload Passed to FM:
"My name is [NAME], my phone number is [PHONE], and my account ID is [ACCOUNT_ID]. Please summarize my recent bill."

Because the foundation model operates on the anonymized tokens, raw customer PII is never stored in model cache windows, never reflected in third-party model inference logs, and never logged in downstream analytics.

---

Word Filters: Managed Profanity & Custom Word Lists

In addition to entity-based PII filtering, Bedrock Guardrails provides lexical controls through Word Filters:

1. Managed Profanity Filter: A continuously updated, multi-lingual profanity blocklist maintained by AWS. Enabling this single toggle automatically identifies and blocks common vulgarities, offensive slang, and obscene phrases across multiple languages.
2. Custom Word and Phrase Lists: Organizations can define custom blocklists containing up to 10,000 words or phrases per guardrail. Words can be entered individually or uploaded as a CSV file.
   • Exact Matching: Blocks literal terms (e.g., internal code names like ProjectZeus).
   • Wildcard Matching: Supports trailing wildcards (e.g., competitor* blocks competitor, competitors, competitorapp).
   • Use Cases: Blocking competitor brand names, preventing internal project leaks, or suppressing unapproved technical jargon in customer-facing applications.

---

Runtime API Integration Patterns: Converse vs. ApplyGuardrail

Understanding how to invoke Guardrails programmatically is a core AIP-C01 exam requirement. AWS provides two distinct integration patterns:

Pattern 1: Inline Invocation with the Converse API

When invoking models natively in Amazon Bedrock, developers pass the Guardrail configuration directly in the converse or converse_stream API call. Bedrock automatically orchestrates input evaluation, model invocation, and output evaluation within a single round-trip:

import boto3

bedrock_client = boto3.client('bedrock-runtime', region_name='us-east-1')

response = bedrock_client.converse(
    modelId='anthropic.claude-3-5-sonnet-20240620-v1:0',
    messages=[
        {
            'role': 'user',
            'content': [{'text': 'Contact John Doe at john.doe@example.com regarding loan #98765.'}]
        }
    ],
    guardrailConfig={
        'guardrailIdentifier': 'gr-abc123xyz789',
        'guardrailVersion': '2',  # Production: Always use immutable version
        'trace': 'enabled'        # Captures detailed intervention assessment in response
    }
)

# Inspect response
if response['stopReason'] == 'guardrail_intervened':
    print("Guardrail Block Triggered:", response['output']['message']['content'][0]['text'])
else:
    # If ANONYMIZE was configured, content displays with redacted placeholders
    print("Model Output:", response['output']['message']['content'][0]['text'])

Pattern 2: Standalone Evaluation with the ApplyGuardrail API

The ApplyGuardrail API provides standalone policy evaluation without invoking a foundation model. It accepts an arbitrary string of text, evaluates it against the specified Guardrail version, and returns the assessment along with redacted or blocked output.

response = bedrock_client.apply_guardrail(
    guardrailIdentifier='gr-abc123xyz789',
    guardrailVersion='2',
    source='INPUT',  # Specifies whether to evaluate 'INPUT' or 'OUTPUT' policies
    content=[
        {
            'text': {
                'text': 'Customer SSN is 000-12-3456 and email is customer@corp.com.'
            }
        }
    ]
)

print("Action Taken:", response['action'])  # 'NONE' or 'GUARDRAIL_INTERVENED'
print("Evaluated Output:", response['outputs'][0]['text'])
# If Anonymize is configured: 'Customer SSN is [US_SOCIAL_SECURITY_NUMBER] and email is [EMAIL].'

Architectural Use Cases for ApplyGuardrail

• Pre-Ingestion RAG Scrubbing: Sanitizing documents in Amazon S3 prior to chunking and embedding into OpenSearch Serverless.
• External / Multi-Cloud Model Governance: Applying centralized enterprise AWS safety guardrails to models running on Amazon SageMaker, external REST APIs, or on-premises servers.
• Agent Tool Input/Output Validation: Inspecting parameters passed to AWS Lambda functions before executing database updates.

---

Guardrail Tracing & Observability

When trace: 'enabled' is specified in the runtime configuration, Bedrock returns a comprehensive assessment trace in the API response:

• action: Indicates whether the transaction resulted in NONE or GUARDRAIL_INTERVENED.
• sensitiveInformationPolicy: Details detected entities, match types, confidence scores, and whether the entity was masked or blocked.
• wordPolicy: Details detected profanities or custom blocked terms.
• CloudWatch Metrics: Guardrails automatically publishes operational metrics to Amazon CloudWatch under the AWS/Bedrock namespace, including Invocations, InvocationLatency, SensitiveInformationBlocked, SensitiveInformationAnonymized, and WordPolicyBlocked.

---

Common Exam Traps & High-Stakes Scenarios

• Trap: Conflating BLOCK and ANONYMIZE. If an exam scenario states that customer service representatives need to read and respond to emails containing customer phone numbers without exposing the numbers to the foundation model, selecting BLOCK is wrong because it halts the conversation. The correct solution is ANONYMIZE.
• Trap: Believing ApplyGuardrail Calls a Model. ApplyGuardrail runs exclusively through the Guardrails policy evaluation engine. It incurs zero foundation model token generation charges and can be used as a standalone data sanitation service.
• Trap: Using Custom Word Filters for Entity Detection. Attempting to block employee IDs or SSNs by adding hundreds of patterns to a Custom Word Filter is an antipattern. Custom word filters are for exact phrases and simple wildcards. Complex pattern matching requires Custom Regex under Sensitive Information Filters.
• Trap: Logging Unredacted PII in CloudWatch. When Bedrock Invocation Logging is enabled, sensitive data evaluated by Guardrails with the ANONYMIZE action is sanitized before being written to CloudWatch Logs or Amazon S3, preventing compliance violations in operational logging.