Before launching a resident chatbot that answers tax questions, what security activity should the team perform early in design?
Select an answer to reveal the explanation.
Short Explanation
Chatbots get weird prompts and leaky memories if you never threat-model them. Sketch the abuse cases—prompt injection, data bleed—while you're still designing, not after residents are chatting about taxes. Early modeling is cheaper than apologizing.
Full Explanation
Early in design of a resident chatbot that answers tax questions, the team should threat-model abuse cases—including prompt injection, jailbreaks, and sensitive data leakage—before deployment. Conversational interfaces expand the attack and error surface: malicious prompts may elicit confidential records, bypass intended topic limits, or manipulate downstream tools if the bot is connected to tax systems. Disabling all logging to avoid discovery risk removes detective capability and hinders incident response. Publishing the full tax database to simplify answers creates unnecessary exposure. Postponing security review until after civic awards treats assurance as optional cosmetics rather than a design activity. Exam caveat: CISSP and modern secure design expect threat modeling during architecture—especially for new AI-enabled citizen services—not only after go-live. Operational check: model trust boundaries between users, the model, retrieval stores, and backend tax APIs; define data minimization and output filtering; test prompt-injection and exfiltration cases; and require security sign-off before production. Log security-relevant events with privacy-aware retention, and revisit the model when connectors or data sources expand.