AI Infrastructure Security Engineer Interviews: The Real Incidents Companies Are Now Asking About

For most of 2024 and 2025, "AI security" in interview prep conversations meant prompt injection and jailbreaks — the application layer. That has quietly changed. A wave of real, disclosed incidents against the infrastructure underneath AI systems — the GPU clusters, the model registries, the training pipelines — has made AI Infrastructure Security a distinct, testable interview topic in its own right, separate from both traditional network security and LLM application security. Companies hiring for infrastructure and platform security roles are now asking about specific, named 2024–2025 incidents, not hypothetical scenarios, and candidates who can only speak in general zero-trust language are getting caught out.

The Incident That Started It: PyTorch's Supply-Chain Compromise

The incident every senior candidate should be able to discuss in detail happened in December 2022, though its lessons only became a standard interview topic more recently as AI infrastructure hiring accelerated. Between December 25 and December 30, PyTorch's nightly build pipeline was compromised through a dependency confusion attack: PyTorch's internal build depended on a package named torchtriton, resolved through a non-default package index, but pip's dependency resolution checked the public PyPI index first, which took precedence. An attacker registered a package with the identical name — torchtriton — on public PyPI, and anyone installing the PyTorch nightly build during that five-day window received the attacker's malicious package instead of PyTorch's real one. Before it was caught and pulled, the malicious package was downloaded more than 3,000 times, exfiltrating each installing machine's hostname, username, environment variables, and DNS nameserver information, with access to read SSH keys and password files.

PyTorch's actual fix is the part worth remembering for an interview: renaming the internal package to pytorch-triton, and proactively reserving the original torchtriton name as a placeholder on public PyPI specifically to block the same name-squatting technique from working again. That's the mature response to dependency confusion generally — not just removing a malicious package after the fact, but reserving every internal package name on whatever public index it could be confused with, so the technique has nowhere to land. Any training or build pipeline using an internal package name that isn't also reserved on the public index it resolves against carries this exact risk today, not just in 2022.

GPU Isolation Has Real, Recent Failure Modes

Dependency confusion targets what a pipeline installs; a second class of 2024 incident targets the isolation boundary around what a pipeline runs. In 2024, Wiz Research disclosed CVE-2024-0132, a critical time-of-check-time-of-use (TOCTOU) vulnerability in the NVIDIA Container Toolkit — the component that gives containers access to GPU hardware. The flaw let a malicious container image exploit a race condition in the toolkit's mount logic to get the host's root filesystem mounted inside the container, escalating from container access to full host control. Wiz estimated the vulnerability affected more than a third of cloud environments running NVIDIA GPUs at the time of disclosure. NVIDIA's first patch, version 1.16.2, was later found to be incomplete, requiring a further fix in 1.17.4 — a detail interviewers specifically probe for, because it tests whether a candidate treats "patched" as a claim to verify or a status to assume.

A third real technique, disclosed by Trail of Bits in 2024 and named Sleepy Pickle, targets model artifact integrity from a different angle than the pickle-deserialization risk most candidates already know. Rather than shipping an overtly malicious model file, Sleepy Pickle uses a separate pickle component that, when loaded alongside a legitimate model, dynamically and stealthily tampers with that model's behavior at deserialization time. A scan checking whether the model file itself is malicious can miss this entirely, because the malicious logic sits in an adjacent component patching the model in memory as it loads, not in the model weights being scanned. It's the kind of nuance that separates a candidate who knows to require safetensors over pickle from one who understands why that single format change closes off more than the obvious case.

The Framework Landscape: ATLAS, NIST, and Two Different OWASP Lists

These incidents map onto a growing, dedicated framework: MITRE ATLAS, the Adversarial Threat Landscape for Artificial-Intelligence Systems, built on the same structure as MITRE ATT&CK but purpose-built for AI and ML systems. As of its November 2025 update, ATLAS spans 16 tactics and continues to expand, most recently adding techniques specific to agentic AI systems through early 2026. Each documented technique is grounded in a real, disclosed case study where possible — a torchtriton-style dependency confusion or a Sleepy Pickle-style artifact tampering technique both have a natural home in ATLAS's taxonomy. Interviewers increasingly expect candidates to know ATLAS exists and to use it the way a traditional security engineer uses ATT&CK: as a structured checklist for threat modeling and incident response validation, not just a name to recognize.

A distinction that trips up otherwise strong candidates is the difference between OWASP's two separate Top 10 lists. The Machine Learning Security Top 10, published in 2023, covers the infrastructure and pipeline layer — adversarial input manipulation, model extraction, transfer-learning attacks, supply-chain risk — exactly the scope of an AI Infrastructure Security role. The Top 10 for LLM Applications, introduced in 2025, covers a different attack surface entirely: prompt injection, excessive agency, insecure output handling, the application layer of generative, instruction-following systems. Conflating the two in an interview answer is a fast way to signal imprecision — citing prompt injection defenses for a model-extraction question, or vice versa, tells an interviewer you haven't drawn the actual boundary between infrastructure security and LLM application security, which is precisely the boundary this specialization exists to test.

Why This Space Moves Faster Than Most Compliance Processes

The governance side of this topic moves just as fast as the technical side. NIST's Generative AI Profile (NIST-AI-600-1), released in July 2024 as a companion to the base AI Risk Management Framework, names twelve specific generative AI risk areas and over 200 suggested actions — evidence that even NIST decided the base framework alone wasn't concrete enough for this technology. Export control policy moved even faster: in January 2025, the Commerce Department created ECCN 4E091, the first export control classification specifically for AI model weights, with a tiered global licensing framework — and rescinded it roughly four months later in May 2025, replacing it with new guidance that legal analysts describe as maintaining rather than reducing compliance obligations. A candidate who treats export control as a settled, one-time policy question rather than an actively evolving area is demonstrating exactly the gap a senior interview is designed to find.

None of this is testable through memorised definitions — interviewers are asking candidates to reason through a specific incident's mechanism, not recite a framework's name. Practise walking through the torchtriton attack and CVE-2024-0132 out loud until you can explain the exact mechanism, not just the outcome, and practise drawing the line between the OWASP ML Security Top 10 and the LLM Top 10 without hedging. Betty, My Next Hop's AI mock interviewer, runs the AI Infrastructure Security Engineer track with exactly this kind of incident-grounded questioning, including follow-ups that test whether your explanation holds up under a deeper probe.