8 Prompt Injection Defenses for Cloud LLM Applications
Prompt injection cannot be fully prevented in a cloud LLM application — it can only be contained. Prompt injection holds the top spot in the OWASP Top 10 for LLM Applications 2025 because the flaw is structural: instruction-tuned models read instructions and data in the same context window, so any text they process — a retrieved document, an email body, a tool response — can behave like a command. Working defenses come in layers: probabilistic controls that cut attack success rates, deterministic controls that cap the blast radius, and human approval on irreversible actions. The eight controls below are ranked by how much damage each one removes, and they assume you already run the first-90-days cloud baseline of tight identity, useful logs, and restricted egress.
Why Injection Resists Complete Fixes
Two facts should anchor every design decision you make. First, OWASP’s LLM01 entry is blunt: research shows that retrieval augmented generation and fine-tuning do not fully mitigate prompt injection. Grounding the model in your own documents narrows what it can say; it does nothing to stop a poisoned document from steering what it does. Second, Microsoft separates every control into two classes: probabilistic defenses, which lower the odds an attack succeeds but cannot promise anything, and deterministic defenses, which guarantee a specific impact never happens — for instance, stripping outbound image references at the render layer so an injected markdown tag cannot phone home. Deterministic controls are the only ones you can commit to an auditor.
Eight Defenses, Ranked by Impact
The table below maps each control to its class and its failure mode, because knowing where a defense breaks is half of the decision:
| Control | Class | What it actually blocks | Where it fails |
|---|---|---|---|
| Least-privilege tool scopes | Deterministic | Injected calls cannot reach data the task never needed | Scope creep through shared service accounts |
| Spotlighting untrusted input | Probabilistic | Model confuses external text with instructions | Novel obfuscation and cross-modal payloads |
| Output schema validation | Deterministic | Malformed or exfiltration payloads die in code | Validators written too loosely |
| Guardrail classifiers | Probabilistic | Known injection patterns flagged pre- and post-model | The classifier is itself an LLM and injectable |
| Egress and rendering controls | Deterministic | Markdown-image and clickable-link exfiltration | Covert channels through tool side effects |
| Human-in-the-loop gates | Deterministic | Privileged actions paused for approval | Approval fatigue trains rubber-stamping |
| Grounded RAG with citations | Probabilistic | Content manipulation gets traceable | Does not stop injection itself |
| Adversarial simulation | Detective | Gaps found before release, not in an incident | Stale test corpus misses new techniques |
Spotlighting deserves a closer look because it is cheap: Microsoft’s write-up describes three modes — delimiting untrusted text with randomized markers, datamarking it with repeated tokens, and encoding it so the model still reads it but treats it differently from instructions. None of these is a guarantee, which is why they sit in the probabilistic column.
Rate limiting, by contrast, is a speed bump rather than a wall. According to the OWASP prompt injection cheat sheet, a best-of-N attack study measured 89% success against GPT-4o and 78% against Claude 3.5 Sonnet once attackers get enough attempts, because retries scale while filters do not. Treat per-user quotas as cost control and alerting, never as the control that stops exfiltration.
Architect the Trust Boundary
The controls that hold up under an incident are the ones enforced outside the model. Keep tool credentials in application code rather than in the prompt, scope every tool to the narrowest role that works, and authenticate each sensitive call independently of the agent’s general permissions. The most complete public reference is Microsoft’s Copilot stack: Microsoft’s layered defense pairs hardened system prompts and Spotlighting with Prompt Shields detection and deterministic blocking of known exfiltration channels, then adds explicit user consent where neither detection nor blocking suffices. For agents that read hostile content, the dual-LLM pattern — a privileged model quarantined from untrusted text — trades latency for a real boundary, and research variants such as CaMeL formalize it with capability tracking on data flows. If your agent cannot send email, no injected instruction can make it phish anyone. These boundaries also close the gaps that appear when teams assume the provider handles everything, a failure mode covered in shared responsibility model gaps.
Mistakes That Undo the Stack
- Trusting a system prompt as a boundary. It is persuasion, not enforcement; put the real boundary in code.
- Rendering model output as raw HTML or Markdown. Sanitize at render time and strip image references whose hosts you do not control.
- Testing injection only through the chat box. Indirect payloads belong in the channels the agent actually ingests: fetched pages, tickets, documents, tool output.
- Grading defenses by refusal phrases. A system that refuses everything passes naive tests and fails users; measure the security objective, not the wording.
- Storing secrets in prompts so the model “knows” context. Every token in context is one leak away from disclosure.