A housing chatbot trusts client-supplied “system” role messages sent from the browser. What architecture hardening is most appropriate?
Select an answer to reveal the explanation.
Short Explanation
If the browser gets to write the “system” voice, applicants just became co-authors of your policy. Keep privileged instructions on the trusted server and treat client role claims like untrusted graffiti. Housing chat APIs need hard role separation, not DIY system prompts.
Full Explanation
Chat APIs that accept client-supplied system roles allow callers to override safety, eligibility, or policy instructions that should only be composed on the trusted server. For a housing chatbot, the correct hardening is to ignore client-provided system roles and bind privileged instructions exclusively in server-side prompt construction. User and assistant turns may still flow from the browser, but the authoritative system/policy channel must be server-owned so applicants cannot rewrite municipal rules mid-conversation.
Accepting any role string from the client to maximize personalization fails because personalization does not require elevating the client into the system role; it invites prompt and policy override. Moving system prompts into a public CDN so residents can edit them fails by publishing and democratizing privileged instructions, which undermines policy integrity and consistency across housing determinations. Disabling HTTPS on the chat API to simplify debugging of roles fails on transport security and does nothing to stop forged system roles—it only exposes the traffic.
Exam caveat: some APIs accept a "system" field for convenience; treating that field as authoritative when it originates from the browser is an architecture defect, not a feature. Operational check: strip or reject client system-role fields at the housing API edge, unit-test that injected system messages do not change eligibility or safety instructions, and keep privileged prompt templates in server config or a secrets-backed prompt store.