Infrastructure Hardening & Sandboxing

Concept. An agent is only as contained as the weakest boundary around it. Weeks 17–18 hardened what the model reads and says; this week hardens what its tools can touch — the filesystem, the network, and the host kernel. The governing assumption flips from "trust the agent, filter its inputs" to "assume the agent is already compromised, and make that compromise worthless." That is defence-in-depth for autonomy: process confinement, least-privilege tool access, and network isolation stacked so that a successful prompt injection lands the attacker in an empty room.

The hard lesson of 2026 is that the boundary keeps losing to confusion — path confusion, parser differentials, TOCTOU races — not to brute force. So the engineering goal isn't "a stronger filter," it's a boundary the kernel enforces and the application cannot talk its way past.

🎯 Objectives

By the end of this week you can:

• Rank the 2026 isolation stack — hardened container → gVisor → microVM → kernel-capability sandbox — by isolation strength, boot cost, and when each is the right call.
• Explain why language-level sandboxing (Python exec, Pyodide) is structurally unsound and always prefer process/VM isolation for untrusted code.
• Apply least-privilege at the tool layer with deny-by-default capabilities instead of blocklists.
• Walk the dominant sandbox-escape patterns — TOCTOU races, path/symlink confusion, parser differentials — and map them to real CVEs.
• Wire agent egress through an exact-host allowlist and justify it with NIST zero-trust principles.
• Treat the sandbox product itself as attack surface — an isolation runtime ships the same bug classes (path traversal, command injection, incomplete blocklists) it exists to stop.

The isolation stack — pick your blast radius

There is no single "sandbox." There is a ladder, and each rung trades startup cost for a smaller blast radius. The decision rule is blunt: the more of the agent's code you didn't write, the higher up the ladder you go.

A shared-kernel container is the fast default, but "a kernel vulnerability or misconfiguration can allow container escape, giving attackers host access" — and since agents generate unpredictable code, that risk is not hypothetical (Northflank). gVisor closes most of it by interposing a user-space kernel that only forwards a vetted syscall subset, at a 10–30% I/O tax and near-zero compute tax (gVisor docs). When the code is genuinely untrusted, microVMs give each workload its own kernel behind a hypervisor — Firecracker boots in ~125 ms with <5 MiB overhead, so the "VMs are heavy" objection no longer holds (Kata for AI workloads). Baseline container hardening — drop capabilities, read-only rootfs, seccomp, non-root — still applies underneath all of it (Docker security · NIST SP 800-190).

🔑 Match the rung to the trust. Reviewed internal automation → hardened container. Compute-heavy agent → gVisor. Anything executing model-generated or third-party code → microVM. Never run untrusted code one kernel bug away from your host.

Language-level sandboxing is a trap

The tempting shortcut — let the agent run Python, but "sanitise" the code first — is a losing game, and 2026 keeps proving it. CVE-2025-9959 (smolagents, CVSS 7.6) is the canonical demonstration: incomplete validation of dunder attributes let a prompt-injected agent walk the object graph — ().__class__.__bases__ → __subclasses__() → find subprocess.Popen → execute — straight out of the "sandbox." The escape needs no exotic primitive, only attribute access the interpreter always exposes; JFrog's fix guidance is telling: don't patch the filter, abandon the local executor for a WASM one (JFrog). The same interpreter that runs your code shares its guts with the attacker's; code inspection can never enumerate every path to Popen.

The principled inversion is object-capability design: don't hand the agent a language and try to forbid the dangerous verbs — hand it typed capability objects that can only express safe operations. Ryan Rasti's SQL sandbox makes the point crisply: the agent never touches a SQL string; it composes queries through objects, and the authorizing WHERE/ON clauses "aren't added by the agent — they're injected by the capability layer" at AST compile time. Whole classes of injection become structurally impossible, not merely filtered. His live CTF pits a prompt-only guard (fell immediately) against the capability layer (the standing ~$1K bounty) — a hands-on proof that whitelisting what can be expressed beats blacklisting what looks bad (object-capability SQL).

💡 The rule of thumb: if the boundary lives inside the process the agent controls, it's a suggestion, not a boundary. Enforce isolation one layer down — a separate process, a WASM runtime, a kernel LSM — where the agent's code cannot reach the enforcement logic.

Least privilege at the tool layer

Confining the process still leaves the tools over-permissioned. The nono project frames the gap as "access without boundaries": agents get full filesystem, network, and credential access by default, when they need a sliver. Its answer is kernel-enforced, deny-by-default capability — start with zero file/network/exec rights and grant only what the task needs (nono run --allow ./project -- agent) via Landlock on Linux (kernel ≥5.13) and Seatbelt on macOS. The philosophy is the through-line of the whole week: "if the agent is running inside the application, then the application's security controls are just suggestions" — so enforcement moves to the kernel, where it's irreversible (nono — why I built it · nono GitHub).

For MCP specifically, agent-airlock sits in the tool-call path: it validates arguments, strips ghost arguments the model was told to smuggle, masks PII, enforces RBAC, and guards STDIO transports — the operational counterpart to the tool-poisoning and command-injection families catalogued in Week 15 (agent-airlock). And the dual-LLM pattern — a privileged planner that never sees untrusted data and a quarantined executor that does but holds no capabilities — turns least-privilege into an architecture: the component that can be injected can't act, and the component that can act can't be injected.

Escapes: the boundary loses to confusion, not force

Study the failures and one pattern dominates — the boundary is defeated by two components disagreeing about the same string or state, never by out-muscling the kernel.

• TOCTOU races are the top escape pattern in agent frameworks. The Claw Chain (OpenClaw, four chained CVEs) races time-of-check against time-of-use, layering env-var injection and a trust-flag bypass; the deeper lesson is that discovery-layer validation without execution-layer enforcement is reliably exploitable — filtering the tool list means nothing if the call isn't re-checked (cross-ref Week 15) (Cyera).
• Path / symlink confusion repeatedly breaks Claude Code's own sandbox: a symlink inside the workspace escalated to arbitrary write → RCE (CVE-2026-39861, CVSS 10.0, fixed v2.1.64), and a git-worktree named .git navigated outside the seatbelt (CVE-2026-55607, "Friendly Fire," fixed v2.1.163). Both are path canonicalisation failures, not permission failures.
• Parser differentials leak past allowlists: the SOCKS5 null-byte bypass let evil.com\x00.google.com pass a JS endsWith() check while libc getaddrinfo() truncated at the null byte and resolved the attacker host — an exfil channel for ~130 releases (Aonan Guan).

🔑 The escape-hardening checklist: re-validate at the point of use, not just discovery; canonicalise every path/host before you match it; prefer exact-host allowlists over wildcards; and reject \x00, %, and CRLF in anything that will cross a parser boundary.

The sandbox product is software too

A sandbox is only a boundary if the sandbox itself is sound — and an agent-isolation product is ordinary software carrying ordinary bugs. NVIDIA's August-2026 bulletin for OpenShell (its "containment boundary around agents and their tools") and NemoClaw (the local inference service) fixed 20 flaws, two of them CVSS 9.9, all in the code whose entire job is to do the containing (NVIDIA bulletin · THREATINT):

• CVE-2026-65093 (9.9, CWE-427 uncontrolled search path) — a direct sandbox escape → code execution, privilege escalation, data tampering, information disclosure. The isolation layer is broken from inside.
• CVE-2026-65083 (9.9) — the sandbox provisioning API generates an incomplete disallow-list, so operations that should have been blocked slip through. This is the chapter's deny-by-default rule proven in the negative: a blocklist is only as good as its completeness, and completeness is exactly what the attacker attacks. A guard that must enumerate the forbidden fails open the moment its list has a hole.
• CVE-2026-65092 (8.5, CWE-22 path traversal) — ../ sequences escape the sandbox's L7 REST network-policy boundary → the path-confusion class again, now one layer down in the guard rather than the workload.
• CVE-2026-65091 (8.8) — OS command injection via a malicious gateway.

The lesson NVIDIA states plainly is this week's thesis restated by the vendor who builds the boundary: sandboxing must remain an independent control even when the model, agent, and input are all trusted — which means the isolation runtime itself needs the same adversarial scrutiny as the code it confines. Two of these four bugs are the exact failure modes named above — an incomplete blocklist (prefer deny-by-default) and a path-traversal bypass (canonicalise-then-confine) — appearing not in the contained workload but in the container.

🔑 Audit the guard, not just the guest. When you add a sandbox to the stack you add attack surface, not just remove it. Pin its version, track its CVE feed, and prefer isolation whose enforcement is deny-by-default (a hole fails closed) over any product that ships an enumerated disallow-list (a hole fails open).

Network isolation & zero trust

The last boundary is egress. An injected agent that can't phone home can't exfiltrate, so default-deny the network and allow only pinned, exact endpoints — the same NIST zero-trust logic applied to a machine principal: never trust by network location, verify every request, assume breach (NIST SP 800-207). Anthropic's Zero Trust for AI Agents operationalises this for autonomy across three maturity tiers — Foundation (cryptographic identity + task-scoped permissions), Advanced (sandboxing, I/O controls, memory safeguards), Optimized (AI-accelerated defence) — and an eight-phase rollout from identity through supply-chain to defensive ops, explicitly countering prompt injection, tool poisoning, memory poisoning, privilege abuse, and supply-chain attack. Its posture is one line: trust nothing, verify everything, assume breach has already occurred (Anthropic).

💡 Kiya check. Our six agents run as claude -p subprocesses under workspace confinement with bypassPermissions — safety comes from the workspace boundary and behavioural guardrails, not permission prompts. That is exactly the model this week hardens: pair it with a filtering egress proxy (exact-host allowlist, reject null bytes) and per-agent tool scoping, and a compromised agent stays in an empty room.

🎯 OSAI exam depth — Reconnaissance (m2): fingerprinting exposed AI infrastructure

Everything above hardens your agent; the exam flips the chair — you are the attacker mapping someone else's AI stack, unauthenticated, from the outside. The defining property of AI infrastructure recon is that the targets advertise themselves: model servers run on predictable ports, ship without auth by default, and expose description endpoints whose entire purpose is to tell you what they are. You inventory them without firing a single exploit (Zenity honeypot data).

This is not a hypothetical exercise: Zenity's honeypots (Ollama :11434, LiteLLM :4000, LangServe :8000, OpenClaw :18789) logged a sustained Feb–Jun 2026 campaign that walks the exact methodology below — ~60,000 liveness probes from 235 IPs, ~31,000 model-catalog queries (/v1/models, /api/tags) from ~1,000 IPs, and 446 "identify yourself" prompts in multiple languages — with 9 of the top-10 source IPs already flagged malicious on threat-intel feeds. The tell of automation: one IP fired identical "Hi" prompts 2,619 times at each of eight discovered models; another rotated 40 API-key guesses across 31 models. Exposure is discovered and abused within hours, not months (Zenity).

Passive discovery — Shodan / FOFA / Censys dorks. Start where the internet is already indexed. Shodan auto-applies an ai tag and a structured product classifier, so product:"Ollama" returns ~25k confirmed hosts and a plain port:11434 country:"ru" product:"Ollama" dork surfaces 150+ services in one region with zero packets sent by you (Vectra — Shodan & FOFA · Cisco — exposed Ollama). Run the same intent through FOFA and Censys — coverage differs, and one engine routinely indexes hosts the others miss. Layer a banner keyword on the port to kill false positives (port:11434 "Ollama"; the Server: uvicorn header is the secondary confirming tell). One caveat the count hides: in Cisco's own scan, 1,139 exposed Ollama hosts but only ~19% (214) were actually serving a model — most are dormant, so the raw exposure number overstates the live attack surface; confirm a model is loaded (/api/tags non-empty) before you count a host as a target. GitHub is a second passive channel: dork for leaked HF_TOKEN, MLFLOW_TRACKING_URI, and OPENAI_API_BASE values pointing at private endpoints.

The AI port map — memorize it. Fingerprinting is mostly "which port + which banner + which description endpoint":

Active enumeration — make the platform describe itself. Once a host answers, walk its native API to inventory the whole ML estate without exploiting anything: on MLflow, five calls (experiments → registered models → model versions → runs → artifact listings) map every model, its artifact URI, and the user IDs behind it; on Triton/TF-Serving, model config endpoints leak tensor shapes and framework; on vector DBs, schema/collection endpoints reveal the embedding model and data types; on Jupyter, kernel listings and notebook cell contents frequently expose cleartext credentials (TryHackMe — AI System Reconnaissance walkthrough). The exam-ready five-phase methodology: ① passive (Shodan/FOFA/GitHub dorks) → ② port scan (Nmap with the AI-specific port list above) → ③ API fingerprint (curl/grpcurl on /v1/models, /v2, /api/tags, header & error-shape analysis) → ④ metadata extraction (MLflow/Triton/Jupyter/vector enumeration) → ⑤ supply-chain review (requirements.txt, Pipfile, exposed container-registry tags) (Hackers-Arise — recon on AI infra).

Tooling — AIMap. AIMap automates the whole chain: 32 preset Shodan-tuned discovery queries, protocol-aware fingerprinting, an exposure score, and authorized protocol-specific attack tests across MCP, Ollama, vLLM, LiteLLM, LocalAI, LangServe, Open WebUI, TGI, and generic inference APIs — the nmap of the AI attack surface (Help Net Security — AIMap).

🧪 Drill — fingerprint your own lab. Stand up Ollama + vLLM + MLflow in containers, then from a second host run: nmap -p 11434,8000,5000,8265 -sV the target, curl http://T:11434/api/tags, curl http://T:8000/v1/models, and curl http://T:5000/api/2.0/mlflow/registered-models/search. You've now inventoried every model + artifact path with no exploit — that is the m2 deliverable. Then Shodan-dork product:"Ollama" and diff what a real attacker sees.

🎯 OSAI exam depth — Infrastructure & Deployment Exploits (m9)

Recon hands you live, unauthenticated endpoints; m9 is turning them into code execution and cloud takeover. Three attack surfaces dominate: the inference server, the container/orchestration layer, and the managed cloud AI platform. The connective tissue across all three is that these tools were built assuming a "trusted internal network" that operators routinely violate by exposing them.

Model-server / inference-engine RCE. These are the crown jewels — an RCE here yields the models, the data flowing through them, and the (often GPU-heavy) host:

• Ray — CVE-2023-48022 "ShadowRay" (CVSS 9.8, disputed/unpatched). The Jobs API on :8265 takes no auth by design, so an attacker who reaches the dashboard submits an arbitrary job = unauthenticated RCE. Because Anyscale disputed it, it never got a direct patch and is a "shadow" CVE invisible to static scanners. Exploitation is a single POST (or ray job submit) with a shell payload; ShadowRay 2.0 weaponized this into a self-propagating botnet that abuses Ray's own orchestration to fan out node-to-node, running cryptominers and stealing model weights/secrets (Oligo — ShadowRay 2.0 · Oligo — original ShadowRay).
• NVIDIA Triton — CVE-2025-23319/23320/23334 chain (unauth RCE). Wiz chained a minor info leak (CVE-2025-23320 leaks the Python backend's private IPC shared-memory region name) into full server takeover — a textbook "small leak → total compromise" chain against the Python backend. Fixed in 25.07; the lesson is that a leaked internal identifier is a foothold, not a footnote (Wiz — Triton vuln chain).
• vLLM — unsafe deserialization & memory bugs. CVE-2025-62164 (CVSS 8.8): the Completions API deserializes user-supplied prompt embeddings via torch.load() with integrity checks disabled (a PyTorch 2.8 default change) → RCE. CVE-2026-22778 (CVSS 9.8, vLLM 0.8.3–0.14.0, fixed 0.14.1): a video_url in a multimodal request reaches OpenCV→FFmpeg's JPEG2000 decoder (libopenjp2), where a crafted cdef (channel-definition) box overflows the heap and corrupts an adjacent function pointer. It chains with a second flaw — vLLM's error handler leaks raw heap addresses to the client, defeating ASLR — so the attacker aims the overflow precisely: unauth RCE via a single malformed video (Kodem — CVE-2026-22778). torch.load() on any attacker-influenced tensor/checkpoint is a recurring m9 primitive — treat every serialized model file as executable code (cross-ref the model-deserialization week).
• Ollama — CVE-2024-37032 "Probllama" (unauth RCE). A path-traversal in the model-pull digest handling lets a crafted manifest write outside the blob dir → RCE against any exposed :11434 pre-0.1.34 (Wiz — Probllama).
• TorchServe exposes a management API on :8081 that can register a model from an attacker URL — model load = code execution as a built-in feature when exposed (Wiz — inference-server RCE roundup).

Containerized ML workload attacks. ML clusters are prime targets because the nodes carry GPUs. The dominant pattern is misconfiguration abuse, not a kernel 0-day: an internet-exposed Kubeflow dashboard (operators override the Istio-internal default) lets anyone deploy pods; attackers push a recon container to profile CPU/GPU, then legit-looking tensorflow:latest / latest-gpu images running XMRig (CPU) + Ethminer (GPU/CUDA), named sequential-pipeline-{random} to blend into real Kubeflow Pipelines (Microsoft/BleepingComputer — Kubeflow cryptomining · Hacker News — Kubeflow crypto-mining). JupyterHub is the same story: Kubeflow's custom-notebook-image feature lets an attacker run any image as a "notebook," so an exposed hub = arbitrary container in your cluster. From a foothold pod, escalation to the host uses the same container-escape families from earlier this week plus GPU-specific ones — the NVIDIA Container Toolkit "Leaky Vessels"-class flaws (CVE-2024-0132) break container→host on GPU nodes. Detection is hard because node-load alerts fire on legit training too; runtime tools like Falco (syscall-level) are what distinguish a miner from a real job (arXiv — multi-tenant scientific K8s / Falco).

Cloud AI platform exploits. Managed platforms bundle a broad managed identity with workload execution, so any code-exec inside the workload becomes cloud-account privilege escalation via the metadata service:

• Azure ML — CVE-2025-49747 (CVSS 9.9, missing authorization). The service skips authz on certain resource/role-assignment API calls, letting an authenticated low-priv user elevate over ML resources. Pair it with the Wiz/Orca storage-based privesc: AML ran invoker scripts from a Storage Account with the compute instance's broad identity, so write access to that bucket → replace the script → run as creator/Owner on the subscription (ZeroPath — CVE-2025-49747).
• AWS SageMaker — role/PassRole abuse. Classic chain: enumerate SageMaker
  • IAM via the CLI, find a notebook role holding iam:PassRole + sagemaker:CreateNotebookInstance, then CreateNotebookInstance bound to a more privileged role and CreatePresignedNotebookInstanceUrl to walk in — pivoting from one dev-account notebook to prod Bedrock guardrails and RAG knowledge bases. AWS calls it "operating as expected," which is exactly why it's exam-relevant (Security Risk Advisors — AWS/GCP ML privesc · Recorded Future — 2025 cloud threat landscape).
• GCP Vertex AI — service-agent lateral movement. Vertex service agents carry broad default permissions, so compromising the workload execution environment converts into project-wide privesc; custom training/prediction jobs run attacker code that reads the metadata server (169.254.169.254) for the service-agent token (CSA — Vertex AI service-agent privesc).

🔑 The m9 through-line. Recon gives you an unauthenticated endpoint → inference RCE or dashboard abuse gives you code exec on the node → the node's metadata service gives you the cloud identity → over-broad managed permissions give you the account. Every hop is a default someone trusted, not a memory corruption. On the 24h exam, always try the boring path first: is it exposed, does it need auth, what does the metadata service hand me.

🧪 Drill — inference RCE to identity. In a lab: expose a pre-0.1.34 Ollama or an unauth Ray dashboard, get code exec (Ray: ray job submit -- 'id'), then from the shell curl -H "Metadata-Flavor: Google" http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token (or the AWS/Azure IMDS equivalent) and confirm you can mint a cloud token. That single chain is the entire m9 kill chain in miniature.

📇 Sandbox & escape CVE reference

The prose above is what to learn; this is the catalog behind it. Folded by default — expand for the detail. Each escape below is an instance of one of three root causes.

Read the escapes through three root-cause classes

Escape case studies

• Claw Chain (OpenClaw, May 2026) — four chained CVEs; TOCTOU race + env-var injection + trust-flag bypass. Canonical proof that discovery-layer validation without execution-layer enforcement is exploitable. Cross-ref Week 15. Source: Cyera [May-21]
• CVE-2025-9959 (smolagents, CVSS 7.6) — incomplete dunder-attribute validation in the Local Python executor → prompt-injection-triggered escape to subprocess.Popen. Fixed 1.21.0; JFrog advises the WASM executor. Pattern: language-level sandboxing is structurally unsound. Source: JFrog [May-25]
• CVE-2026-39861 (Claude Code, CVSS 10.0) — symlink inside workspace → arbitrary file write → RCE. Fixed v2.1.64. Path-confusion class. [May-12]
• CVE-2026-55607 ("Friendly Fire," Claude Code, CVSS 7.7) — git-worktree named .git navigates outside the seatbelt sandbox via symlink + fsmonitor. Affected >=2.1.38,<2.1.163; fixed v2.1.163. Our VPS runs 2.1.183 — patched. [Jun-27]
• Claude Code SOCKS5 null-byte bypass (no CVE) — parser differential: JS endsWith() allowlist vs libc getaddrinfo() null-byte truncation; evil.com\x00.google.com resolved to evil.com. Affected v2.0.24–v2.1.89; fixed sandbox-runtime 0.0.43. Lesson: exact-host > wildcard. Source: Aonan Guan [Jun-24]
• NVIDIA OpenShell batch (Aug 2026, affects ≤0.0.33, fixed v0.0.34) — the isolation product is attack surface: CVE-2026-65093 (9.9, CWE-427 uncontrolled search path) sandbox escape → RCE/privesc; CVE-2026-65083 (9.9) sandbox-provisioning API builds an incomplete disallow-list so blocked ops slip through (blocklist-completeness failure — prefer deny-by-default); CVE-2026-65092 (8.5, CWE-22) path traversal bypasses the L7 REST network policy; CVE-2026-65091 (8.8) OS command injection via a malicious gateway. Part of a 20-flaw bulletin for OpenShell + NemoClaw. Source: NVIDIA bulletin a_id/5872 · THREATINT [Aug-25]

AI infrastructure & deployment exploits (m9 offensive)

• CVE-2023-48022 ("ShadowRay," Ray, CVSS 9.8, disputed/unpatched) — unauthenticated Jobs API on :8265 → RCE by design; ShadowRay 2.0 turned it into a self-propagating cryptojacking botnet. Source: Oligo
• CVE-2025-23319 / -23320 / -23334 (NVIDIA Triton) — info-leak → full unauth RCE chain via the Python backend; fixed 25.07. Source: Wiz
• CVE-2025-62164 (vLLM, CVSS 8.8) — torch.load() on user prompt embeddings with integrity checks off → RCE. CVE-2026-22778 (CVSS 9.8, fixed 0.14.1) — multimodal video_url → libopenjp2 JPEG2000 cdef-box heap overflow + ASLR-defeating heap-address leak → unauth RCE. Source: Kodem
• CVE-2024-37032 ("Probllama," Ollama) — path-traversal in model-pull digest handling → unauth RCE against exposed :11434 pre-0.1.34. Source: Wiz
• CVE-2025-49747 (Azure ML, CVSS 9.9) — missing-authorization privilege escalation over ML resources; pair with the storage-based invoker-script privesc to Owner. Source: ZeroPath
• CVE-2024-0132 (NVIDIA Container Toolkit, "Leaky Vessels"-class) — container→host escape on GPU nodes, the escalation leg of containerized-ML attacks. Self-cites.
• MLflow LFI chain (CVE-2024-2928 / -3573 / -3848 / -8859) — unauth arbitrary file read on exposed tracking servers via URI-fragment/scheme path traversal; harvest SSH/cloud keys for pivoting. Source: OffSec