infrastructure security
AI security interview questions tagged infrastructure security, across every topic.
10 questions · 5 unlocked for you
Concepts behind "infrastructure security"
Explanations of the mechanisms these questions rely on.
Foundational
What Containers Isolate, and What They Do NotContainers isolate processes using Linux namespaces, cgroups, capabilities, seccomp and security modules, but every container on a host shares one kernel. A kernel bug or a misconfiguration such as a privileged container, a mounted container runtime socket or a broad host mount lets code escape to the host. For untrusted code, including code written or run by AI agents, stronger boundaries such as gVisor's user-space kernel or Firecracker and Kata microVMs put a much smaller or separate kernel between the workload and the host. Infrastructure Security
Foundational
Sandboxing Untrusted CodeAgents that write and run code, notebooks that execute model output, and platforms that run customer code all execute code nobody reviewed. A sandbox makes that safe by combining a strong isolation boundary with an environment that has nothing valuable in it: no credentials, minimal files, no network or tightly allowlisted egress, resource and time limits, and disposal after use. Isolation answers whether code can escape; the environment answers what it can do without escaping. Infrastructure Security
Foundational
Protecting Model WeightsTrained model weights can represent enormous investment and, for the most capable models, real misuse risk if stolen. Theft needs only one successful copy, through compromised credentials, insiders, supply chain attacks, exposed storage or the serving infrastructure itself. Protection combines limiting where weights exist and who can access them, strong identity and encryption with tightly controlled keys, monitored and restricted egress, hardened serving, and insider-risk controls. RAND's 2024 study frames the problem as security levels matched to increasingly capable attackers. Infrastructure Security
Core
Cloud IAM and Privilege Escalation PathsCloud identity and access management decides what every user, service and workload can do, so it is the real perimeter of a cloud environment. Privilege escalation happens when a principal can use its permissions to gain more: attaching policies to itself, passing a powerful role to a resource it creates, changing code that runs under another role, or minting credentials. ML platforms are full of such paths because training and notebook roles are often broad. Least privilege, permission boundaries, organisation-level guardrails and path analysis keep them closed. Infrastructure SecuritySign in
Core
Self-Hosted Inference Servers: A Secure Reference DeploymentTeams increasingly run their own model servers, such as Ollama, vLLM, Triton, Ray Serve and llama.cpp. Most were designed for trusted networks: some have no authentication by default, expose model management next to inference, and rely on internal channels that deserialise data. Vulnerabilities and exposed servers followed. A secure deployment binds servers to loopback or a private segment behind an authenticating proxy, separates admin endpoints from inference, loads models only from an internal registry by digest, gives nodes no unnecessary cloud identity or egress and patches on a schedule. Infrastructure SecuritySign in
Advanced
The Inference Stack as Attack SurfaceAn LLM inference service is a stack of components that all handle untrusted input: an API gateway, authentication and quotas, request and prompt processing, tokenizers, the model server, GPU drivers, caches, logging, and the management plane. Each layer has classic risks such as parsing bugs, exposed dashboards and broken tenancy, plus AI-specific ones: cost exhaustion, model extraction through the API, prompt leakage through shared caches, and data retained in logs. Threat-modeling the stack layer by layer turns 'secure the model' into concrete controls. Infrastructure Security🔒 Premium