How ready are you for an AI security interview?
20 scenarios written the way AI security interviewers phrase them. At the end you see which of the seventeen areas you have real exposure to, the single gap most likely to sink a loop, and the pages that close it. Each option you pick is explained as an interviewer would read it, so a half-finished run still teaches something.
Which role are you going for?
The job titles overlap, yet each AI security role weights its rounds differently.
The seventeen areas an AI security loop tests
AI security interviews are built from these areas, weighted by employer: frontier labs press hardest on prompt injection and agents, large tech companies on application security, banks on governance and identity. The diagnostic touches every one of them.
- Threat modelingdecides loops
- The method under every design round. Candidates who name controls before assets, attackers and trust boundaries lose the round in the first five minutes, whatever they say next.
- Prompt injectiondecides loops
- The defining risk of the field and the warm-up question in most AI loops. It scores the root cause and an honest account of why filters alone do not end it.
- Agents & MCPdecides loops
- Where the bar now sits. Once a model can act, injection becomes theft or an unwanted transaction, and design answers are judged on what a fooled agent can still reach.
- LLM app securitydecides loops
- Retrieval, output rendering and data leakage are where AI features ship real bugs. Interviewers expect controls enforced in code, not instructions to the model.
- LLM systemsexpected
- How context windows, retrieval and tool calls move data. Every AI security answer is a claim about this data flow, so a wrong picture here spoils the rest.
- Application securityexpected
- Model output that reaches a browser, shell or database recreates the classic bug classes. Big tech loops keep their standard code review and web security rounds.
- Identity & accessexpected
- Agents act on someone's behalf, so delegation, token scope and the confused deputy problem come up in nearly every agent design question.
- Infrastructureexpected
- Sandboxes for generated code, egress control and model weight protection. The controls that contain a fooled model live here.
- Supply chainexpected
- Models, datasets and MCP servers are dependencies that can execute code or carry instructions. Signing and provenance questions build on classic supply chain work.
- Red teamingexpected
- Central for red team roles and present everywhere as measurement: a finding without a sample size, a judge you validated and a severity is an anecdote.
- Cryptography & PKIsituational
- Rarely a whole round, often a sharp follow-up. Knowing exactly what a signature, a MAC and TLS each prove separates engineers from people who recite acronyms.
- Adversarial MLsituational
- Decisive for research roles, a vocabulary check elsewhere. Poisoning, evasion, extraction and membership inference must be told apart precisely.
- Governancesituational
- Decisive in regulated enterprises and architect roles. The skill tested is turning a framework or regulation into a control an engineer can build.
- Systems & OSexpected
- Sandboxes, containers and agent code runners all rest on the kernel and the privilege model. Panels probe it hardest for infrastructure and offensive roles, and a vague answer about what root or a container actually is ends the follow-ups early.
- Mobilesituational
- Decisive for mobile, payments and consumer-platform roles, a sharp follow-up elsewhere. Panels listen for one idea: the phone belongs to whoever holds it, so the server makes every decision that matters.
- Networksituational
- A favourite of big-tech and vendor screens. Panels walk the stack from DNS to rendering and stop wherever you hand-wave; the idea they test is that authentication, not encryption, is what defeats an attacker in the path.
- Detection & IRexpected
- Every security loop asks what you would do when something is already wrong. Panels listen for the order: contain before cleaning, preserve before changing, scope beyond the first host, and turn the incident into fixed systems.
Profiles this tends to find
Rather than ranking you, the diagnosis matches your answers to a profile. Six frequent profiles follow, and each suggests a different place to spend your first week.
- The AI Specialist Without the Security Base
You know the AI attacks: injection, exfiltration channels, the lethal trifecta. Then the classic rounds land differently.
- The Security Engineer Meeting the Model
Your threat modeling and identity answers read like someone who has done security reviews for real. The AI questions are where the picks wandered, usually toward controls that rely on the model behaving: firmer prompts, more classifiers.
- The Builder Who Has Not Measured
You design sensible controls for LLM apps and agents. The gap is assurance: how you would show a control works, report a red team result with honest uncertainty, or turn a regulation into a requirement.
- The One Who Designs for a Fooled Model
Without prompting, you chose controls that stay safe even when the model misbehaves: narrowly scoped tokens, retrieval filtered by permission, a sandbox, no open path out. Interviewers treat that instinct as the strongest signal for this job.
- The Strong Generalist
Every area scored evenly. Even scores make it hard to know where to start, and people in that position tend to reread what they already know.
- Early, and Aimed at the Right Thing
You have not shipped or secured an AI system that others relied on, and interviewers test for that experience in roundabout ways. Fortunately the field rests on a handful of mechanisms, and taken in sequence they take weeks, not years, to learn..
Where the plan sends you
Each plan sends you to pages like these, and you are welcome to start reading without it.
Why not just ask a chatbot?
Go ahead: a chatbot gives a reasonable first tour of what AI security interviews cover. For actual interview preparation it misses four things.
It will agree with you
Suggest a stricter system prompt plus another classifier to stop prompt injection, and a chatbot may well call it a great plan. Here that answer loses credit, with the reason: both measures only lower odds, and neither restricts what a manipulated agent can do. Each option is weighted by how an interview panel would respond, including badly.
It only covers what you bring up
You can only ask a chatbot about gaps you already know you have. People who studied prompt injection seldom think to test themselves on token audiences or on what signing actually guarantees, and those are the follow-ups that catch them out. These scenarios cover all seventeen areas, including the ones you would leave out.
Its reading list points nowhere specific
"Review RAG access control" is advice. Here that line becomes a link to the lesson that explains the mechanism and to the interview questions that probe it. Each step in the plan maps to a page on this site: 614 questions with worked answers and 147 concepts, plus 50 lessons.
The conversation does not persist
In a few weeks that conversation is lost in your history. This diagnosis is rebuilt from your saved answers, so it stays consistent, and its links go to pages that exist. Sign in and it is kept for you.
Use chatbots to explain OAuth or walk through the OWASP list; they are good at it. Locating your weak spots needs something else: one consistent scenario set for everyone, answers weighted the way panels grade, and specific pages to study next.
Why this measures coverage and not ability
Picking the correct answer about the lethal trifecta is not the same as reviewing a real agent design with someone watching, and any security engineer would distrust a page that pretended otherwise. That is why you get no percentage. You get the rounds your answers suggest you have prepared for, a claim the same scenarios for everyone can back up, and a named gap comes with a page to read, which a number never does.