Prompt Injection Defense

An LLM can encounter instructions inside a user's request or indirectly inside documents, web pages and tool results. The attacker attempts to make those instructions override the application's intended task. Unlike a conventional parser, the model does not reliably enforce a formal separation between executable instructions and ordinary language. Defense therefore combines contextual guidance with controls outside the model: trusted identity, restricted tools, validated arguments and constrained destinations. The relevant threat is an unauthorized effect, such as disclosure or a transaction, rather than merely unusual wording in an answer. Retrieval does not make third-party instructions trustworthy.

A practitioner maps every untrusted input and identifies what the model can read, send or change after consuming it. They constrain tools to narrow operations, enforce authorization in application code and require appropriate review for consequential actions. Tests should place attacks in realistic retrieved material, metadata and tool responses, including multistep conversations. A useful artifact connects each attack path to an enforceable boundary and a regression case. Input detectors can add coverage, but their failure must not grant the model new privileges or unrestricted network access.

No prompt wording or injection classifier guarantees that the model will ignore every attack. Overly aggressive filters can block legitimate quoted instructions, while attackers can exploit encodings or longer contexts. A defense should be evaluated through prevented disclosure and actions, alongside false rejections. Separating roles in the prompt helps communication, but genuine security boundaries come from the application's identity, permission and execution controls.