Amazon Bedrock Guardrails sensitive-information filters detect personally identifiable information and can either block the entire prompt/response or mask recognized values before they pass through the conversational flow. Current AWS documentation describes this as a context-dependent machine-learning classifier over text, with built-in PII categories plus custom regular expressions for deterministic patterns.
Within Generative AI on AWS, PII filtering is one privacy control among several. It can reduce accidental disclosure in prompts and model responses, but it does not automatically sanitize every field in a tool-calling workflow, every log, or every external data store.
The existing AI guardrails and content safety article provides the broader control-plane context. This page focuses on the current Bedrock PII behavior and its operational boundaries.
Block and mask solve different problems
Block rejects the affected input or response and returns the configured guardrail message.
Mask lets the conversation continue while replacing detected values with placeholders such as {NAME} or {EMAIL} according to service behavior.
Use block when any presence of that data violates policy; use mask when the business task can still succeed with anonymized values.
Built-in PII types are context-aware
Bedrock Guardrails includes many built-in PII categories covering identity, contact, financial, credential, device/network, and country-specific identifiers.
Because detection is context dependent, a digit string can be interpreted differently depending on surrounding text.
AWS explicitly recommends providing enough context rather than submitting isolated words/values when relying on PII classification accuracy.
Custom regex is useful for organization-specific identifiers
Regex filters can catch employee numbers, account formats, ticket IDs, internal project codes, or other predictable sensitive patterns not represented by built-in PII types.
Regex is deterministic pattern matching rather than contextual classification, so it can be more reliable for a strict format but more prone to false positives if the pattern is broad.
Test regex against realistic content and note that current AWS documentation does not support lookaround in custom sensitive-information regex patterns.
Tool-call arguments are a major boundary
AWS currently documents that PII filters do not evaluate PII the model generates inside tool-call arguments, nor PII returned inside tool results, nor PII embedded in the tool definitions themselves.
This is critical for agents. A model can generate an email address as a function argument even when ordinary assistant text would be masked.
Validate and redact sensitive tool arguments/results in the application/tool layer before sending them to downstream systems or back to the model.
Model invocation logs can contain the original unmasked input
AWS notes that when model invocation logging is enabled, the CloudWatch Logs/S3 input field can contain the original request regardless of guardrail intervention.
That means PII masking in the model path is not a log-redaction solution.
Use CloudWatch log data protection, application-side redaction, restricted log access, and retention controls appropriate to the data classification.
Guardrail trace output can expose the matched PII value
The trace/assessment structure can include the original matched PII in fields intended for application logic and diagnostics.
Do not forward raw guardrail traces to user-visible errors or general analytics stores without redaction.
Security monitoring can keep the event type/category while minimizing the actual sensitive value unless investigation requires it.
Code and hybrid content can contain PII too
Current sensitive-information filtering supports natural language and code-related text, including comments, string literals, and other code contexts.
This matters for developer copilots and agents that inspect configuration or source code where credentials, usernames, IP addresses, or customer examples may be embedded.
PII policy should be tested against the content types the application actually sends, not only chat-like prose.
Use ApplyGuardrail when you need filtering outside model invocation
Bedrock Guardrails can be applied independently from a model call using the guardrail runtime API.
This allows an application to check user input before retrieval/tool execution or check generated/intermediate content that does not pass through the main Bedrock model request.
For agent systems, this can help place PII checks at multiple boundaries rather than only at final inference.
PII detection should be part of a complete privacy flow
Guardrail filtering does not replace IAM, encryption, tokenization, least-privilege data access, DLP, log protection, retention, or downstream API controls.
If the application retrieves a customer record from a database and passes it to a tool, that path may never be protected by the specific prompt/response PII filter.
Map every path where sensitive values can enter, move, be stored, and leave the agent.
Measure false positives and false negatives with domain data
Customer support transcripts, code, healthcare text, finance documents, or operational logs each create different contexts for names, numbers, and addresses.
Build a labeled test set and track blocked/masked results by PII type.
If a required identifier is constantly masked, the workflow may need structured side-channel handling rather than weakening the global guardrail.
PII filtering succeeds when sensitive data cannot escape through a side path
The mature design chooses block versus mask by use case, supplements built-ins with precise regex, protects invocation logs/traces, validates tool arguments and results, tests real domain content, and knows which flows require ApplyGuardrail or application-side DLP.
A PII filter is valuable only when the team understands exactly which content it sees and which content it does not.
PII policy should differentiate data the model legitimately needs from data that should never enter generation. A customer-service summarizer may need names during ingestion but can mask them before summary generation; a fraud workflow may need account identifiers for deterministic lookup but should keep those identifiers in structured tool arguments rather than natural-language context. The right architecture often routes sensitive fields around the model instead of asking one guardrail to sanitize everything after the fact.
False positives should be reviewed by PII type. Product codes, server names, device IDs, or ticket numbers can resemble account or identity patterns in some contexts. If a filter blocks legitimate workflows, add more context, move the identifier to a structured field outside the model prompt, or use a narrower custom regex rather than disabling the entire PII category across the application.
False negatives deserve their own test corpus. Synthetic names and phone numbers are easy; realistic abbreviations, international formats, identifiers embedded in logs, and code comments are harder. Include customer-specific data formats and adversarial obfuscation in preproduction tests, then monitor unexpected sensitive-data incidents to expand the corpus over time.
Masking can alter downstream semantics. Replacing an email address with a token may be fine for summarization but can break a model task that must compare two addresses, detect duplicates, or generate a personalized response. Decide which tasks can operate on masked placeholders and which must be redesigned around secure structured data access.
Regular expressions should be anchored to business syntax where possible. A generic sixteen-digit regex can match harmless inventory numbers; a stronger payment-card rule can include delimiters or validation logic outside the guardrail. Treat regex as one signal and perform deterministic validation in application code when the exact format has financial or security impact.
Streaming responses need the same caution. If an application streams model output to the user while a guardrail is applied, the client should follow the documented guardrail/response semantics and avoid exposing content that the final policy outcome blocks. Test streaming plus PII cases explicitly instead of assuming the nonstreaming behavior applies identically.
Guardrail version changes should be rolled out like application releases. Add or change PII categories, custom regexes, block versus mask actions, or messages in a candidate version, run the labeled corpus, compare intervention rates, then promote. Keep previous behavior available long enough to diagnose whether a production issue came from the guardrail change or the model/application.
Metrics should separate input PII, output PII, block, mask, regex match, and entity type. Aggregate counts can reveal whether one upstream system suddenly begins sending customer identifiers into prompts or whether a model change increases sensitive outputs. Avoid storing raw matched values in analytics unless the security use case requires them and access is tightly controlled.
For multi-tenant services, guardrail policy can be shared while tenant-specific data handling remains separate. One global PII configuration may be appropriate, but the application still needs tenant-aware storage, tools, logs, and deletion. Masking a name does not prevent one tenant’s documents or tool results from leaking to another if retrieval/session isolation is weak.
PII policy should also account for data retention after masking. If the application stores both the raw request and the masked model input, privacy risk remains in the raw copy. Keep only the minimum data needed for audit or product function, define deletion windows, and ensure masked placeholders cannot be reidentified casually by joining them with broadly accessible logs or customer metadata.
For support and analytics teams, publish an intervention taxonomy rather than raw values: entity type, block/mask action, workflow, model, and tenant/account where permitted. This creates useful operational trends without turning the monitoring system into another high-value store of unredacted personal data.
Keep PII test cases in the release suite whenever guardrail version, model, prompt template, or tool flow changes. A safety boundary that is not regression-tested against the actual application can drift even when the PII configuration itself is unchanged.
