AI Security & Prompt Engineering Interview Questions

OWASP's LLM01 is the opening question of nearly every AI security screen. Most candidates can define direct injection; the ones who get hired explain why indirect injection is the one that ruins enterprise deployments.

Candidates use these terms interchangeably and security interviewers notice immediately. The distinction, whose policy is being violated, drives completely different defenses, and that's the actual question.

OWASP made system prompt leakage its own category (LLM07) because teams keep treating prompts as secrets. The strong answer flips the premise: design so extraction doesn't matter.

Reciting all ten gets you a pass on memory and a fail on judgment. The question is really a prioritization exercise, here's the two-risk answer that maps to how agents actually get breached, and the trap hiding in 'walk me through.'

OWASP LLM06 is where AI security stops being novel and becomes a least-privilege problem, which is exactly why interviewers love it. The control list is short; knowing which control to lead with is the test.

Poisoning questions sort candidates who've read about backdoors from those who can name where poison enters a real pipeline, and why the embedding store is the soft target nobody audits.

ATLAS questions filter candidates who can name the framework from those who can run an incident through it. The mapping exercise, one concrete attack, kill-chain stage by stage, is what the interviewer actually wants to hear.

A verbatim AI-security interview question with a built-in trap: candidates who promise to stop extraction fail, and candidates who shrug 'it's unpreventable' also fail. The winning answer is a layered containment design.

Everyone hardens the chat box; almost nobody hardens the index. This question checks whether you've realized the RAG corpus is a write path into your model's behavior, and what you'd do about it this sprint.

MCP turned 'install a plugin' into 'inject text into every conversation.' Interviewers ask this to see if you understand why tool descriptions are an attack surface, and what a least-privilege agent runtime looks like.

A reported AI-security interview staple with a known grading rubric: recon, bypass, leakage, tool abuse, multi-turn drift. Candidates who free-associate attack ideas fail; candidates who run a structured campaign pass.

The grown-up version of 'how would you red-team a chatbot', Microsoft-style loops ask for a program, not a pen test. Team composition, harm taxonomy, iteration cadence, and which attack classes you script on day one.

An Anthropic-style system design axis: architectural safety. The answer is a pipeline diagram in words, five checkpoints, what each catches, what each costs in latency, and the streaming complication most candidates forget.

A deceptively simple screener: each detection method maps to a PII class, and the 'why not regex for names' sub-question has a precise answer about structure vs context that interviewers use as the pass bar.

An architecture question with a defensible right answer, and interviewers are tired of 'it depends.' Here's the split that survives both the platform team's consistency argument and the app team's context argument.

The four-point redaction design is becoming the standard FDE privacy round. Most candidates fortify the chat box and lose on the other three doors, here's the full design, including the de-redaction map that makes it usable.

Every EU enterprise deal hits this question, and the FDE in the room is expected to carry it without legal on the call. The processor/controller split, the transfer mechanics, and the one GDPR right that's hard for LLMs.

The most-asked question in every enterprise AI deal, and precision is pass/fail: the contractual answer, what ZDR actually changes, and the retention nuance that separates FDEs from demo engineers.

'Can't leave our environment' means four different things to four different stakeholders. The FDE skill is decomposing the demand into the actual requirement, and knowing which deployment tier each requirement really needs.

HIPAA-with-LLMs questions test whether you know the three things that gate the deal: the BAA, the minimum-necessary standard, and audit controls. Engineers who can name 45 CFR obligations in design terms win these rooms.

SOC 2 fluency is the price of admission to enterprise deals, and interviewers check it with two traps: what a SOC 2 report actually proves, and what it doesn't. Engineers who can read one are rarer than you'd think.

The AI Act question is a classification exercise in disguise: interviewers give you a use case and watch whether you can tier it, name the obligations, and know whose job each one is, provider or deployer.

Four frameworks, one product, mostly one set of evidence, the answer interviewers want is the deduplication map. Plus the one thing ISO 42001 covers that nothing else does, and why the labs raced to get it.

A Snowflake solutions-loop classic that generalizes to every AI deployment: why masking retrofits fail, what a role hierarchy actually looks like, and the policy-attachment model that makes governance survive schema growth.

The defining security design problem of enterprise RAG, and the reason Glean exists. Query-time ACL filtering, permission sync lag, and the leakage channels that survive naive designs: caches, citations, and the model itself.

A reported Anthropic system-design prompt. The skeleton is standard API platform work; the AI-specific 20%, token-denominated limits, safety classifiers in the path, abuse identity, is what the round actually grades.

A real customer ask from the field, and a layered design question in disguise: attribution, budgets, anomaly detection, and enforcement, plus the attribution problem that decides whether any of it works.

The LLM billing round has three trapdoors: retries double-charging customers, metering latency leaking into inference, and month-end numbers that don't match the provider invoice. The design that survives all three is the answer.

When the agent does something expensive, 'what happened and why' must be answerable in minutes, to an auditor, from records they trust. Most logging designs answer 'what'; the AI-specific work is 'why', and tamper-evidence is what makes it count.

The capstone governance round: AI incidents break standard IR playbooks in three specific places, containment without rollback, blast-radius over probabilistic systems, and root cause for nondeterministic behavior. Interviewers grade you on knowing which three.

The agent has real money authority and a write path into the system of record, which is the exact shape attackers want. The strong answer is layered enforcement outside the model, with the spend cap and the chain rule in code, not in the prompt.

Authentication is not isolation: a request can be fully authenticated to tenant A and still touch tenant B through a shared index, a semantic cache, or a fine-tuned model. The strong answer names every shared surface and how you stamp tenant identity through all of them.

One backdoored MCP server can BCC every email an agent drafts, and a clean server can rug-pull its tool definitions a week after approval. This is a software supply-chain program for dependencies that talk, not a one-time review.

Cross-tenant or cross-user data exposure through a model is the breach that starts regulatory clocks. The runbook has to answer 'whose data, to whom, how many' from logs that most teams never designed for, and contain a leak that may live in a cache or a fine-tuned model, not a deploy.

NIST AI RMF is voluntary, which is exactly why a CISO uses it as a shared yardstick. The strong answer turns Govern, Map, Measure, Manage into artifacts you already produce, and uses the Generative AI Profile to name the LLM-specific risks the core framework leaves abstract.

When agents call agents, one agent's output is another's untrusted input, and a single injected instruction can propagate across the whole graph with accumulated privileges. The strong answer treats every inter-agent edge as a trust boundary and bounds privilege per agent, not per system.

Sensitive meeting audio in, speaker-attributed summary out, and a hard guarantee that the raw transcript never lands on disk. The strong answer keeps everything on-prem, processes transcripts in memory only, and proves non-retention with architecture and audit, not a policy promise.

Turn a constitution of rules into a model that follows them, with no human labels on harmful examples. The strong answer walks the two phases (self-critique SFT, then RL from AI feedback), then spends real time on the part papers gloss: adversarially validating the aligned model holds under attack.

A code model that occasionally produces ransomware, reverse shells, or exfiltration scripts. The strong answer builds an automated loop: adversarial prompt generation, static and behavioral output scanning, layered mitigations, and attack-success-rate per category to prove the mitigations worked.

A red-team model that learns over many episodes which attacks bypass your filters is only useful if it explores instead of farming one exploit, and only safe if every discovered attack becomes target training data.

Two ways to prove a cloud LLM run is the audited model on the customer's input: a zero-knowledge proof of the computation, or a TEE attestation. They differ by roughly an order of magnitude in overhead and entirely in trust assumptions.

SAEs can surface candidate 'deception' features in the residual stream, but a correlated feature is not a cause. The real work, and the honest answer, is causal validation and admitting what interpretability cannot yet prove.

Fine-tune a LoRA adapter on the user's typing on the phone's neural engine, add noise locally with DP-SGD, and aggregate only adapter deltas, so no individual's vocabulary is recoverable from the global update.

An agent with write access to a CRM, a chat tool, and an HR system is one bad tool call from emailing salaries to a channel. Safety is least-privilege scopes, a hard read/write split, human approval on destructive actions, and an audit log of everything.

Candidates treat computer-use agents like API agents with a screenshot. The interviewer is probing the new visual attack surface (hidden text, off-viewport UI, injected images) and how containment changes when the agent drives a real customer desktop. Most miss the per-turn-approval trap.

Every control in the stack validates the shape of the action and none validates its target. A refund of the right amount, to a real customer, through a permitted tool, against the wrong account, is indistinguishable from success at every layer that is watching.

The inventory is the easy half. The hard half is finding the agents nobody registered, versioning behavior rather than code, and a kill switch that actually stops traffic within seconds while keeping every past action traceable.