Bedrock guardrails with no sensitive-information (PII) policy
What does ZopNight detect here?
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.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1615 |
| Category | security |
| Severity | high |
| Metric | none — pure configuration read |
| Source | bedrock_guardrail_pii.go |
Where it applies
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
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.