# Bedrock Guardrail Missing PII / Sensitive-Information Protection

> ZopNight inspects each Bedrock guardrail's DRAFT configuration and raises a high-severity finding when the sensitive-information policy is confirmed "disabled": a guardrail that filters topics but lets names, emails and SSNs pass. Absent enrichment data produces no finding, and the rec claims $0. The gap is safety, not spend.

Source: https://zop.dev/integrations/aws/recommendations/bedrock-guardrail-missing-pii-sensitive-information-protection
Updated: 2026-08-19

---

## Topic filters without a sensitive-information policy

A Bedrock guardrail bundles several independent policies: content filters, denied topics,
word lists, and a sensitive-information policy that catches PII entities and custom regex
patterns. Teams routinely configure the first three and skip the last, leaving a guardrail
that blocks off-topic conversation while personal data (names, emails, phone numbers,
SSNs) flows through both prompts and responses untouched. For any workload whose purpose
includes protecting personal data, that half-configured guardrail is a false sense of
safety, so the finding ships at high severity under the security category.

## Why the DRAFT config is what gets judged

Enrichment calls `GetGuardrail` without a version argument, which returns the DRAFT working
copy, and stamps the result onto the resource as `piiProtection: enabled` or `disabled`.
DRAFT is the current intended configuration and normally sits at or ahead of any published
version, so it is a fair proxy for what production enforces. The known blind edge: if a
protected version was published and DRAFT was later edited to drop the PII policy while
traffic stays pinned to the older version, the rule over-reports. Resolving that would
require knowing which guardrail version production actually invokes, which Bedrock's
control-plane APIs alone cannot tell you. When the flag is absent because enrichment never
ran, the rule stays silent; only a confirmed `disabled` fires.

## Inspecting sensitiveInformationPolicy directly

```bash
aws bedrock get-guardrail --guardrail-identifier gr-abc123 \
  --query 'sensitiveInformationPolicy'
```

`null` reproduces the finding: no PII entities and no regexes are configured on the DRAFT.
Add `--guardrail-version 1` to audit a published version instead of the working copy.

## Block, Mask, and publishing a new version

Add a sensitive-information filter with the PII entity types the workload can encounter,
plus regex patterns for anything domain-specific like account numbers. Choose the action
deliberately: Block rejects the whole exchange, Mask replaces the entity with a tag and
lets the conversation continue, usually the right default for assistants. Then publish a
new guardrail version and move consumers to it; editing DRAFT alone protects nobody until
a version carrying the policy is what production invokes.