Interview Preparation

Agentic AI security interviews are unusual because the field is too new for a standard question bank. Interviewers improvise, and they improvise from the problems they are currently living with. That works in your favor: if you have actually built and broken an agent, you have opinions grounded in specifics, and specifics are what distinguish you from the pile of candidates who have read about prompt injection. This page covers the question archetypes per role, how to structure the two hard question types (incident scenario and design), how to talk about your own portfolio, and how to handle questions about experience you do not have.

The meta-rule for every answer on this page: name the trust boundary, name the failure mode, name the control, name the evidence. Answers that stay at the level of “you should validate inputs” are indistinguishable from answers written by someone who has never deployed an agent.

Archetypes and what they are really testing

Questions by role

Match your preparation to the role you are targeting — see Core Roles.

Agentic AI Security Engineer

1. “An agent in our platform has access to a customer database and an email tool. How do you reduce blast radius without breaking the product?” — A strong answer separates read from write, scopes credentials per-tool rather than per-agent, introduces an approval gate on the irreversible action, and names what the product team will object to.
2. “How do you prevent an agent from exfiltrating data through a tool call?” — Strong answers cover egress control at the network layer, allow-listing tool destinations, output inspection at the boundary, and acknowledge that content filtering alone is defeatable.
3. “What do you log for an agent, and why?” — Should name the full decision chain: input, retrieved context, model output, tool invocation with arguments, tool result, and the identity under which the tool ran. See Lab 4.
4. “How do you test that a security control on an agent actually works?” — Should describe an adversarial test suite that runs in CI, not manual spot checks.

AI Red Teamer

1. “How would you attack an agent that summarizes web pages and can file tickets?” — Should immediately identify attacker-controlled content flowing into a privileged action, then walk a concrete chain.
2. “How do you decide a finding is a real vulnerability rather than model misbehavior?” — Should center on whether a security boundary was crossed, not whether output was undesirable.
3. “Your test suite passes. What does that not tell you?” — Tests coverage humility; strong answers discuss non-determinism, model version drift, and the limits of a finite attack corpus.
4. “Walk me through a finding you reported and how you handled disclosure.” — Draw directly from From Portfolio to Offer.

Agent Orchestration Engineer

1. “Describe how you would design tool permissions in a multi-agent system.” — Should discuss per-agent identity, least privilege per tool, and preventing privilege accumulation through delegation chains.
2. “What breaks first when you go from one agent to five?” — Strong answers name trust between agents, context contamination, and loss of traceability across handoffs. See Lab 2.
3. “How do you secure an MCP server that other teams will connect to?” — Authentication, tool scope, input validation on tool arguments, and rate limiting; see Month 2.
4. “How do you handle an agent that loops or runs away?” — Budgets, step limits, cost ceilings, kill switches, and who gets paged.

AI Security Architect

1. “Where do you draw the trust boundaries in an agent platform?” — Should produce an actual boundary map: user, orchestrator, model provider, retrieved content, tools, downstream systems.
2. “How do you decide which agent use cases are allowed at all?” — Risk tiering tied to reversibility and data sensitivity; should reference NIST AI RMF.
3. “A team wants an agent with production write access. Walk me through your review.” — Should be a structured review, not a yes/no.
4. “What is the security architecture difference between a chatbot and an agent?” — The answer is capability and consequence, not model behavior.

AI Governance Engineer

1. “How do you produce evidence that a control is operating, not just documented?” — Should describe automated evidence collection; see Evidence Automation.
2. “How do you map an agent system to a regulatory obligation?” — Should show the mapping mechanics, using EU AI Act or ISO 42001 concretely.
3. “An engineering team says your control is impossible. What do you do?” — Tests whether governance is done with engineers or to them.
4. “How do you keep a risk register current when the system changes weekly?” — See Lab 5.

The incident scenario question

This is where most candidates lose the interview, usually by racing to a root cause. Use this structure every time, out loud, in this order:

1. Clarify scope — What is the agent? What can it access? What is confirmed versus reported? How long has it been running? Ask before you act.
2. Contain — Reduce blast radius before you understand the cause. Revoke credentials, disable the tool, pause the agent, block the egress path.
3. Investigate — Work the decision chain in the logs, from the tool call backwards to the input that caused it.
4. Name the evidence you would need — Explicitly list the telemetry that would confirm or refute your hypothesis, and say what you would do if it does not exist.
5. Root cause hypothesis — State it as a hypothesis, with the specific evidence that would confirm it.
6. Durable control — What change prevents this class of incident, not just this instance.

Worked example: agent hijacked via indirect prompt injection

Scenario: “Our support agent reads customer emails and has a tool that issues refunds. Finance says refunds spiked overnight. Go.”

Clarify. How many refunds, over what window, to which accounts? Does the agent issue refunds autonomously or with approval? Which tools does it hold besides refunds? Is it still running right now?

Contain. Disable the refund tool first — not the whole agent, if the rest of the workflow is business-critical, but the irreversible capability immediately. Revoke the credential the agent uses against the payments system. Freeze the affected payouts if the payment provider allows a hold. Preserve logs before anything rotates.

Investigate. Pull the decision chains for the anomalous refunds. For each: which email was the input, what content was retrieved into context, what did the model output, what arguments went to the refund tool, under which identity. Look for the same instruction-shaped text appearing across multiple hijacked runs.

Evidence I would need. Full prompt and retrieved-context capture per run; tool invocation arguments; the raw source email including headers; the identity and scope of the credential used. If prompts are not captured, I say so plainly and describe what I can infer from tool arguments alone — and that gap becomes a finding.

Root cause hypothesis. Attacker-controlled email content contained instructions that the agent treated as directives rather than data, and the refund tool was invoked without a human gate or amount ceiling. The injection is the trigger; the missing authorization boundary is the vulnerability.

Durable control. Refunds above a threshold require human approval. The refund tool enforces per-transaction and per-window limits server-side, not in the prompt. Untrusted email content is structurally separated from instructions in context. Anomaly alerting on refund volume. An adversarial test case, added to CI, that replays this exact injection.

The design question

“Design the trust boundary and approval gate for an agent that reads internal wiki pages and can update customer records.”

A good answer covers this checklist, roughly in order:

• Enumerate the data flows and mark which sources are attacker-influenceable
• Draw the trust boundaries explicitly — say where they are, out loud
• Classify each tool by reversibility and blast radius
• Assign identity: which principal does each tool call run as, and with what scope
• Place the approval gate at the irreversible action, not at the model output
• Define what the approver actually sees — a diff and a reason, not raw model text
• Specify server-side enforcement of limits, so a compromised prompt cannot raise them
• Define the audit record for every gated action
• State the failure mode: what happens when the model is wrong, and what happens when the gate is unavailable
• Name the cost — latency, human load, and where the product team will push back
• Say how you would test that the boundary holds

The two most common gaps: putting the control in the prompt instead of in the infrastructure, and never mentioning what the human approver is looking at.

Talking about your own portfolio

Interviewers use your project to test whether the work is genuinely yours. The tell is depth on failure.

Prepare a three-minute version and a fifteen-minute version of each artifact. The three-minute version: what problem, what you built, what you found, what it maps to. The fifteen-minute version adds architecture, decisions you reversed, and evidence.

The “how it fails” section is the point. Every artifact you present should come with a volunteered limitation: what your evaluation does not cover, what an attacker could still do, what you would build next if you had another month. Volunteering a limitation is a strength signal for a specific reason — security work is the practice of knowing where your assurance ends. A candidate who presents flawless work is either inexperienced or not being straight, and interviewers read it as one of the two.

Questions about experience you do not have

You will be asked about things you have never done. There is one correct pattern, and it has three parts:

1. State the gap plainly. “I have not run an incident response at production scale.”
2. Bridge to the nearest real thing. “The closest I have done is instrumenting my own agent so a hijacked tool call was traceable end to end — that is where I learned what evidence you need before you need it.”
3. Show how you would approach it. Then reason through the actual question, out loud, using the structure above.

What kills candidates is not the gap. It is bluffing, because the follow-up question is always more specific and the collapse is visible to everyone in the room. Interviewers hire people they will have to teach; they do not hire people they cannot trust to say “I don’t know.”

Preparation checklist

• Two-sentence positioning statement rehearsed until it is natural
• Three-minute and fifteen-minute versions of each portfolio artifact
• A volunteered limitation prepared for every artifact
• The six-step incident structure practiced out loud, three different scenarios
• The design checklist practiced against two different agent architectures
• Ability to map any finding to OWASP LLM Top 10 and MITRE ATLAS without notes
• One framework from Governance you can discuss at real depth
• Three specific, non-generic questions to ask the interviewer about their agent architecture
• A prepared, honest answer for your single biggest experience gap
• Reference material bookmarked from Standards References

Then keep the skills current: The Continuous Learning Loop.