AI Security Interview Questions and Answers 2026 (60 Questions)

AI security interview questions in 2026 test whether you can secure a system that reads untrusted text, calls tools with real permissions and returns output people act on, not whether you can recite a list of attacks. Interviewers for AI security, GenAI security, LLM application security and AI red teaming roles want to hear threat models, layered controls, honest trade-offs and calm incident handling. This guide works through 60 high-value questions with model answers, from the OWASP and MITRE frameworks to prompt injection, agent identity, RAG access control, cloud controls and twelve production scenarios.

How to use this guide

• Freshers and career switchers: master the threat landscape, prompt injection, data leakage and output handling sections. Interviewers mainly check that you understand why an LLM cannot reliably separate instructions from data.
• Application security, cloud security and DevSecOps engineers: focus on agent identity, supply chain, cloud AI security and monitoring. You are expected to map familiar controls (least privilege, egress control, SBOMs, audit logs) onto AI systems.
• Senior and architect candidates: the RAG security, multi-tenant isolation, governance and scenario sections carry the most weight. Expect follow-ups such as "what breaks first?" and "how would you prove that control works?"

All attack descriptions here are conceptual and defensive.

Contents

• AI threat landscape (Q1–5)
• Prompt injection and defences (Q6–10)
• Data leakage and PII (Q11–14)
• Excessive agency and tool security (Q15–18)
• Identity for agents (Q19–21)
• Supply chain: models, packages, MCP servers (Q22–25)
• RAG security: ACLs and poisoning (Q26–29)
• Output handling (Q30–32)
• Guardrails (Q33–35)
• Red teaming (Q36–38)
• Monitoring and incident response (Q39–41)
• Cloud AI security (Q42–44)
• Governance and compliance (Q45–46)
• Multi-tenant isolation (Q47–48)
• Real-world scenarios (Q49–60)
• Key takeaways
• Interview preparation checklist
• FAQ

AI threat landscape

1. Why is securing an LLM application different from securing a normal web application?

Answer: Because the model mixes instructions and data in one channel, and its behaviour is probabilistic. In a web app, code is code and user input is data; parameterised queries keep them apart. In an LLM app, the system prompt, the user's message, retrieved documents and tool results all arrive as text in the same context window, and the model decides what to follow. There is no equivalent of a parameterised query that makes injection impossible. On top of that, modern LLM apps are given tools, so a manipulated model can act, not just talk. The consequence is a design principle: treat the model as an untrusted component whose output must be validated and whose permissions must be bounded by systems outside the model.

Interview tip: Say "the model is not a security boundary" early. It signals you will not rely on the system prompt as a control.

2. Walk me through the OWASP Top 10 for LLM Applications.

Answer: The current edition, published by the OWASP GenAI Security Project as the 2025 list, is: LLM01 Prompt Injection; LLM02 Sensitive Information Disclosure; LLM03 Supply Chain; LLM04 Data and Model Poisoning; LLM05 Improper Output Handling; LLM06 Excessive Agency; LLM07 System Prompt Leakage; LLM08 Vector and Embedding Weaknesses; LLM09 Misinformation; LLM10 Unbounded Consumption. Compared with the earlier edition, it added system prompt leakage and vector/embedding weaknesses (reflecting how common RAG has become), broadened poisoning to cover models as well as training data, and reframed denial of service as unbounded consumption, which includes cost abuse.

Interview tip: OWASP also publishes a separate Top 10 for Agentic Applications (ASI01 Agent Goal Hijack through ASI10 Rogue Agents). Mentioning that you know the difference between the two lists shows you keep current.

3. What is MITRE ATLAS and how does it differ from the OWASP list?

Answer: MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) is a knowledge base of adversary tactics, techniques and case studies against AI and machine learning systems, modelled on MITRE ATT&CK. OWASP's list is a prioritised set of risk categories for people building LLM applications; ATLAS is an adversary-behaviour matrix for threat modelling, detection engineering and red team planning. They complement each other: I use OWASP to structure a design review ("have we addressed excessive agency?") and ATLAS to describe how an attacker would chain steps such as reconnaissance, initial access through a poisoned data source, and exfiltration, so the SOC can map detections to techniques the same way it does with ATT&CK.

4. How would you threat model a new GenAI assistant?

Answer: Start from data flows and trust boundaries, not from the model. I draw every input source (user, uploaded files, retrieved documents, web pages, tool results, memory), every action the system can take (tool calls, emails, tickets, database writes), and every output channel (chat UI, rendered HTML, downstream systems). Then for each boundary I ask STRIDE-style questions plus AI-specific ones: can untrusted text reach the context? Can the model reach a tool with side effects? Can output reach a sink that executes or renders it? The most dangerous combination is the one Simon Willison called the "lethal trifecta": access to private data, exposure to untrusted content, and a way to send data out. If all three exist in one agent, I break at least one leg by design.

untrusted text --> [ context ] --> model --> tool call
                       ^                       |
private data ----------+          egress? <----+

5. What is the difference between a jailbreak and a prompt injection?

Answer: A jailbreak is an attempt by the user to make the model ignore its safety or policy training, for example to produce content it should refuse. A prompt injection is an attack on the application: text from any source, often a third party, tries to override the developer's instructions so the system does something its owner did not intend, such as calling a tool or leaking data. A jailbreak is mostly a content-safety problem with reputational impact; an injection is a confused-deputy problem with security impact, because the victim is often not the person typing. The controls overlap (input classifiers, output checks), but injection needs architectural controls such as least-privilege tools and egress restrictions, because you cannot filter your way out of it.

Prompt injection (direct and indirect) and defences

6. Explain direct versus indirect prompt injection.

Answer: Direct injection comes from the user's own input: they type instructions meant to override the system prompt. Indirect injection arrives through content the system processes on the user's behalf: a web page the agent browses, an email it summarises, a PDF in the RAG index, a ticket comment, even a tool description or API response. Indirect injection is more dangerous in enterprises because the attacker never needs an account; they only need to get text somewhere the assistant will read it, and the victim is a legitimate user whose permissions the agent is using. That is why every external or user-editable source must be labelled as untrusted in the architecture, regardless of how "internal" it looks.

7. Can prompt injection be fully prevented? What do you do instead?

Answer: No current technique reliably prevents it, because the model processes instructions and data in the same token stream. So I design for containment: assume some injection will succeed and limit what a hijacked model can do. Concretely: least-privilege tools scoped to the task; the user's own authorisation enforced at every tool and data call; no unrestricted outbound network or link rendering; human approval for irreversible or high-impact actions; deterministic validation of tool arguments; separation of planning from processing untrusted content where possible; and detection layers (classifiers, canary checks, anomaly monitoring) to reduce the success rate and raise alerts. Success is measured as "a successful injection produces a low-impact, logged event", not "injection never happens".

8. What prompt-level hygiene is still worth doing, given it is not a boundary?

Answer: Prompt hygiene lowers the attack success rate and makes behaviour more predictable, so it is worth doing as one layer. Keep instructions in the system role, never concatenated into user content. Wrap retrieved and tool content in clearly delimited sections and tell the model that content inside them is data to analyse, not instructions to follow. Keep the system prompt free of secrets, because system prompt leakage (LLM07) should be assumed possible. Use structured outputs with a schema so the model's response can be validated. What I would not do is treat any of this as sufficient on its own for a tool-using agent.

9. What design patterns reduce the impact of indirect injection in agents?

Answer: The useful patterns all limit what untrusted content can influence. A dual-LLM or quarantine pattern has a privileged planner that never sees raw untrusted text, while a quarantined model processes it and returns only constrained values (for example, a classification label or extracted fields validated against a schema). A plan-then-execute pattern fixes the sequence of tool calls before untrusted data is read, so a document cannot add new actions. Action selection from an allow-list removes free-form tool choice. Context minimisation passes only the fields the step needs. And taint tracking marks data derived from untrusted sources so that policy can block it from flowing into sensitive sinks, such as an email recipient field. Each pattern costs flexibility, so I apply the strictest one where the tools are most dangerous.

10. How do you test whether your injection defences work?

Answer: With a versioned adversarial test set run in CI, plus periodic manual red teaming. The set includes direct attempts, indirect attempts planted in each content source the system reads (documents, emails, tool results), multilingual and encoded variants, and multi-turn attempts. For each case I assert on behaviour, not wording: was a disallowed tool called, did data reach an external URL, did the agent take an action outside the user's request? I track attack success rate per category over time and fail the build if it regresses beyond an agreed threshold. Equally important, I run a benign set to measure false positives, because a filter that blocks legitimate users will be switched off by the business. The AI red teaming guide covers how to build and maintain such an attack library.

Data leakage and PII

11. What are the main ways sensitive data leaks from an LLM application?

Answer: Five common paths. First, retrieval returns documents the user is not entitled to, because the index ignored source ACLs. Second, the model is induced to reveal context it was given, including the system prompt or another user's data held in shared memory or cache. Third, data leaves via output channels: rendered links and images, tool calls to external services, or emails. Fourth, logs, traces and evaluation datasets store prompts and responses containing PII with weaker access control than the source system. Fifth, data is sent to a model provider or region that the data classification does not allow. Training-data memorisation exists too, but for most enterprise apps using hosted models with retrieval, the first four are where incidents actually happen.

12. How do you handle PII in prompts, logs and traces?

Answer: Minimise first, then protect what remains. Only send fields the task needs; a summarisation step rarely needs a customer's Aadhaar or PAN number. Where the model does not need the real value, replace it with a reversible token before the call and restore it after, keeping the mapping in a controlled service. For observability, log metadata (prompt template version, token counts, tool names, latency, guardrail decisions) by default and store full prompt and response text only where needed, with redaction, a short retention period and access limited to named roles. Treat traces in tools such as Langfuse or LangSmith as production data stores under the same classification as the source data. Under India's DPDP Act, purpose limitation and retention questions apply to these stores too; see the DPDP Act for AI applications.

13. What is system prompt leakage and why does OWASP list it separately?

Answer: It is the disclosure of the instructions the developer gave the model. OWASP lists it separately because teams keep putting things in system prompts that should never be there: API keys, internal hostnames, role definitions that stand in for real authorisation ("only admins may approve refunds"), or business rules attackers can then probe. The fix is not secrecy but design: assume the system prompt will be read, keep secrets in a secrets manager used by backend code, and enforce permissions in the tool layer rather than describing them to the model. A leaked prompt should be mildly embarrassing, never a breach.

14. How do you decide which data may be sent to which model?

Answer: Through the existing data classification scheme, extended with an AI usage policy. For each classification level I define allowed model endpoints (for example, a provider-hosted model in an approved region under an enterprise agreement with no training on customer data, versus a self-hosted model inside the VPC for the most restricted data), allowed retention, and whether human review of outputs is required. Then I enforce it technically: an LLM gateway that routes by data classification, blocks unapproved endpoints, and applies DLP checks on outbound prompts. Policy without a gateway becomes a document that developers bypass under deadline pressure.

Excessive agency and tool security

15. What does "excessive agency" mean in practice?

Answer: It means the system can do more than the task requires, so a manipulated or simply mistaken model causes outsized damage. OWASP breaks it into excessive functionality (tools that are not needed, such as a general shell when only "read ticket" is required), excessive permissions (a tool connected with an admin account instead of a scoped one) and excessive autonomy (high-impact actions taken without confirmation). The controls map directly: remove unneeded tools, give each tool its own narrowly scoped credential, prefer specific operations ("close_ticket(id)") over generic ones ("run_sql(query)"), and require human approval for irreversible or high-value actions.

16. How do you design a tool so that it is safe for an agent to call?

Answer: Treat every tool as a public API that a hostile client can call with any arguments. Use a strict input schema with types, enumerations and length limits, and validate on the server, not in the prompt. Enforce authorisation inside the tool against the end user's identity, not the agent's. Make writes idempotent and reversible where possible (soft delete, versioning). Add rate limits and per-call blast-radius limits, such as a maximum number of records changed. Return minimal, structured results so tool output does not become a new injection vector. Log every call with the requesting user, the agent identity, arguments and result.

17. When should an agent require human approval, and how do you stop approval fatigue?

Answer: Require approval when an action is irreversible, affects money, access rights or customers externally, touches many records, or falls outside the user's normal pattern. To avoid fatigue, tier it: low-risk reads run automatically, medium-risk writes are logged and reversible, and only high-risk actions pause for approval. The approval screen must show the exact action and arguments in plain language, computed by deterministic code, not a model-written summary that an injection could falsify. Track approval rates; if reviewers approve nearly everything instantly, the threshold is wrong or the approver is rubber-stamping. Frameworks such as LangGraph support interrupting a graph for approval and resuming it, which makes this pattern straightforward to implement.

18. What are the specific risks of agents that can execute code?

Answer: Generated code may be malicious (via injection) or just dangerous (deleting files, installing packages, making network calls). OWASP's agentic list calls this unexpected code execution. Controls: run code only in an isolated sandbox (ephemeral container or microVM) with no access to host credentials, a read-only base image, CPU, memory and time limits, and network egress denied or restricted to an allow-list. Never mount cloud credentials or the user's home directory. Pin and scan any packages the sandbox can install, because models can suggest package names that do not exist and attackers can register them.

Identity for agents

19. Whose identity should an AI agent use when it calls enterprise systems?

Answer: It depends on the pattern, and the answer must be explicit. When the agent acts for a user (a copilot reading that user's mail or tickets), it should use delegated access, typically OAuth tokens obtained on behalf of the user, so downstream systems enforce the user's existing permissions and audit logs show both the user and the agent. When the agent acts autonomously (a nightly reconciliation job), it should use its own workload identity with permissions scoped to that job. Many systems are hybrid. The anti-pattern is a single shared service account or API key with broad rights used for every user, which turns any injection into privilege escalation. The AI agent identity and access guide covers these three patterns in depth.

20. How would you replace a long-lived API key used by an agent?

Answer: Move to short-lived, automatically issued credentials tied to a workload identity. On AWS that means an IAM role assumed by the compute (for example, an EKS service account mapped to a role) instead of access keys; on Azure, a managed identity or workload identity federation with Microsoft Entra ID; on Google Cloud, a service account with workload identity federation. For third-party SaaS APIs that only support keys, keep the key in a secrets manager, inject it at runtime, scope it to the minimum, rotate it on a schedule and on any suspected exposure, and put a proxy in front so the agent never sees the raw key. Add secret scanning in repositories and CI so keys do not reappear in code or notebooks.

21. How does authorisation work for MCP servers?

Answer: MCP (Model Context Protocol) is an open protocol, introduced by Anthropic in late 2024, for connecting AI applications to tools and data. For remote servers over HTTP, the specification defines an OAuth-based authorisation flow in which the MCP server acts as a protected resource and the client obtains tokens from an authorisation server; tokens should be issued for that specific server (audience-bound) and not passed through to other services. Local servers over stdio usually rely on the host environment's credentials instead. In an interview I would add the operational points: each MCP server should get its own scoped credentials, the server must enforce per-user authorisation on every tool call, and the enterprise should keep an approved registry of servers. Check the current specification at modelcontextprotocol.io, because the authorisation sections have evolved between revisions.

Interview tip: For a deeper MCP question bank, see the MCP interview questions.

Supply chain: models, packages, MCP servers

22. What does supply chain risk look like for AI applications?

Answer: It covers everything you did not write: model weights downloaded from public hubs, fine-tuning datasets, Python packages for frameworks and tokenisers, container base images, hosted model APIs, vector database clients, and MCP servers or plugins. Risks include tampered or backdoored weights, unsafe serialisation formats that execute code when loaded, typosquatted or hallucinated package names, abandoned dependencies, and tool servers whose behaviour changes after approval. The controls are familiar DevSecOps ones applied to new artefact types: provenance, pinning, scanning, signing and an internal approved registry. DevSecOps for enterprise AI walks through the pipeline stages.

23. How do you safely adopt an open-weight model from a public hub?

Answer: Verify where it came from and that loading it cannot run code. Prefer safetensors over pickle-based formats, because pickle can execute arbitrary code during deserialisation. Pin the exact revision or hash rather than a moving tag, mirror it into an internal artefact registry, and scan it with a model scanner before approval. Review the licence and model card, and record the model in an AI bill of materials alongside its dataset lineage where known. Then evaluate it yourself for safety behaviour and task quality, because a model that loads safely can still be fine-tuned to behave badly on specific triggers.

24. What risks are specific to MCP servers and how do you govern them?

Answer: An MCP server is code with access to data and actions, plus tool descriptions that the model reads as part of its context. Specific risks: a malicious or compromised server; tool descriptions containing hidden instructions (sometimes called tool poisoning); a server whose tool definitions change after approval (a "rug pull"); a tool named to shadow a trusted one; over-broad credentials; and tool outputs carrying injected text. Governance: an internal allow-list of approved servers with owners, pinned versions, review of tool descriptions as code, alerts when tool definitions change, scoped per-server credentials, sandboxed execution for local servers, and logging of every tool call. Treat installing an MCP server like installing a browser extension with access to company data.

25. How would you secure the CI/CD pipeline for an LLM application?

Answer: Apply standard pipeline security, then add AI-specific gates. Standard: signed commits or protected branches, SAST, dependency and container scanning, secret scanning, an SBOM, signed images and least-privilege pipeline credentials via OIDC rather than stored keys (GitHub Actions supports this with AWS, Azure and Google Cloud). AI-specific: prompts, guardrail configurations and tool schemas versioned and reviewed as code; an evaluation stage that runs quality and adversarial test sets and blocks on regression; model and dataset artefacts verified by hash; and a deployment gate that checks the target environment's model endpoints and egress rules. Promotion through environments should be the same as any other service, for example with Argo CD in a GitOps flow.

RAG security: ACLs and poisoning

26. How do you enforce document permissions in a RAG system?

Answer: Enforce them at retrieval time, using the source system's permissions, before anything reaches the model. During ingestion, store each chunk with metadata for its source document ID and access control (groups, roles, tenant, classification). At query time, resolve the user's identity and group memberships from the identity provider and apply them as a mandatory filter in the vector or hybrid search, so unauthorised chunks are never retrieved. Do not retrieve broadly and ask the model to "ignore documents the user cannot see". Keep ACLs in sync with the source: permission changes and deletions must propagate quickly, and you should test for stale permissions explicitly. For more question practice here, see the RAG interview questions.

user --> IdP (groups) --> retriever
                           | filter: acl IN groups
                           v
                   vector store --> chunks --> LLM

27. What is RAG poisoning and how do you defend against it?

Answer: RAG poisoning is planting content in the knowledge base so that it is retrieved for target queries and then misleads the model or injects instructions. It maps to OWASP's data and model poisoning and vector and embedding weaknesses. Defences: restrict who can write to indexed sources and prefer curated, owned sources over open wikis; record provenance and author for each chunk; scan content at ingestion for instruction-like text and hidden content (white text, tiny fonts, metadata fields, HTML comments); show citations so users see where an answer came from; weight or filter by source trust; and monitor for documents that suddenly appear in many retrievals. Most importantly, keep retrieved content from controlling tools, so poisoning degrades answers but cannot trigger actions.

28. Can embeddings leak the original text?

Answer: Yes, to a meaningful degree. Research on embedding inversion has shown that text can be partially reconstructed from embeddings, so vectors derived from confidential documents must be treated with the same classification as the documents. In practice that means encryption at rest, network isolation of the vector store, access control on the index itself (not just the application), tenant separation, and deletion of vectors when source documents are deleted. Do not export embeddings to third-party analytics tools on the assumption that they are anonymous.

29. What extra risks come with agentic RAG compared with a simple retrieval pipeline?

Answer: In agentic RAG the model decides what to search, how many times, and which tools to combine with retrieval, so retrieved content can influence later steps. A poisoned chunk can steer the next query, trigger a tool call or persist into agent memory, which OWASP's agentic list calls memory and context poisoning. Controls: keep retrieval tools read-only and permission-filtered; cap the number of iterations; do not write retrieved text into long-term memory without validation; and separate "research" steps from "act" steps with an explicit policy check in between. Evaluate the full trajectory, not just the final answer.

Output handling

30. What is improper output handling? Give examples.

Answer: It is passing model output to another component without treating it as untrusted input. Because an attacker can influence the output through injection, any downstream sink becomes reachable. Examples: rendering model output as HTML in a web UI without encoding (cross-site scripting); concatenating it into SQL or shell commands; using it as a URL the server fetches (server-side request forgery); writing it into templates or configuration; or rendering markdown images and links that cause the client to call an attacker's server.

31. How do you safely render LLM output in a chat interface?

Answer: Render as plain text or a restricted markdown subset, sanitise any HTML with a well-maintained sanitiser, and disable automatic loading of remote images. Links should be shown with their full destination, restricted to an allow-list of domains where feasible, and never auto-followed. A strict Content Security Policy limits where the page can load resources from, which blocks a common exfiltration channel. If you render code blocks, never execute them in the user's browser. These controls matter because a markdown image whose URL contains data is a well-known way to exfiltrate context without the user clicking anything.

32. How do structured outputs help security, and what are their limits?

Answer: Structured outputs (JSON constrained to a schema, or function calling) let you validate the model's response deterministically: types, enumerations, ranges and required fields. That turns many "the model said something weird" failures into rejected requests. Limits: a schema-valid value can still be malicious or wrong, such as a valid email address that belongs to an attacker or a refund amount within range but unjustified. So schemas must be combined with business-rule validation and authorisation checks. See function calling and structured outputs for the mechanics.

Guardrails

33. What are guardrails, and where do they sit?

Answer: Guardrails are checks around the model that detect or block unwanted inputs, outputs and actions. Input guardrails detect prompt attacks, off-topic requests and sensitive data before the call; output guardrails check for harmful content, PII, ungrounded claims and policy violations after it; action guardrails validate tool calls against policy. They sit in the application or a gateway, outside the model. Managed options include Amazon Bedrock Guardrails, Azure AI Content Safety (including Prompt Shields for user and document attacks) and Google Cloud's Model Armor, alongside open-source frameworks. The AI guardrails guide compares placements and options.

34. Why are guardrails not enough on their own?

Answer: Because they are probabilistic classifiers facing an adaptive adversary. A determined attacker iterates until something passes, uses encodings, other languages or multi-turn setups, and splits payloads across inputs. Guardrails also miss context: a request may be harmless in isolation but harmful given the tools available. So guardrails reduce volume and catch the obvious; architecture (least privilege, egress control, approvals, authorisation in tools) limits damage when they fail. In an interview I describe guardrails as one layer of defence in depth with a measured catch rate, never as the control.

35. How do you tune guardrails without blocking legitimate users?

Answer: Measure both error types on representative data. Build a labelled set of real (redacted) traffic plus adversarial cases, measure false positives and false negatives per category, and set thresholds per use case: a public chatbot and an internal security-research assistant need very different settings. Roll out new rules in log-only mode first, review what they would have blocked, then enforce. Watch latency too: chaining several guardrail calls adds delay, so run independent checks in parallel and use lightweight classifiers before heavyweight ones.

Red teaming

36. How does AI red teaming differ from a traditional penetration test?

Answer: A pentest looks for exploitable vulnerabilities in deterministic systems and usually ends with a reproducible exploit. AI red teaming probes probabilistic behaviour: whether the system can be made to leak data, misuse tools, produce harmful content or make unsafe decisions, and how often. The same prompt may succeed one time in ten, so results are reported as rates over repeated trials. Scope is broader too, covering safety, misuse and fairness harms as well as security. A good AI red team still covers the surrounding infrastructure (APIs, identity, storage), because many real findings are conventional bugs next to the model.

37. How would you scope and run a red team exercise for an internal copilot?

Answer: Agree scope and rules of engagement first: the environment (staging with realistic but synthetic data), allowed techniques, out-of-scope systems, data handling and a stop condition. Threat model the copilot to pick priorities: who the attackers are (malicious insider, external sender of content, curious employee), what assets matter, and which tools have side effects. Then combine automated probing with open-source tools such as PyRIT, garak or promptfoo for breadth with manual, creative testing for depth, especially multi-step indirect injection through the copilot's real data sources. Score findings by impact and reproducibility, report with clear remediation, and convert every confirmed finding into a regression test.

38. How do you rate the severity of an AI red team finding?

Answer: By impact times likelihood, with likelihood informed by the measured success rate and the attacker's required access. A jailbreak producing rude text from an internal tool, which requires an authenticated employee, is low. An indirect injection that any external email sender can use to make an agent send customer data out is critical even if it succeeds only occasionally, because attackers can retry at scale. I describe the impact in business terms (which data, which action, how many users) and note which control failed, so the fix targets architecture rather than just patching one prompt.

Monitoring and incident response for AI

39. What would you monitor in a production LLM application from a security point of view?

Answer: Signals across inputs, model behaviour, actions and cost. Inputs: guardrail detections by category, unusual input sizes, and spikes from single users or IPs. Behaviour: refusal rates, outputs containing URLs or PII, and drift in topic distribution. Actions: tool call volumes per user and agent, calls to sensitive tools, failed authorisation checks, approval rates, and any egress attempt to non-allow-listed destinations. Cost: tokens per user, per tenant and per key, which is how unbounded consumption and stolen keys show up. Emit these as OpenTelemetry traces and metrics with user, tenant and session IDs, and forward security-relevant events to the SIEM so the SOC can correlate them with identity and network logs. AI observability covers the tracing side.

40. How does incident response change for AI systems?

Answer: The lifecycle is the same (prepare, detect, contain, eradicate, recover, learn), but the playbooks need AI-specific levers prepared in advance. Containment options should include: a kill switch per feature or agent, disabling specific tools while keeping chat available, forcing all actions to require approval, switching to a more restrictive guardrail profile, removing documents from the index, and revoking agent credentials. Investigation needs the evidence to exist beforehand: prompt template versions, retrieved document IDs, tool calls with arguments, and model versions per request. And the post-incident action must add the attack to the regression suite.

41. What should an AI audit log record?

Answer: Enough to answer "who asked, which identity acted, what was read and what changed". Per request: timestamp, end-user identity, agent or workload identity, tenant, session, model and prompt template version, retrieved document IDs, guardrail decisions, each tool call with arguments and result status, approvals with approver identity, and the final response or a hash of it depending on data policy. Logs must be tamper-evident, access-controlled and retained according to policy, and sensitive content must be redacted or stored separately under stricter control.

Cloud AI security (private endpoints, IAM)

42. How do you keep traffic to a managed model service off the public internet?

Answer: Use private connectivity and lock down public access. On AWS, Amazon Bedrock supports interface VPC endpoints through AWS PrivateLink, and you can use endpoint policies and IAM conditions to restrict which principals and models can be used through them. On Azure, Azure OpenAI and related services in Microsoft Foundry (previously Azure AI Foundry) support private endpoints with public network access disabled. On Google Cloud, Private Service Connect and VPC Service Controls perimeters protect AI services (Vertex AI services are now delivered through Gemini Enterprise Agent Platform; check current documentation for naming). Pair private endpoints with egress controls on the application side, so a compromised workload cannot reach other model providers or arbitrary hosts.

43. How would you write IAM for an application that calls Amazon Bedrock?

Answer: Give the application's role only the actions it needs, such as invoking specific models, scoped to specific model or inference profile ARNs rather than a wildcard, and only in approved regions. Separate roles for runtime inference, for knowledge base ingestion and for administrators who manage guardrails or model access. Deny model invocation through anything but the VPC endpoint where your policy allows that condition. Enable CloudTrail for API activity and decide deliberately whether to enable model invocation logging, since it captures prompts and responses and must then be protected like the source data. Use service control policies at the organisation level to block unapproved regions or services entirely. The same thinking applies on Azure with Entra ID role assignments and managed identities.

44. What cloud misconfigurations do you see most often in AI workloads?

Answer: Patterns repeat: notebooks and development endpoints exposed publicly with broad roles; long-lived provider API keys in environment variables, repositories or notebooks; storage buckets with training data or documents readable too widely; vector databases reachable from the internet with default credentials; GPU instances with permissive security groups; logs with full prompts in a broadly readable log group; and no budget alerts, so key abuse is discovered on the invoice. A cloud security posture tool will catch many of these if AI resources are tagged and in scope. For a broader view, see AI for cloud security engineers.

Governance and compliance

45. Which frameworks and regulations would you reference when building an AI security programme?

Answer: A small, relevant set rather than every acronym. For risk management, the NIST AI Risk Management Framework and its Generative AI Profile. For a certifiable management system, ISO/IEC 42001 (see ISO/IEC 42001 explained). For application risk, the OWASP Top 10 for LLM Applications and for Agentic Applications; for adversary behaviour, MITRE ATLAS. For regulation, it depends on where data subjects and customers are: India's Digital Personal Data Protection Act for personal data of people in India, and the EU AI Act for systems placed on the EU market or affecting people there, which matters for Indian GCCs and services firms serving European clients.

46. What does an AI security review checklist for a new use case contain?

Answer: At minimum: data classification of every input and output; approved model endpoint and region for that classification; identity pattern (delegated, workload or hybrid) and tool permissions; retrieval ACL design; output sinks and how they are encoded; guardrail configuration and measured catch rates; human approval points; logging, retention and redaction; red team or adversarial test results; incident playbook with kill switch; vendor terms on data retention and training; and a named business owner who accepts residual risk. The review should be proportionate: an internal summariser over public documents should pass in a day, while a customer-facing agent with write access deserves a full review. The enterprise AI security guide includes a fuller checklist.

Multi-tenant isolation

47. How do you isolate tenants in a multi-tenant AI SaaS product?

Answer: Carry the tenant ID from authentication through every layer and enforce it outside the model. Retrieval: either separate indexes or namespaces per tenant, or a shared index with a mandatory tenant filter applied server-side (and row-level security if using PostgreSQL with pgvector). Caches: include the tenant ID in every cache key, especially semantic caches, where a "similar" question from another tenant could otherwise return a cached answer. Memory and conversation history: scoped per tenant and user. Fine-tuned models or adapters: never trained on one tenant's data and served to another. Rate limits and budgets: per tenant, to prevent noisy-neighbour and cost abuse. Multi-tenant AI SaaS architecture compares the models.

48. How do you prove tenant isolation to a customer's security team?

Answer: With design evidence and test evidence. Design: diagrams showing where tenant context is enforced, code paths where the filter is mandatory rather than optional (for example, a repository layer that cannot be called without a tenant ID), and infrastructure separation where offered. Tests: automated cross-tenant tests in CI that create two tenants with canary documents and assert neither can retrieve, cache-hit or be told about the other's data, including through adversarial prompts; periodic third-party penetration tests that include cross-tenant objectives; and monitoring that alerts when a response cites a document from a different tenant.

Real-world scenarios

49. A user reports that after the assistant summarised an uploaded document, their browser made a request to an unknown domain with what looks like internal data in the URL. What happened and what do you do?

Answer: This is very likely indirect prompt injection with exfiltration through output rendering: the document contained hidden instructions telling the model to emit a link or image whose URL encodes data from the conversation, and the chat UI rendered it, so the browser sent the data to the attacker's server. Containment first, then root cause, then structural fixes.

What I would check:

1. Disable remote image and link rendering in the UI immediately, or apply a strict domain allow-list and CSP.
2. Identify the document from the trace and quarantine it; search the index and uploads for similar hidden content.
3. Determine what context was in the window at the time (other documents, user data, system prompt) to scope the exposure.
4. Check proxy, CSP report and CDN logs for other requests to that domain to find additional affected sessions.
5. Engage the privacy and incident team if personal data was involved, following notification obligations.

Production consideration: The lasting fix is breaking the egress leg of the lethal trifecta: no auto-loaded remote content, link allow-lists, CSP, and treating uploaded documents as untrusted.

50. An operations agent deleted several hundred customer records in production. Walk me through your response.

Answer: Stop further damage, restore data, then find out why the agent was able to do this at all. The deeper question is not "why did the model decide to delete" but "why did a model have an unbounded delete permission without approval".

What I would check:

1. Trigger the kill switch or revoke the agent's credentials; confirm no further writes are happening.
2. Restore from backups, point-in-time recovery or soft-delete records, and verify with the data owner.
3. Reconstruct the trajectory from traces: the user request, retrieved content, the tool calls and arguments, and whether any untrusted content influenced the decision.
4. Check which identity performed the deletes and why it held that permission.
5. Review whether approval policies existed and were bypassed, misconfigured or never applied to this tool.

Production consideration: Fixes include replacing generic write tools with specific, bounded operations, soft deletes, a maximum-records-per-call limit, approval for bulk or destructive actions, and a separate identity with no delete rights for routine work.

51. Your LLM provider bill and token usage spike overnight, mostly from one API key. What do you do?

Answer: Treat it as a probable credential leak and unbounded consumption until proven otherwise. Revoke or rotate the key first, then investigate, because every hour costs money and possibly data.

What I would check:

1. Rotate the key and update the legitimate consumers via the secrets manager; confirm usage drops.
2. Look at request sources (IPs, user agents, regions) and content patterns in provider and gateway logs to tell abuse from a runaway internal loop.
3. Search repositories, CI logs, container images, client-side code and notebooks for the key; check secret-scanning alerts.
4. Determine whether the key could access anything beyond inference, such as stored files, fine-tuned models or assistants with data.
5. Contact the provider about the fraudulent usage and preserve logs.

Production consideration: Prevent recurrence with a gateway so applications never hold raw provider keys, per-key and per-tenant budgets with alerts, rate limits, short-lived credentials where the provider supports cloud IAM, and secret scanning in pre-commit and CI. A key embedded in a mobile app or browser bundle is effectively public.

52. A customer of your AI SaaS reports that an answer cited a document belonging to another company. How do you handle it?

Answer: This is a cross-tenant data leak and a serious incident. Contain, scope, notify, fix, and prove the fix.

What I would check:

1. Use the trace to identify the request, the retrieved chunk IDs and their tenant, and the code path taken.
2. Typical causes: a retrieval query missing the tenant filter in one code path, a semantic cache keyed without the tenant ID, shared conversation memory, an ingestion job that wrote chunks with the wrong tenant metadata, or a shared fine-tuned adapter.
3. Disable the affected feature or cache while investigating.
4. Query logs for all responses citing out-of-tenant documents to find every affected customer and document.
5. Follow contractual and legal notification obligations for both the customer who saw the data and the customer whose data was exposed.

Production consideration: Make the tenant filter impossible to omit (enforced in a data-access layer or database row-level security), include tenant ID in every cache key, and add cross-tenant canary tests to CI plus runtime alerts on any cross-tenant citation.

53. Screenshots of your customer-facing chatbot producing offensive content after a jailbreak are circulating on social media. What do you do?

Answer: Respond on two tracks: technical containment and communication. First confirm the transcripts are real using logs, since screenshots can be fabricated.

What I would check:

1. Find the sessions in logs and identify the technique category (role-play, encoding, multi-turn escalation) without republishing it.
2. Apply a fast mitigation: a stricter output moderation profile, an input rule for the pattern, or temporarily narrowing the bot to its core topics.
3. Check whether the jailbreak also exposed system prompt contents, data or tool access, which would change the severity.
4. Coordinate with communications and legal on a factual public response.

Production consideration: Durable fixes are output-side moderation (which catches results regardless of technique), topic scoping, a regression test for the technique family, and a pre-approved playbook so the next response takes minutes, not a meeting.

54. Someone posts your assistant's full system prompt online. How serious is this?

Answer: It depends entirely on what the prompt contained, which is why this is a design question more than an incident. If it holds only behaviour instructions, impact is low: competitors see your prompt engineering and attackers learn your guardrail wording. If it holds credentials, internal URLs or authorisation logic, it is a real incident.

What I would check:

1. Compare the posted text with the deployed version to confirm authenticity and age.
2. Rotate any secret that appeared in it, and review whether internal endpoints named in it are exposed.
3. Check whether the prompt describes permissions that only the model enforces; move them to the tool layer.

Production consideration: Assume every system prompt will be extracted eventually. Design so that publication is a non-event.

55. An HR assistant starts confidently telling employees a wrong leave policy. You find a recently edited wiki page is the source. What now?

Answer: This could be a careless edit or deliberate poisoning; the response is similar, and the lesson is source trust.

What I would check:

1. Remove or roll back the page in the index and confirm answers recover.
2. Check the edit history and author; if deliberate, involve HR and security.
3. Look for other edits by the same account or with instruction-like content.
4. Decide whether policy questions should retrieve only from an owned, approved policy repository rather than an open wiki.

Production consideration: Rank or restrict sources by ownership, display the source and last-updated date with each answer, and alert when a high-traffic answer's top source changes.

56. An approved MCP server used by your coding assistants pushed an update, and its tool descriptions now contain odd instructions. What do you do?

Answer: Treat it as a supply chain compromise or a "rug pull" until proven otherwise. Block the new version, then assess.

What I would check:

1. Pin all clients back to the last reviewed version or block the server at the proxy or endpoint management layer.
2. Diff the tool definitions and code between versions, and check the maintainer's account and repository for compromise.
3. Review tool call logs since the update for unusual calls, file access or outbound requests.
4. Rotate credentials the server had access to if anything suspicious ran.

Production consideration: Pin versions, treat tool descriptions as reviewed code, alert on definition changes, run local servers sandboxed with minimal credentials, and keep an internal registry so you know exactly who uses which server. Building your own MCP server is often safer for critical internal tools.

57. During an audit you discover that full prompts and responses, including customer PII, have been stored in your tracing tool for months with broad access. How do you remediate?

Answer: This is a data protection issue even if no misuse occurred. Reduce exposure now, then fix the pipeline.

What I would check:

1. Restrict access to named roles immediately and review access logs for who viewed or exported data.
2. Agree a retention decision with the privacy team, then delete or redact historical data accordingly.
3. Check where traces were exported or copied (evaluation datasets, spreadsheets, vendor support tickets).
4. Assess notification obligations with legal.

Production consideration: Redact at the SDK or collector level before data leaves the application, log metadata by default with opt-in content capture, set retention policies, and include observability tools in data classification and vendor review.

58. The business wants to launch an internal copilot connected to email, SharePoint and the ticketing system in three weeks. The CISO asks for your recommendation. What do you say?

Answer: I would give a conditional yes with a staged scope rather than a flat no. A three-week launch of read-only, permission-respecting retrieval for a pilot group is realistic; a launch with write actions across all three systems is not.

What I would check:

1. That access uses delegated user permissions, and that oversharing in SharePoint has been reviewed, since a copilot exposes existing permission mistakes.
2. That email content is treated as untrusted and the copilot has no outbound send or external link rendering in phase one.
3. Logging, retention and redaction agreed with privacy.
4. A focused red team on indirect injection through email and documents before go-live.
5. A kill switch and incident playbook.

Production consideration: Phase two adds write actions behind approvals once monitoring data exists. Framing security as a staged path, not a gate, is what senior interviewers listen for.

59. A developer's AI coding agent added a dependency that turns out not to exist on the official index, and someone has since registered that name. How do you respond and prevent it?

Answer: This is package hallucination exploited by squatting, a supply chain attack enabled by AI suggestions.

What I would check:

1. Identify every repository, build and environment that installed the package; treat those hosts and build credentials as potentially compromised.
2. Remove the dependency, rebuild from clean images and rotate secrets exposed to affected builds.
3. Report the malicious package to the registry.

Production consideration: Route installs through an internal proxy registry with an allow-list or age and reputation checks, require lockfiles and review of new dependencies, and run coding agents in sandboxes without production credentials.

60. A multi-agent workflow got stuck in a loop over a weekend, calling tools thousands of times and running up cost. What controls were missing?

Answer: Bounds. Unbounded consumption is a security and reliability issue: the same gap a cost-abuse attacker would exploit.

What I would check:

1. Whether there was a maximum step count, recursion limit or wall-clock timeout per run.
2. Whether tool calls were rate-limited and whether repeated identical calls were detected.
3. Whether budgets and alerts existed per workflow, and who was on call.
4. Whether the loop was triggered by bad input, a tool error the agents kept retrying, or agents passing work back and forth.

Production consideration: Add step limits, timeouts, retry caps with backoff, circuit breakers on failing tools, per-run token budgets and alerting on anomalous spend. OWASP's agentic list calls the broader pattern cascading agent failures. For more agent-design questions, see the agentic AI interview questions.

If you want to practise these scenarios hands-on, across cloud security, AI and agent controls, Cloudsoft's APEX AI, ML, Cloud and Cyber Security program is built around that combination, in Ameerpet or live online.

Key takeaways

• The model is not a security boundary. Enforce identity, authorisation and validation in the systems around it.
• Prompt injection cannot currently be fully prevented, so design for containment: least privilege, no uncontrolled egress, approvals for high-impact actions.
• Know the OWASP Top 10 for LLM Applications (2025) by name, know that a separate agentic list exists, and use MITRE ATLAS for adversary behaviour.
• RAG security starts at retrieval: permission filters from the identity provider, provenance per chunk and controlled sources.
• Agents need explicit identity patterns, short-lived credentials, bounded tools and full audit trails.
• Supply chain now includes model weights, datasets and MCP servers; pin, scan, review and register them.
• Prepare AI-specific incident levers (kill switches, tool disabling, index removal) before you need them, and turn every incident into a regression test.

Interview preparation checklist

• Recite the OWASP Top 10 for LLM Applications 2025 with one control for each item.
• Draw a threat model for a RAG assistant and an email-reading agent, marking the lethal trifecta.
• Explain direct and indirect prompt injection with a defensive example, without describing payloads.
• Build a small RAG app with permission-filtered retrieval and a cross-user canary test.
• Configure a managed guardrail service (Bedrock Guardrails, Azure AI Content Safety or Model Armor) and measure false positives on benign prompts.
• Write a least-privilege IAM policy for an app calling a managed model through a private endpoint.
• Run an open-source red teaming tool against your own app and write a short findings report.
• Prepare one incident story (real or from a lab) using contain, scope, fix, prevent.
• Read the current MCP authorisation section at modelcontextprotocol.io.
• Be ready to discuss DPDP Act obligations for prompts and logs, and when the EU AI Act applies.

FAQ

What skills are required for an AI security role?

You need application security and cloud security fundamentals, a working understanding of how LLMs, RAG and agents are built, identity and access management, threat modelling, and enough Python to build and test small AI applications. Communication matters too, because much of the job is reviewing other teams' designs.

How should I prepare for an AI security interview?

Learn the OWASP and MITRE ATLAS frameworks, build a small RAG app and an agent yourself, then attack and harden them. Practise explaining threat models and incident responses out loud, and prepare one or two scenario stories with concrete controls.

Do I need a cyber security background to move into AI security?

It helps but is not mandatory. Security engineers need to learn how AI systems are built, while AI engineers need to learn security fundamentals such as threat modelling, IAM and incident response. Either path works if you close the gap deliberately.

Is AI security a good career in India?

Interest is growing as enterprises, GCCs and services firms in Hyderabad and Bengaluru move AI assistants and agents into production and need people who can review and secure them. It suits engineers who enjoy both building systems and thinking like an attacker.

What is the difference between AI security and AI safety?

AI security protects AI systems and their data from attackers, covering injection, leakage, abuse and compromise. AI safety focuses on the system behaving as intended and not causing harm even without an attacker. Enterprise roles usually cover both, with security as the main focus.

Which certifications help for AI security roles?

Cloud security and general security certifications from the major cloud providers and security bodies remain useful foundations. AI-specific credentials are still emerging, so interviewers usually weigh a portfolio of hands-on projects and red team write-ups more heavily than any single certificate.

Do AI security interviews include coding?

Often, yes, at a practical level: reading Python, writing a small validation or filtering function, reviewing a tool implementation for authorisation gaps, or writing an IAM policy. Deep algorithm puzzles are less common than design and code review exercises.

What is AI red teaming and is it a separate job?

AI red teaming is adversarial testing of AI systems for security, safety and misuse failures. Some larger organisations have dedicated AI red teams, but in many companies it is one responsibility within an application security or AI platform team.

How important is cloud knowledge for AI security?

Very important. Most enterprise AI runs on AWS, Azure or Google Cloud, so private endpoints, IAM, key management, logging and network controls are a large part of securing it in practice.

Cloudsoft's APEX program combines AI and ML engineering with cloud and cyber security, so you can build the systems these questions describe and then secure them. If your goal is deploying AI systems with enterprise customers, the AI Forward Deployed Engineer course (FDE PRO) includes a Secure Banking AI Assistant project and placement support until you're placed. For core security foundations, see the Cyber Security course in Hyderabad. Classes run in Ameerpet or live online; call +91 96660 19191 for a free demo.

Related Cloudsoft resources

• AI Security for Enterprise LLM Apps and Agents
• AI Red Teaming Guide
• AI Guardrails Explained
• DevSecOps for Enterprise AI
• AI Agent Identity and Access
• AI for Cloud Security Engineers
• LLM Interview Questions
• Enterprise AI Interview Questions