A housing-authority chatbot must never reveal applicant SSNs even when residents type free-form questions. Which prompt control best enforces that boundary?

Preventing disclosure of applicant SSNs in free-form resident questions is best enforced with a fixed system prompt that forbids revealing SSNs regardless of user prompt content. System-level instructions establish a durable policy boundary the model is expected to honor even when users attempt to override it through clever wording. A user-role instruction that forbids disclosing SSNs during the resident support dialogue fails because a user-role instruction is untrusted and cannot be the source of privacy enforcement; it does not bind the model across dialogues or override a fixed system policy. A retrieved policy excerpt that forbids disclosing SSNs for grounding model responses fails because adding retrieved policy text does not stop disclosure in the answer path—the harm is the revealed identifier, and grounding passages are untrusted data, not an enforcement boundary that survives missing retrieval or conflicting user wording. A few-shot demonstration that forbids disclosing SSNs by modeling redacted replies fails because imitation examples guide style but do not enforce non-disclosure; the model may still reveal a full SSN when free-form wording differs from the examples and the examples create no reliable refusal boundary. Exam caveat: prompt controls are necessary but not sufficient; models can still leak identifiers present in context, so redaction, retrieval filters, and output scanners should layer with the system prompt. Operational check: maintain a locked system prompt under change control, test jailbreak-style SSN extraction cases, strip SSNs from retrieved housing records before prompt assembly, and alert on any response that matches SSN patterns.