Home / Question bank / AI System Design
What is prompt injection and how do you defend against it?
30-second answer
It's when input causes the model to follow attacker instructions instead of the developer's. Indirect injection arrives through content the model reads (web pages, emails, documents). Defences limit impact rather than eliminate it: treat external content as data, least-privilege tools scoped to the user, human confirmation for consequential actions, block data exfiltration channels like auto-loaded URLs, injection classifiers as one layer, and red-team testing.
Try answering out loud before reading on. The walkthrough below is paced for a 40-minute interview round.
Architecture diagram
Sketch this on the whiteboard as you talk through the answer. See all AI architecture diagrams →
Scroll sideways to see the whole diagram.
0–5 min Clarify and frame
Ask what the system can do: just chat, read untrusted content (web, email, documents), or take actions with tools? Framing: "Prompt injection can't be fully prevented today, so the design goal is limiting what a successful injection can do."
5–15 min Core explanation
Prompt injection: input causes the model to follow attacker instructions rather than the developer's.
- Direct: the user types "ignore previous instructions and…". Mostly a policy/jailbreak problem.
- Indirect: instructions hidden in content the model processes: a web page, an email, a PDF, a code comment, a tool result. The user may be the victim.
Why it's hard: models process instructions and data in the same token stream; there's no reliable hard boundary, and attackers can obfuscate (encoding, other languages, invisible text).
Impact depends on capabilities: data exfiltration, unauthorized actions (sending emails, making purchases), misinformation shown to users.
15–25 min Deep dive: defence in depth
| Layer | Controls |
|---|---|
| Architecture | Least privilege tools scoped to the current user; separate read-only and write agents; avoid combining private data + untrusted content + external send |
| Human-in-the-loop | Explicit confirmation for consequential actions, showing exactly what will happen |
| Data handling | Delimit untrusted content; tell the model it's data; strip hidden text/markup where possible |
| Output channels | Block auto-loading external images/links in rendered output; allowlist domains; no secrets in context |
| Detection | Injection classifiers on retrieved/tool content; anomaly detection on tool-call patterns |
| Model choice | Models trained for instruction hierarchy and injection robustness |
| Monitoring | Log tool calls with provenance; alert on unusual actions |
| Testing | Red-team suites with indirect injection payloads; track attack success rate |
Dual-LLM / quarantine pattern: a privileged model plans and calls tools but never reads raw untrusted text; a quarantined model processes untrusted content and returns only structured, validated data.
25–32 min Trade-offs
- Confirmations add friction; reserve for consequential actions.
- Classifiers have false positives and can be evaded; never the only layer.
- Restricting tools reduces usefulness; design capability tiers by risk.
32–37 min Production example
An email assistant could read the inbox and draft replies. A red-team email contained hidden text telling the assistant to forward the latest invoice to an external address. Controls that stopped it: the assistant had no forward tool, sending required user confirmation with the recipient shown, and external links in drafts were flagged. The team added the payload to their regression suite.
37–40 min Likely follow-ups
- Can a better system prompt fix it? It helps marginally; not a security boundary.
- How would you measure robustness? Attack success rate on a maintained adversarial suite, before each release.
What interviewers listen for
- Distinguishing direct vs. indirect injection.
- Blast-radius thinking: permissions, confirmations, exfiltration channels.
Red flags
- "Add 'ignore malicious instructions' to the prompt."