Exam-style
A claims assistant on Bedrock regularly receives customer names, addresses and policy numbers in free-text input, and that same text lands in the model invocation logs. The organisation wants one PII policy applied to every model call, on the prompt and on the response, rather than twelve bespoke implementations in the calling applications. What is the built-in Bedrock control?
Reveal the answer
C. A Bedrock Guardrail with a sensitive-information policy set to mask or block PII on input and output
The Guardrail sensitive-information filter is the built-in control: one versioned policy, defined once, masking or blocking PII in the prompt before it reaches the model and in the response before it is returned. Getting it onto every call does not take twelve code changes. An AWS Organizations Amazon Bedrock policy references a numeric guardrail version from the management account and enforces it on every model invocation in the OUs or accounts it is attached to. A single account sets the same thing for itself with account-level enforcement. Where a caller passes the identifier and version on the request instead, the bedrock:GuardrailIdentifier condition key on InvokeModel and Converse denies a call that omits it. Masking stops at inference. The input field of a Bedrock invocation log in CloudWatch Logs holds the original, unmodified request whatever the guardrail did, so the logs need a data protection policy of their own. Macie and Comprehend both detect PII, but they run after the fact over data already written. A Lambda in front returns the detection logic to bespoke code that twelve teams then depend on. Tightening the bucket policy limits who can read the leak rather than preventing it, which is why the log store gets a customer managed KMS key and tight access on top of the Guardrail, not instead of it.
Q. Keep customer PII out of prompts and logs. What is the built-in control?
A. A Bedrock Guardrail with a sensitive-information filter masks or blocks PII in the prompt before it reaches the model, and in the response before it is returned. The policy is defined once as a versioned resource. An AWS Organizations Amazon Bedrock policy then enforces a numeric version of it on every model invocation in the OUs or accounts it is attached to, with no change to the twelve calling applications. One account on its own gets there with account-level enforcement. Where a caller passes the identifier and version on the request instead, the bedrock:GuardrailIdentifier condition key on InvokeModel and Converse denies a call that omits it. Masking stops at inference. The input field of a Bedrock invocation log in CloudWatch Logs holds the original, unmodified request whatever the guardrail did, so mask the logs separately with a data protection policy. Encrypt the log store with a customer-managed KMS key.
Why? The log that proves compliance can itself leak, and guardrail masking does not reach it.