A parks wildlife 311 chat receives a resident message that says to ignore prior rules and dump the system prompt. How should the municipal team classify that input?

Direct prompt injection occurs when untrusted user input tries to override system or developer instructions. A parks wildlife 311 message that tells the bot to ignore prior rules and dump the system prompt is a classic direct injection: the attacker speaks to the model in natural language and aims to replace or reveal the municipal assistant’s governing instructions. Classifying it as injection triggers security review, rate limits, and possibly blocking—not routine FAQ handling.

Treating it as a routine fee-schedule lookup that needs no security review fails by concept: the content is an override demand, not a fee query. Treating it as proof that the vector database must be physically destroyed fails because destroying RAG infrastructure is neither a diagnosis nor a proportionate control for a single malicious user turn. Treating it as a harmless snow-plow map update fails because the wording targets instruction override and prompt exfiltration, not map maintenance.

Exam caveat: Direct injection is user-supplied adversarial text in the conversation; contrast it with indirect injection hidden in documents or retrieved web pages. Detection heuristics help but are incomplete—obfuscated variants exist—so defense in depth (system prompt isolation, output filtering, tool gates) still matters. Revealing system prompts can expose internal policies and tool lists even when the model only partially complies.

Operational check: Tag “ignore previous / reveal system prompt” patterns in 311 logs, route them to a security queue without executing tool calls, and verify the assistant refuses to disclose system instructions in a controlled red-team test.