AWS bedrock documentation change
Summary
Added clarification note about PII masking limitations in Bedrock guardrails - masking doesn't apply to model invocation logs or guardrails trace output
Security assessment
This change adds important security documentation about the scope of PII protection in Bedrock guardrails, clarifying that sensitive data may still appear in logs and trace outputs. This is a documentation clarification rather than addressing a specific security issue.
Diff
diff --git a/bedrock/latest/userguide/guardrails-sensitive-filters.md b/bedrock/latest/userguide/guardrails-sensitive-filters.md index c069a6354..1b5c6ad54 100644 --- a//bedrock/latest/userguide/guardrails-sensitive-filters.md +++ b//bedrock/latest/userguide/guardrails-sensitive-filters.md @@ -178,0 +179,11 @@ The PII model performs more effectively when it is provided with sufficient cont +###### Note + +PII masking applies only to content that is sent to the inference model (input prompts) and content that is returned from the inference model (model responses). It does not apply to the following: + + * **Model invocation logs** — If you enabled [Monitor model invocation using CloudWatch Logs and Amazon S3](./model-invocation-logging.html), the `input` field in Amazon CloudWatch Logs always contains the original, unmodified request regardless of guardrail intervention. To protect sensitive information in your logs, use [Amazon CloudWatch log data protection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/mask-sensitive-log-data.html). + + * **Guardrails trace output** — The `match` field in [GuardrailPiiEntityFilter](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_GuardrailPiiEntityFilter.html) that is returned in API responses (such as the `trace` object of the Converse API) contains the original PII value, not the masked output. This behavior is by design so that your application can use the detection result for its own logic. + + + +