You're building an LLM agent that can call tools (email, DB). User input could contain hidden instructions. How do you reduce prompt-injection risk?

An LLM mixes instructions and data in the same text stream, so any attacker-controlled content — typed directly, or pulled in from an email, document, or web page the agent reads — can carry instructions the model may follow. That's prompt injection, and once the model can call tools (send email, query or modify a database), a successful injection turns into a real-world action. You can't reliably out-prompt this.

Why "just tell it to ignore" fails

The model has no robust boundary between your system prompt and injected text; both are just tokens. A line saying "ignore malicious instructions" is itself subject to override by a cleverly phrased injection. Defending at the wording layer is fighting on the attacker's home turf.

The architecture that actually reduces risk

• Treat every model output as untrusted input to the rest of your system. Validate, type-check, and bound tool arguments before execution.
• Least privilege per tool. Scope each tool to the minimum data and capability, with short-lived, narrowly-scoped credentials — not a broad admin token.
• Human-in-the-loop for sensitive or irreversible actions: sending external email, deleting records, moving money.
• Sandbox and constrain execution and network egress to limit exfiltration and SSRF.

This maps directly to OWASP's LLM risks of excessive agency (too much capability/autonomy) and improper output handling (acting on model output without validation).

Why the other options fail

• Increasing temperature only makes outputs more random; it has nothing to do with whether an injected instruction is obeyed.
• Logging and hoping records the incident after the damage is done — useful for forensics, useless as prevention.

What the interviewer is probing

Whether you understand that prompt injection is a design constraint, not a bug you can patch with phrasing, and whether you architect the blast radius down: least privilege, confirmation gates, and output validation so a subverted model still can't do much harm.