LLM Security Interview Questions (2026): 15 Questions on Prompt Injection and More

A 5-step way to answer any LLM security question

Identify the asset. Data, actions, money or reputation that an attacker wants.
Trace the path. Where untrusted text enters (user, documents, web pages, tool results).
Assume the model fails. Design so a fooled model still cannot cause serious harm.
Layer controls. Least-privilege tools, approvals, output validation, filtering and monitoring.
Test it. Red teaming, adversarial test sets and regression checks on every release.

Contents: Prompt injection (questions 1 to 4) · Data and output risks (questions 5 to 8) · Agents and tools (questions 9 to 11) · Testing and operations (questions 12 to 15)

Prompt injection (questions 1 to 4)

1. What is prompt injection?

Input that causes the model to follow attacker instructions instead of the developer's.
Direct injection comes from the user; indirect injection hides in content the model reads, such as web pages, emails or documents.
It works because models do not reliably separate instructions from data in the same context.
OWASP lists it first in its Top 10 for LLM Applications.

Common pitfall: Saying a stronger system prompt solves it.

2. Why is indirect prompt injection especially dangerous for agents?

Agents read untrusted content and also have tools that can act or send data.
Hidden instructions can make the agent exfiltrate data or take unwanted actions.
The user may never see the malicious text.
Defense must limit what the agent can do, not only what it reads.

Common pitfall: Only scanning user input and ignoring retrieved and tool content.

3. How do you defend against prompt injection?

Least privilege: give tools minimal scopes and per-user credentials.
Require human approval for sensitive or irreversible actions.
Mark untrusted content clearly, filter known patterns and validate outputs and tool arguments in code.
Restrict outbound destinations to block data exfiltration, and monitor for anomalies.

Common pitfall: Claiming any single filter fully prevents injection.

4. What is the difference between a jailbreak and prompt injection?

A jailbreak tries to make the model break its safety policies, for example producing harmful content.
Prompt injection hijacks the application's intended task, often to misuse its data or tools.
The techniques overlap, but the impact differs: policy violation versus application compromise.
Both need testing, and controls outside the model.

Common pitfall: Treating the two as identical and missing the tool-misuse risk.

Data and output risks (questions 5 to 8)

5. How can an LLM application leak sensitive data?

Through retrieval that ignores user permissions.
Through system prompts or secrets placed in the context and then revealed.
Through logs, training on user data without consent or tool calls that send data out.
Controls: permission filters at retrieval, no secrets in prompts, redaction and data retention rules.

Common pitfall: Putting API keys or private rules in the system prompt and assuming they stay hidden.

6. What is insecure output handling?

Passing model output directly into a browser, shell, SQL query or API without validation.
It can lead to cross-site scripting, command injection or unintended API calls.
Treat model output like user input: escape, validate against schemas and use parameterized queries.
Sandbox code execution.

Common pitfall: Rendering model-generated HTML without sanitization.

7. How do you enforce document permissions in RAG?

Store access metadata with each chunk and filter by the user's permissions at query time.
Enforce filtering in the retrieval layer, not in the prompt.
Keep permissions in sync with the source system and handle revocations.
Test with users who should not see certain documents.

Common pitfall: Retrieving everything and asking the model not to mention restricted content.

8. What is training data poisoning?

An attacker inserts malicious or biased data into training or fine-tuning data.
It can create backdoors or degrade behavior on specific triggers.
Mitigate with data provenance, filtering, review of fine-tuning sets and evaluation on trigger tests.
The same idea applies to poisoning a RAG corpus.

Common pitfall: Ignoring that retrieved documents can also be poisoned.

Agents and tools (questions 9 to 11)

9. What is excessive agency?

Giving an LLM system more permissions, tools or autonomy than its task needs.
A fooled or buggy model can then do real damage.
Limit tools, scopes and rate, and require approval for high-impact actions.
Log every action for audit.

Common pitfall: Giving an agent admin-level credentials for convenience.

10. How do you secure tool calls?

Validate every argument in code against a schema and business rules.
Check authorization for the end user, not for the agent's service account alone.
Make actions idempotent and reversible where possible.
Set budgets and rate limits per session.

Common pitfall: Executing whatever arguments the model produces.

11. What risks come with third-party plugins or MCP servers?

A tool description or result can carry injected instructions.
A compromised or malicious server can request excessive data or actions.
Review and pin trusted servers, limit their scopes and isolate credentials.
Monitor which tools are called and with what data.

Common pitfall: Installing any community tool server without review.

Testing and operations (questions 12 to 15)

12. What is red teaming for LLM applications?

Structured adversarial testing to find harmful outputs, injections, leaks and misuse paths.
Combine manual testers with automated attack generation.
Turn findings into regression test sets that run on every release.
Prioritize by impact and likelihood.

Common pitfall: Running red teaming once before launch and never again.

13. What are guardrails and where should they live?

Checks on inputs, retrieved content, tool calls and outputs.
They can be rules, classifiers or LLM-based checks.
The critical ones live in code and infrastructure, not only in the prompt.
Measure false positives so guardrails do not block legitimate users.

Common pitfall: Relying on prompt instructions as the only guardrail.

14. How do you monitor an LLM application for abuse?

Log prompts, retrieved sources, tool calls and outputs with privacy controls.
Alert on unusual tool usage, data volume or repeated policy hits.
Rate limit and add abuse detection per user or API key.
Have an incident process to revoke access and patch quickly.

Common pitfall: Logging nothing because of privacy concerns instead of logging safely.

15. How would you threat model a customer support chatbot with refund tools?

Assets: customer data and money; attackers: users and anyone who can inject content.
Risks: injection leading to unauthorized refunds or data leaks across customers.
Controls: per-customer data scoping, refund limits, approvals above a threshold and validation in code.
Tests: adversarial prompts and tickets with hidden instructions.

Common pitfall: Discussing only content safety and ignoring the refund tool.

Go deeper on related questions

FAQ

Is prompt injection solved?

No. It is mitigated by layered controls; current models cannot reliably separate instructions from data, so systems must limit the impact.

What is the OWASP Top 10 for LLM Applications?

A community list of the main security risks for LLM applications, including prompt injection, sensitive information disclosure, improper output handling and excessive agency. Know the main categories.

Do I need security experience for AI engineer roles?

You need the basics: untrusted input, least privilege, output validation and permissions. Senior roles expect threat modeling.

How do I practice?

Take one of your projects, list where untrusted text enters, and design controls that hold if the model is fooled.

The PlaybookWant the full method?

The 0 to 1 AI Engineer Interview Playbook covers answer frameworks, system-design walkthroughs and an 8-week plan. $19.99 on Gumroad.

Get the playbook

All interview topics · Prep guides · Question deep dives · Free 50 RAG and LLM questions