A 311 email from the public embeds text trying to make Copilot reveal internal escalation contacts. What responsible-AI concern does this raise?
Select an answer to reveal the explanation.
Short Explanation
When you use resident email with Copilot, remember that embedded instructions may try to extract internal contacts. Treat this as prompt injection and keep internal lists out of blindly pasted threads.
Full Explanation
A 311 email that embeds instructions to make Copilot reveal internal escalation contacts raises prompt injection through external resident content: untrusted inbound messages can carry instruction-like text that tries to extract internal information. If you feed resident email into Copilot, treat it as potentially manipulative content, not trusted policy text. The claim that Copilot automatically publishes all escalation contacts to the city’s open-data portal goes beyond the scenario; an attempted extraction is not proof of automatic publication. A successful citation check confirming that the escalation list came from SharePoint permissions also does not fit: the concern is the embedded instruction, not a citation-validation success or proof of SharePoint access controls. Over-reliance risk only, based on the claim that resident email cannot influence Copilot prompts, is incorrect; external content can influence prompts when pasted or used as context, and the specific risk here is an attempt to obtain internal contacts. Exam caveat: when outsider text tries to force disclosure of internal data, identify prompt injection rather than an asserted open-data publication, a successful SharePoint citation check, or over-reliance alone. Practical check: keep escalation lists out of prompts containing raw 311 email, sanitize or summarize resident messages before using Copilot, and verify any returned contact against the internal directory rather than the resident’s embedded instructions.