Guard an LLM Feature Against Prompt Injection
Added 2026-11-05
User input and tool output are untrusted; so is whatever the model returns.
My feature sends user input and third-party content to a model: [data flow]. Assess injection and privilege-escalation risk: 1) list every untrusted source that reaches the prompt; 2) point out where data and instructions share one channel; 3) give layered defenses — input cleaning, separating instructions from data, a tool-call allowlist, output validation; 4) describe the worst a manipulated model could do, and whether current permissions contain it; 5) three injection tests I can actually run; 6) defenses that are only comfort. Do not stop at "add a system prompt".
Site original
Chinese original
Replace these placeholders 1
Swap the bracketed parts for your own details before sending.
[data flow]
How to use
The point of injection defense is not making the model obey; it is making dangerous actions impossible even when it does.
Try tweaking it
- Have it restate requirements and constraints before writing code.
- Ask for the smallest change plus a rollback path, not a full-file rewrite.
What you should get
- A minimal, runnable change with copy-ready code
- Impact list: which files and call sites must follow
Common mistakes
- Asking it to touch ten files at once, then losing track of what broke what.
- Pasting only the error, with no code or version, and getting an unfixable answer.
How to check the output
- The change runs, can be rolled back, and touches nothing unrelated.
- Edge cases (empty, oversized, concurrent) are covered or explained.
Where it works
- Good for: having it restate requirements and constraints, then propose the smallest runnable change.
- Watch out: include versions and a minimal reproduction with the error, or the fix may look plausible but not fit.