Bedrock PII redaction — detect, block, and mask sensitive data.

IWhat Bedrock PII redaction is — and where it sits

A foundation model will happily echo a Social Security number a user pasted into a prompt, or surface a phone number it retrieved from a document. PII redaction is the Bedrock Guardrails control that stops sensitive values from flowing where they should not — in either direction — without you writing detection code.

Bedrock PII redaction is the behavior of the sensitive-information filter, one of the policy types inside an Amazon Bedrock Guardrail. A guardrail is a named, model-independent policy object that Bedrock evaluates against every interaction; the sensitive-information policy is the part of it that finds personally identifiable information and acts on it. Like every guardrail policy, it runs on both directions — the user input (someone pasting a customer's card number into a chat) and the model output (the model emitting an email address it read from a retrieved file).

The word "redaction" is doing specific work here. When the filter detects a sensitive value it can do one of two things: block the entire interaction (the request never reaches the model, or the response is withheld, and the user sees a message you configured), or anonymize it — what most people mean by "redaction" or "masking" — where the value is replaced in place with a placeholder token such as {EMAIL}, {PHONE}, or {SSN}, and the rest of the interaction proceeds. Anonymizing is what lets a support assistant keep helping a user who happened to include their phone number, while ensuring that number is never stored, logged, or returned verbatim.

Because the guardrail is a separate object from the model, the redaction policy is portable and auditable: it is defined in one place, it is the same no matter which foundation model the request hits, and it can be versioned and shown to a reviewer. This page is a deep dive on this single policy. For the full survey of every guardrail filter type — content filters, denied topics, word filters, contextual grounding — see the amazon-bedrock-guardrails sibling; this page assumes that context and goes deep on PII specifically.

IIBuilt-in PII entity types — and custom regex for your own identifiers

Detection is only as good as the things you tell it to look for. Bedrock ships a managed list of common PII entity types and lets you extend it with regular expressions for the identifiers that are specific to your business.

The sensitive-information filter recognizes two kinds of things: a managed set of built-in PII entity types, and any custom regular-expression patterns you define. You enable the entity types relevant to your workload and pick an action for each; you do not have to take the whole list.

IIIBlock vs redact (mask) — what each does and when to choose it

The single most important configuration decision for this filter is, per entity type, whether to block the interaction or anonymize the value. They produce very different user experiences and very different risk profiles.

Both actions prevent the sensitive value from being exposed; they differ in what happens to the interaction around it.

IVApplying the redaction policy: model calls, Agents, RAG, and non-Bedrock models

A redaction policy is only useful if it covers every path data can take. Because the sensitive-information filter lives in a model-independent guardrail, the same policy reaches direct model calls, autonomous agents, retrieval pipelines, and even models outside Bedrock.

There are three ways the same PII policy gets enforced, and for regulated workloads you typically use more than one.

VHow redaction maps to HIPAA, PCI DSS, and GDPR

PII redaction is frequently the control that makes a generative-AI feature shippable in a regulated context. The mapping to the major regimes is direct, but the boundary of what the control does and does not cover has to be stated honestly.

The sensitive-information filter speaks the language regulators care about: detect the protected data, and prevent it from being stored, logged, or returned. How that maps:

• HIPAA — protected health information (PHI) — Detecting and redacting identifiers such as names, addresses, dates, national IDs, and — via custom regex — medical-record numbers supports data-minimization and helps keep PHI out of prompts, logs, and responses. Bedrock is offered with an AWS compliance posture that includes services in scope for HIPAA eligibility under a BAA (confirm current scope on AWS's compliance pages); the redaction policy is one technical control within that program, not the whole of HIPAA compliance.
• PCI DSS — cardholder data — Built-in detection of card numbers, expiry, and CVV lets you block (the usual choice) or mask cardholder data so it is never placed in the model context, the conversation logs, or the output — directly supporting the PCI principle of minimizing where cardholder data lives. Redaction reduces scope; it does not by itself make a system PCI-compliant.
• GDPR — personal data and data minimization — GDPR's data-minimization and storage-limitation principles map cleanly onto masking PII before it is processed or persisted. Redacting personal data on the input side means the model never processes the raw identifier, and masking on the output side keeps it out of what you store and show. It supports — but does not replace — lawful-basis, data-subject-rights, and DPA obligations.
• SOC 2 — auditable change control — Because guardrails are versioned, you can evidence which redaction policy was in force at any time and demonstrate it was enforced on every interaction — the kind of change-control and control-operation evidence a SOC 2 assessor looks for.

The honest caveat, repeated because it matters: a guardrail is a technical control, not a certification. HIPAA, PCI DSS, and GDPR are organizational programs — BAAs and DPAs, scoping, access controls, encryption, logging, breach processes, audits — and PII redaction is one part. Treat it as defense-in-depth alongside the controls in the next section, not as something you can fully outsource the regulatory risk to.

VICombining redaction with logging controls, encryption, and a reference architecture

Redaction does not exist in isolation. The two places teams most often undo their own redaction are logging and storage — and the fix is to think of redaction, logging, and encryption as one design.

The most common self-inflicted leak in a regulated GenAI build is logging the raw data before it was redacted. Bedrock can capture model-invocation logging (the inputs and outputs of model calls, sent to Amazon CloudWatch Logs and/or Amazon S3), which is invaluable for debugging and audit — but if you log the raw request and then redact, you have a copy of the unredacted PII sitting in your logs. Order and ownership matter.

• 1 — Detect at the edge with ApplyGuardrail (optional but strong) — For the strictest designs, run user input and any to-be-indexed documents through ApplyGuardrail first, so PII is masked before it touches your application logic, your RAG index, or your logs.
• 2 — Enforce inline on every model call — Attach the guardrail (with the sensitive-information policy) to every Converse/InvokeModel call and to every Agent, so both prompt and response are screened regardless of which model is used.
• 3 — Screen retrieved content (RAG) — Because retrieval can surface PII from your corpus, rely on the output-side policy — and consider redacting the source documents at ingestion — so a Knowledge Base cannot leak indexed personal data.
• 4 — Make logs redaction-aware — Persist the masked form, restrict and encrypt any log that could hold raw input, and scope retention. If using Bedrock model-invocation logging, lock down and encrypt the destination and confirm what it captures.
• 5 — Encrypt and least-privilege everything around it — KMS encryption on storage that touches model I/O, IAM scoped to only the roles that need invoke/read, network controls as appropriate.
• 6 — Version the guardrail in IaC — Define the redaction policy as code, publish numbered versions, reference a specific version at inference time — your auditable, roll-back-able PII policy artifact.

VIITesting the redaction layer — recall, precision, and a regression suite

A PII filter that is never tested is a liability dressed as a control. Both failure modes — letting real PII through, and over-redacting legitimate text — are real, and only testing tells you where you sit.

Before relying on the redaction policy, exercise it. The Bedrock console provides a test window where you submit sample inputs and responses against a draft guardrail and see exactly what is detected, what is masked, and what is blocked — without wiring it into your application. The discipline is to go beyond ad-hoc clicks and build a labelled test set you can run repeatedly (scriptable through the API, including ApplyGuardrail):

• Positive cases (must be caught) — Real-format examples of every entity type you enabled — emails, phones, addresses, SSNs, card numbers — and decoy-laden text for each custom regex (real MRNs, policy IDs). These measure recall: does the filter catch what it must?
• Negative cases (must NOT be caught) — Benign text that looks PII-adjacent — order numbers that resemble card numbers, dates that resemble IDs, common words that resemble names. These measure precision: how often does it over-redact and harm legitimate use?
• Both directions — Test PII in the prompt (does input-side masking remove it before the model?) and PII in simulated responses / retrieved passages (does output-side screening catch model- or RAG-emitted PII?).
• Custom-regex stress tests — Validate each pattern against the real format spec plus near-miss decoys, since a regex is exactly as good as it is written — this is where misses and false hits concentrate.
• Keep it as a regression suite — Re-run the set every time you change the policy, add an entity type, or bump the guardrail version, so a tuning change does not silently open a hole. Pair it with monitoring of real traffic for over-redaction complaints.

The goal is the right balance: high enough recall that real PII does not slip through, high enough precision that you are not masking order confirmations into uselessness. You will not hit perfect on either — so for high-stakes flows keep a human escalation path and layer redaction with the storage/logging controls above rather than treating it as the only line of defense.

VIIILimitations — what PII redaction does not do

The sensitive-information filter is strong and worth defaulting to for anything that touches personal data, but it is bounded. Deploying it well means knowing the edges.

• Detection is not perfect — misses and over-redaction both happen — Managed detectors can miss unusually formatted or obfuscated PII and can over-flag benign look-alikes; custom regex is exactly as good as the pattern. Tuning and testing narrow the gap but never close it — plan for both failure modes.
• Context-dependent entities are hardest — Names in particular are inherently ambiguous (a name can be an everyday word), so name detection is less clear-cut than, say, a card number. Lean on custom regex and structured handling where the format is well-defined, and test names against your real content.
• Language and region coverage varies — Coverage of PII types and quality of detection can differ across languages and regions, and national-ID support varies by country. Test with your actual languages and locales rather than assuming uniform coverage; confirm supported entities per region in AWS docs.
• It does not encrypt or govern your data — Redaction reduces exposure in model interactions; it does not encrypt storage, manage IAM, control your logs, or run your audits. Those are separate controls — redaction is one layer of defense-in-depth, necessary for many regulated cases, sufficient for none on its own.
• Masking is destructive by design — A masked value is gone. If a downstream step genuinely needs the real value, masking will have removed it — so mask only what you mean to protect, and architect any legitimate need for the raw value separately and securely.
• It adds a little latency and cost per call — Screening input and output is extra work on every request. It is usually modest, but for ultra-low-latency or extreme-volume paths it is worth measuring. PII detection is typically one of the cheaper guardrail policies, but it is not free.