AI Security Interview Questions in 2026: Prompt Injection, Agents and Governance

AI security interviews are not machine learning interviews. Nobody is going to ask you to derive backpropagation. What they are testing is whether you can reason about a new class of untrusted input - model output, retrieved documents, tool calls - inside an otherwise ordinary application. The role is application security for systems that can be talked into doing things. This guide covers the scenarios that come up across the three sub-roles hiring today - securing AI systems, AI red-teaming, and AI governance → - what the interviewer is listening for, and what to ask back.

The attack and design scenarios (the core of the interview)

• "Our support chatbot reads customer tickets and can call an internal refund API. How would you attack it, and how would you fix it?" This is the indirect prompt injection question, and it is the single most common scenario in the loop. The attack: the attacker does not talk to the model at all - they write the ticket. Text retrieved from a document, a web page, an email, or a database row reaches the model with the same authority as the system prompt. The answer that fails is "I would filter malicious instructions from the input." There is no reliable classifier for "instruction," the attack surface is natural language, and every filter you write is one paraphrase away from bypass. The answer that lands is architectural: treat model output as untrusted input, scope the refund tool with its own least-privilege credentials and hard limits, require human approval for consequential or irreversible actions, and make the blast radius of a fully jailbroken model acceptable rather than betting the system on the model never being jailbroken. Filtering is defense in depth, never the control.
• "We are giving an agent shell access in a build environment. What is your threat model?" Excessive agency and tool abuse. They want to hear you enumerate what the agent can reach rather than what it is supposed to do: which credentials sit in that runtime, what the network egress policy is (an agent that can make arbitrary outbound requests is an exfiltration channel for everything in its context), whether secrets are in environment variables the model can read and then print, whether tool calls are logged and attributable, and what happens when a chained call sequence produces an effect no single call would have been approved for. Sandboxing, short-lived scoped credentials, an allowlist of tools per task, and egress control are the mitigations. Say plainly that the agent's permissions are the real security boundary, not its instructions.
• "Our RAG system indexes the whole company wiki and serves every customer. What goes wrong?" Data boundaries. Retrieval typically happens before authorization is considered, so the index becomes a flat namespace where anyone's query can surface anyone's document. Two failures to name: internal over-sharing, where the model cheerfully summarizes the HR folder that was technically readable but never actually read, and multi-tenant leakage, where tenant A's embeddings and tenant B's live in one store. The fix is enforcing the same authz the source system enforces - filter at retrieval time against the requesting user's permissions, partition per tenant, and re-check on the way out rather than trusting the model to keep a secret it has already been handed.
• "A team wants to pull a model off a public hub and run it in production. What do you require first?" Supply chain, and it is the scenario most candidates have not thought about. Model weights are code-adjacent artifacts: pickle-based formats deserialize arbitrary objects, so loading an untrusted checkpoint is remote code execution on your inference host. Ask for provenance (who published it, is the repo the one you think it is, is there a signature or hash you can pin), prefer formats that do not execute on load, scan and load in an isolated environment first, and pin versions the same way you pin a dependency. Extend it to datasets and fine-tuning data - poisoned training data is a persistence mechanism that survives every prompt-level control you add later.
• "The model returns HTML that we render in the customer dashboard. Any concerns?" The easy one, and a fast filter for candidates who only think about the model. Insecure output handling is XSS with an extra step: model output flows into a browser, a shell, a SQL string, or another service's API. Encode at the sink, never eval or exec generated content, and apply exactly the discipline you would apply to any user-supplied string - the ground covered in our AppSec interview guide →.

Knowledge questions

• "Walk me through the OWASP Top 10 for LLM Applications." You do not need to recite ten items in order. You do need it as shared vocabulary - prompt injection, insecure output handling, training data poisoning, model denial of service, supply chain, sensitive information disclosure, excessive agency. Name the three you have actually reasoned about and go deep on those instead of listing all ten shallowly.
• "What is the difference between direct and indirect prompt injection?" Direct is the user typing the attack into the chat box, and it mostly matters when the model has privileges the user does not. Indirect is the attack arriving through content the model consumes - a retrieved page, a document, a calendar invite - which makes it a supply chain problem and the one that scales. Candidates who only describe the first are describing the less interesting half.
• "How do you evaluate whether a guardrail actually works?" Measurement, not vibes. A held-out attack set, attack success rate as the metric, reporting both before and after the control, and honesty about false-positive cost when the guardrail starts refusing legitimate requests. Mentioning that you would re-run the suite against every model version change shows you understand these systems drift.
• "What is the EU AI Act and does it apply to us?" For any governance-flavored role, know the shape: obligations are tiered by risk, with prohibited practices at the top, a heavy compliance regime for high-risk systems, and lighter transparency duties below that. Pair it with ISO/IEC 42001 as the emerging management-system standard - the thing an auditor can certify against - and NIST's AI Risk Management Framework as the voluntary structure most US teams reach for. The honest and correct answer to "does it apply" usually starts with "that depends on what the system decides and about whom."
• "What would be in your model inventory?" A GRC-track question with a concrete answer: every model in use, first- and third-party, what data it touches, what decisions it influences, who owns it, which evaluations it has passed, and when it last changed. You cannot govern what nobody has listed, and almost no company has this list yet.

The judgment questions

• "We are shipping our first LLM feature next quarter. What do you do in your first month?" The sizing question, and the most revealing one in the loop. The wrong answer is a research program. The right answer is triage: inventory what is already being built (it is always more than leadership thinks), find where model output reaches a sink that does something - a tool, a database, a browser, a payment - and put controls there first, then write the one-page rule for what an AI feature may and may not be trusted to do without a human. Ambition scaled to a quarter beats ambition scaled to a conference talk.
• "Is this a model problem or an application problem?" Given a finding - the model produced something harmful, or the model leaked another customer's data - can you tell the difference between a model-safety issue you escalate to the provider or the ML team, and an application-security issue your team owns and can fix this week? Most findings that get reported as scary model behavior are ordinary authorization and output-handling bugs, and the engineer who can say so without drama is the one they hire.
• "How would you write up a jailbreak you found?" Red-team seats test whether your output is actionable. A copy-pasted prompt from social media is not a finding. A finding states the preconditions, the impact in terms of what the attacker gains, the reproduction rate across attempts (these attacks are probabilistic, so "works 6 times in 10" is real information), and a mitigation the product team can build. Show one from your own lab work if you have it.
• "A product team wants to ship in two weeks and your review is not done." Same test as any security role: can you separate what must block from what can be a tracked risk with an owner and a date. AI features are shipping fast everywhere, and a reviewer who blocks everything gets routed around by the third sprint.

Questions you should ask them

• "Do you have an inventory of the AI systems in production today, and who owns it?" (If nobody can answer, you are being hired to build the map, which is a fine job as long as you know that going in.)
• "Where does this role sit - inside AppSec, inside the ML org, or in GRC?" (The three versions of this job are genuinely different, and job titles do not distinguish them.)
• "Can I actually block a launch, or do I advise?" (Ask early. The answer defines the job more than any responsibility bullet.)
• "What have you already found and fixed?" (A team with real findings has real systems. A team with none has either nothing shipped or nobody looking.)
• "Who handles model-safety issues versus application-security issues here?" (Tests whether they have thought about the boundary you will be living on.)

Before you interview

The biggest tell in these loops is the candidate who can only discuss models. They know the jailbreak literature and cannot say where the credentials live, how the retrieval query is authorized, or what the agent's network policy is. The systems being shipped are ordinary applications with a new component, and most of the real incidents so far have been ordinary failures around AI - leaked keys, open storage, over-permissioned agents. Bring one artifact: a threat model of a RAG or agent architecture you drew yourself, or a red-team writeup with a reproduction rate and a mitigation. That is still rare enough to carry an interview. If you are earlier on the path, start with how to become an AI security engineer →, and see who is hiring on the AI security jobs hub → or the adjacent application security jobs board → - updated hourly, every listing applying direct to the employer.