LLM Security Interview Questions on Prompt Injection and Defenses

Interviewers ask about LLM security because the failure is easy to demonstrate and hard to fix. The short version of the best answer: you can't make the model reliably refuse every malicious instruction hidden in its input, so you design the system so that a model that has been fooled still can't do much harm. Everything below is practice material for that conversation, with a script that shows one such control working.

These questions are written for this site as practice. They aren't leaked, and they aren't from any company. The post is deliberately conceptual: there are no attack strings in it, because you don't need them to explain a defence. If you want the build-side detail afterwards, read prompt injection defense for production systems and prompt injection in tool-using agents. For the basics, see the prompt injection lesson.

What source is this based on?

The reference point is the OWASP Top 10 for LLM Applications, 2025 edition. I read its prompt injection page (LLM01:2025) and the index page of the project's list on 2026-10-09, fetched with curl as plain page text. Where I attribute something to OWASP below, it comes from those two pages. Where I give my own view, I say so. OWASP's 2025 list names these ten risks:

I only read the one-line summaries for entries other than LLM01, so for those I stick to what the summaries say and mark the rest as my reasoning. Lists get revised; check the OWASP GenAI Security Project page for the current version before an interview.

Q1: What is prompt injection, and how is it different from jailbreaking?

Strong answer outline

• Prompt injection: inputs that alter the model's behaviour or output in unintended ways. OWASP adds that the inputs don't have to be readable by humans, as long as the model parses them.
• Jailbreaking, per OWASP, is a form of prompt injection where the input makes the model disregard its safety protocols. People often use the two terms interchangeably, and OWASP says so.
• The root cause is that instructions and data share one channel: text in a context window. There's no hardware-style separation like the one between code and data in a classic injection bug.

Follow-up: Why is this different from SQL injection? SQL injection has a structural fix (parameterised queries) because the parser can tell code from data. A model has no equivalent parser. That's my framing, and it explains why OWASP's page speaks of mitigating impact rather than preventing the issue.

Common weak answer: "It's when users trick the chatbot into saying bad words." That's one case. The serious cases are about actions and data, not language.

Q2: Direct versus indirect injection: which worries you more?

Strong answer outline

• Direct: the user's own prompt changes behaviour. OWASP notes it can be intentional or unintentional.
• Indirect: the model accepts input from external sources such as websites or files, and that content alters its behaviour. Also intentional or unintentional.
• Indirect is the one to name for agents, because the person typing may be entirely innocent. They asked for a summary, and the document did the rest.
• OWASP's own scenarios include a summarised web page that causes private conversation data to leak, and a modified document in a RAG repository that skews answers. It also includes an unintentional case: an instruction placed in a job description to catch AI-written applications ends up affecting an applicant who just used an LLM to polish their resume.

Follow-up: Which data sources in your product are untrusted? A good candidate lists them: emails, tickets, uploaded files, web pages, retrieved chunks, tool outputs, and other agents' messages. If you can't list them, you can't draw the trust boundary.

Q3: Can't you just tell the model to ignore malicious instructions?

Strong answer outline

• You should still write a clear role and constraints. OWASP's first mitigation is exactly that: specific instructions on role, capabilities and limits, and an instruction to ignore attempts to change core instructions.
• But it's a mitigation of likelihood. OWASP says that, given the stochastic nature of models, it's unclear whether fool-proof prevention exists.
• So the second half of the answer matters more: assume the instruction layer fails sometimes and ask what the worst outcome is when it does.

Follow-up: What does RAG or fine-tuning do for injection? OWASP states that research shows RAG and fine-tuning don't fully mitigate it. They improve relevance and accuracy, not robustness to hostile input.

Common weak answer: "We'll put it in the system prompt in capital letters." Emphasis isn't a control.

Q4: Walk me through your defences, in order

This is the central question. A clean structure beats a long list. OWASP's page lists seven mitigations, and here they are in the order I'd say them, with the kind of control each one is:

My reading of this table, and the way to score points: output validation, least privilege and human approval run outside the model's judgement. Those are the ones you can reason about with certainty. A candidate who answers with prompt wording only has described the top row of the table.

Follow-up: Which two would you ship first if you had one week? A defensible answer is least privilege plus human approval on anything irreversible, since both limit blast radius whatever the model does. Say why, and say what you'd add next.

Q5: Design question: an assistant reads a user's inbox and can send email. What's the risk and what do you build?

Interviewers like this one because the answer is a design, not a definition.

Strong answer outline

1. Name the threat in one sentence. Anyone who can email the user can put text in front of the model. That makes every inbound message an indirect injection channel, and "send email" is an exfiltration route.
2. Split capabilities by task. Summarising the inbox needs read access, not send. Drafting a reply may need send, but only to approved recipients.
3. Enforce in code. Check each tool call the model proposes against an allowlist after the model proposes it and before anything runs.
4. Gate irreversible actions. A human confirms sends and deletions.
5. Log and alert. Record every proposed and executed tool call so you can spot a session with unusual behaviour.

Here is a minimal gate for steps 2 to 4. I ran this on 2026-10-09 with Python 3:

ALLOWED_RECIPIENT_DOMAINS = {"example-corp.test"}
NEEDS_HUMAN = {"send_email", "delete_record"}
TOOLS_FOR_TASK = {"summarise_inbox": {"read_email", "search_kb"},
                  "draft_reply": {"read_email", "search_kb", "send_email"}}

def gate(task, tool, args, human_approved=False):
    """Deterministic checks that run in code, after the model proposes a call."""
    if tool not in TOOLS_FOR_TASK.get(task, set()):
        return False, "tool not granted for this task"
    if tool == "send_email":
        domain = args["to"].rsplit("@", 1)[-1].lower()
        if domain not in ALLOWED_RECIPIENT_DOMAINS:
            return False, f"recipient domain {domain!r} not on allowlist"
    if tool in NEEDS_HUMAN and not human_approved:
        return False, "needs human approval"
    return True, "ok"

cases = [
    ("summarise_inbox", "send_email", {"to": "a@example-corp.test"}, False),
    ("draft_reply", "send_email", {"to": "x@other.test"}, True),
    ("draft_reply", "send_email", {"to": "a@example-corp.test"}, False),
    ("draft_reply", "send_email", {"to": "a@example-corp.test"}, True),
    ("draft_reply", "read_email", {"id": 7}, False),
]
for task, tool, args, ok in cases:
    print(f"{task:16s} {tool:11s} approved={ok!s:5s} -> {gate(task, tool, args, ok)}")

Output:

summarise_inbox  send_email  approved=False -> (False, 'tool not granted for this task')
draft_reply      send_email  approved=True  -> (False, "recipient domain 'other.test' not on allowlist")
draft_reply      send_email  approved=False -> (False, 'needs human approval')
draft_reply      send_email  approved=True  -> (True, 'ok')
draft_reply      read_email  approved=False -> (True, 'ok')

Read the second line closely: even with human approval, the call is refused because the recipient domain isn't allowed. The gate doesn't care why the model wanted that address. That is the point. It's a sketch of one control, not a product. A real one also needs identity, auditing, handling of address spoofing and lookalike domains, and a confirmation UI that shows the human the real recipient and body.

Follow-up: The human approves everything without reading. Now what? Good question to anticipate. Approval fatigue is real. Reduce the number of prompts by auto-allowing low-risk read actions, and make the confirmation show exactly what will leave the system. That answer comes from reasoning, not from a study I can cite.

Q6: What are improper output handling and excessive agency?

Both are separate entries on OWASP's 2025 list. Going by the index summaries I read:

• LLM05 Improper Output Handling is about insufficient validation, sanitisation and handling of model outputs. My interpretation: whatever the model emits is untrusted input to the next component. If you pass it to a shell, a database, a browser or another service, apply the same validation you'd apply to user input there.
• LLM06 Excessive Agency is about a system being given the ability to call functions or interact with other systems. My interpretation: grant the smallest set of tools, with the narrowest parameters, that the task needs.

Follow-up: How do these combine with injection? Injection is the way hostile text gets in. Excessive agency and weak output handling are how it turns into real damage. Fixing the latter two shrinks the consequences of the first, which is why a sensible answer spends more time on them than on detecting injection.

Q7: Should anything sensitive live in the system prompt?

OWASP lists System Prompt Leakage (LLM07) as a risk in its own right, and its injection page includes revealing system prompts among possible impacts. My position, which is not an OWASP quote: write the prompt as if a user will read it. Keep secrets, credentials and access rules out of it. Make authorisation decisions in code, where "the model was persuaded" cannot override them.

Follow-up: Then why bother with a system prompt? For behaviour and tone, not for security. The model follows it most of the time, which makes it great for product quality and poor as a lock.

Q8: What is unbounded consumption, and is it a security issue?

OWASP names Unbounded Consumption (LLM10); the index summary I read is cut off after "generates outputs based on input queries or", so I'm relying on the name. My reasoning for an interview: a security person cares because a single user or an injected loop can run up cost or exhaust capacity. Name concrete controls: per-user rate limits, maximum input and output tokens, per-session budgets for agents, request timeouts, and alerts on spend. For the abuse-prevention side, see rate limits for a free-tier AI app, and for per-session budgets on agent loops see token budgeting for agents.

Q9: How would you test for prompt injection without a list of magic strings?

Strong answer outline

• Start from the data flow, not a payload library. List every untrusted input and every tool with side effects, then ask for each pair: if this text tried to cause that action, what stops it?
• Treat the model as an untrusted user. OWASP's phrasing for the adversarial-testing mitigation is to test trust boundaries and access controls this way.
• Test the controls, not only the model. A unit test for the tool gate above is more reliable than any number of model prompts, because it's deterministic.
• Keep regression cases in version control, and rerun them when you change the model, the prompt or the tools. See red-teaming your agents for a working process.

Common weak answer: "I'd run a jailbreak dataset." Datasets help with coverage, but a pass rate on a public set says nothing about your tool permissions.

How to score a practice answer

Use this when a friend plays interviewer. It's my own rubric, not any company's.

What I could not verify

I read OWASP's LLM01:2025 page in full and the project's list page on 2026-10-09, as text fetched by curl. I did not read the pages for LLM02 to LLM10, so my notes on those rely on one-line summaries plus my own reasoning, flagged as such. I haven't checked whether OWASP has newer material than what those pages showed. The gate script is a sketch that I ran as shown; it has not been security-reviewed.