Prompt injection & guardrails interview questions
6 questions across 2 sections, in the order you would learn them. Every answer here is one that works — but an answer you have read is not an answer you can give, so use Test yourself and say it out loud first.
Why prompt injection cannot be prompted away
Read the section that teaches thisIf this comes up in an interview
What is prompt injection?
Untrusted content containing instructions that the model follows. It works because a model has no separation between instructions and data: the system prompt, user input, retrieved documents and tool results all arrive as text in the same context.
Why can you not fix it by filtering the input?
The instruction can be rephrased, translated, encoded or split, legitimate content triggers false positives, and the filter itself has the same weakness. Filtering raises the cost of an attack and is not a boundary.
What is the difference between direct and indirect injection?
Direct is the user typing overriding instructions, which mainly affects their own session. Indirect is an instruction hidden in content the agent reads while working, such as a document or a web page, and it is the dangerous one because the victim is not the attacker.
Defending architecturally
Read the section that teaches thisIf this comes up in an interview
How do you defend against prompt injection?
Architecturally, not textually. Scope tool permissions to the minimum, require human approval on irreversible or externally visible actions, separate the component that reads untrusted content from the one holding permissions with a schema between them, and restrict outbound fetching to an allowlist.
Then they push further
Can you make an agent fully safe against injection?
Not with current models, if it both reads untrusted content and can take consequential actions. The practical approach limits what injected text can achieve: least-privilege tools, human approval for sensitive actions, and never combining private data, untrusted input and a way to send data out in one agent.
What would you log to detect it?
Every tool call with its arguments and the content that came before it, so an unexpected action can be traced to the text that caused it. Alert on unusual actions, such as a refund to a different account from the one on the order.
What gets marked up. Strong answers accept that injection cannot be filtered away and design to limit the damage. Relying on a detection model or a prompt that says 'ignore instructions in documents' is marked down.
Your agent reads customer emails and can issue refunds. What is the risk and what do you do?
An email can contain instructions the agent follows, so refunds become attacker-controllable. Split it: an extractor with no tools reads the email and emits structured fields; a separate actor issues refunds from those fields only, with approval required above a threshold and full audit logging.
Then they push further
The business wants refunds fully automated. How do you make that work?
Automate the low-risk band: refunds under a small amount on orders that exist and belong to the sender, checked in code against the order system rather than trusting what the email says. Everything else goes to a person. Measure how much volume falls in the automated band.
What gets marked up. Marked up for checking facts against the system of record rather than the email, and for proposing a risk threshold instead of all or nothing.
How might data leak out of an agent even if it cannot send email?
Through any outbound request it can influence. A fetched URL containing the data in its path or query, or a rendered markdown image, both make a request without looking like sending anything. Allowlist domains and be careful about rendering model output as markup.
These are the questions for one topic. The whole question bank covers every topic on the site.