A housing authority's casework assistant must never surface an applicant's Social Security number in a generated response, even when that number appears in the retrieved case notes the model is grounded on. Which control addresses this directly?
Select an answer to reveal the explanation.
Short Explanation
A guardrail is the bouncer standing at the door of every response, checking it against a list before it goes out. It doesn't matter that the sensitive number showed up in the retrieved notes — the bouncer catches it before a resident-facing screen ever displays it. That's the control built for exactly this job.
Full Explanation
Guardrails let a team define sensitive-information filters that pattern-match against categories like government ID numbers and either block or mask matches in the generated response, which addresses the leak at the point where it would actually reach the caseworker — regardless of whether the number originated in the prompt, the retrieved context, or the model's own output. Restricting the S3 bucket to a single role controls who can read the raw case notes directly, but it does nothing to stop the model from including retrieved content in a generated answer once that role's application has legitimately pulled the notes for grounding. Enabling CloudTrail logging on invocations creates an audit record after the fact, which supports investigation but does not prevent the sensitive value from appearing in the response in the first place — it's detective, not preventive. Increasing retrieval chunk size changes how much text is pulled per query and has no relationship to whether sensitive fields within that text get filtered out of the final response. Scope caveat: guardrail pattern coverage should be tested against the specific formats case notes actually use, since a filter tuned for one format can miss a variant. Operational check: run a test query designed to surface a known sensitive value and confirm the guardrail blocks or masks it before treating the control as verified.