"What is the central design philosophy of B7 (the blast-radius principle), and how does it invert the naive intuition?"	"The naive intuition is 'harden the sandbox so it cannot be escaped' — wrong goal. Every sandbox is software, every sandbox has CVEs, every sandbox will eventually be escaped. B7's principle: ASSUME the sandbox will be escaped, and design so an escaped sandbox still has NO CREDENTIALS and NO NETWORK. The escape becomes a detected-and-killed anomaly, not an incident. The value of escape is what you can reach after escaping — design so the answer is 'nothing.'"	c2b::b7::recall
"What is the difference between Course 1 Module 5 and Course 2B B7 on sandboxing?"	"Course 1 Module 5 teaches HOW TO BUILD a sandbox (inside-vs-outside split, provider table, filesystem/network scoping) against the threat of a MISBEHAVING-BUT-HONEST agent (accidents: over-long loops, mis-scoped writes). B7 teaches how the sandbox FAILS UNDER AN ADVERSARY who controls the agent's inputs — an agent under prompt-injection coercion induced to run ATTACKER-CHOSEN CODE inside the sandbox. The controls must be stronger, the threat model is adversarial, and the design philosophy inverts (assume escape)."	c2b::b7::recall
"List the isolation hierarchy from weakest to strongest, with the escape surface of each."	"(1) OS PROCESS — boundary: UID/gid + kernel; escape surface: whole user account. (2) CONTAINER (Docker) — namespaces + cgroups; boundary = the Linux kernel (CVE-rich). (3) HARDENED CONTAINER — gVisor (userspace kernel) / Kata (lightweight VM); boundary = runsc/hypervisor. (4) MICROVM (Firecracker) — stripped KVM hypervisor; small, audited surface. (5) WASM/V8 ISOLATE — linear memory + capability exports; boundary = runtime + your exports. (6) FULL VM — KVM/Hyper-V; hypervisor (rarely the right answer for an agent sandbox)."	c2b::b7::recall
"Why is plain Docker a DEFECT (not just a weakness) for an agent sandbox that runs attacker-influenced code?"	"Default Docker's security boundary is the Linux KERNEL itself — a large, CVE-rich surface. Container breakouts happen via kernel CVEs (Dirty Pipe), misconfigured capabilities (CAP_SYS_ADMIN), privileged mode, or the mounted Docker socket. For code the agent merely invokes, this may be tolerable. For code the agent WROTE, gVisor/Kata is the floor. For code the agent was COERCED into running (injection), you need a microVM (Firecracker) or WASM isolate. Most shipped agent sandboxes sit at plain Docker regardless — that is the defect B7 exists to fix."	c2b::b7::recall
"Name the four attack vectors against an agent sandbox and the control for each."	"(1) ESCAPE — exploit a bug in the provider (V8, kernel, gVisor) to reach the host → CONTROL: blast-radius principle (assume escape; pick a stronger point on the hierarchy). (2) NETWORK EGRESS — exfiltrate, C2, lateral move, SSRF metadata → CONTROL: default-deny egress with per-task allowlist (the MOST under-applied control). (3) RESOURCE EXHAUSTION (OWASP ASI09) — run forever, fill disk, OOM, fork-bomb → CONTROL: hard resource caps (cgroups). (4) SIDECAR COMPROMISE — suborn a privileged helper (root package installer) → CONTROL: privilege minimization on every helper."	c2b::b7::recall
"Why is network egress (vector 2) the most under-applied control, and what does it contain that filesystem scoping does not?"	"Operators fixate on the filesystem mis-scope that COUGHS UP the secret and ignore the network that CARRIES IT OUT. But exfiltration requires BOTH bugs (the read AND the network reach) — kill either and the exfiltration fails. Default-deny egress is the EASIER bug to fix (a network-layer policy vs hunting every filesystem scope) AND contains the larger class of outcomes: not just secret exfiltration but also C2 callbacks, lateral movement into internal networks, and SSRF against the cloud metadata service (169.254.169.254)."	c2b::b7::recall
"Why is the cloud metadata service (169.254.169.254) a special-case must-block at the network layer?"	"The metadata service hands out INSTANCE CREDENTIALS to anything that can reach it — the host's cloud IAM role, temporary tokens, sometimes user-data scripts with embedded secrets. A sandboxed agent that can reach metadata can STEAL THE HOST'S CLOUD ROLE, which is a far worse outcome than reading a local secret (cloud roles often have broad permissions across the account). Default-deny egress blocks this for free; an allowlist that does not explicitly list it blocks it for free; an LLM-judge-only model is one prompt injection away from failing to block it. Block the metadata service at the network layer, always."	c2b::b7::recall
"Why do allowlist command policies outperform denylists? Explain the failure mode of each."	"DENYLIST = 'things you have thought of' — block curl, then wget, then python -c, then perl, then git clone with a hook, then directly invoking libc. The attacker's job is to find ONE command you didn't think of; the space of 'things that fetch a URL or run code' is UNBOUNDED. ALLOWLIST = 'things the task needs' — ls, cat, grep, git status, pytest. The attacker's job becomes: make an ALLOWED command do harm (argument injection, vulnerable subcommand) — a bounded, auditable surface. Allowlist inverts the failure mode from 'infinite attack surface' to 'finite, reviewable surface.'"	c2b::b7::recall
"What is a per-tool execution scope, and what attack does it prevent?"	"Each TOOL carries its OWN allowlist rather than one monolithic 'what can the sandbox run' list. The run_tests tool may invoke pytest and make; the format_code tool may invoke prettier and black; the install_deps tool may invoke pip install ONLY through the validating proxy. The sandbox enforces 'the command must match the calling tool's scope' before exec. This prevents a coerced agent from invoking pytest from INSIDE the install_deps tool (or git from inside the pytest tool) — the tool's scope is the enforcement boundary, closing cross-tool command-injection paths."	c2b::b7::recall
"Contrast the IronCurtain (deterministic) and CrabTrap (LLM-as-judge) enforcement models for execution policy. Which is correct for security-critical runtime decisions and why?"	"IRONCURTAIN: policy written in plain English, compiled OFFLINE by an LLM into deterministic JSON rules; runtime enforcement is pure if/then matching, ZERO LLM at runtime; miscompilation caught by verify-and-repair at build time. CRABTRAP: each invocation evaluated by a runtime LLM seeing command+args+policy, returning allow/deny; flexible but PROBABILISTIC — a prompt injection in the arguments can manipulate the judge. For SECURITY-CRITICAL decisions, deterministic (IronCurtain) is correct: the allowlist is a finite enumerable set, there is no semantic question the LLM needs to answer at runtime, and the blast radius of probabilistic enforcement is the set of inputs where the LLM happens to be wrong."	c2b::b7::recall
"How does B7's network-layer default-deny egress differ from CrabTrap's egress governance, and why do you want both?"	"CrabTrap (DD-19) governs egress at the LLM-JUDGE layer: every outbound request evaluated against a natural-language policy by an LLM. This answers the SEMANTIC question ('is this request something this agent should be making?') probabilistically. B7's network-layer default-deny (iptables/nftables/egress proxy/microVM NIC) answers the EXISTENCE question ('should this sandbox reach the network at all?') DETERMINISTICALLY. You want both because the network-layer control is what HOLDS when the LLM judge is bypassed, confused, or absent. CrabTrap sits ON TOP of the network gate, not in place of it — a sandbox relying on CrabTrap alone is one prompt-injection of the judge away from exfiltration."	c2b::b7::recall
"What four signal classes does a sidecar monitor watch, and what attack does each catch?"	"(1) RESOURCE — CPU/mem/disk/proc-count time series; a spike = ASI09 resource exhaustion or escape in progress. (2) SYSCALL (seccomp-bpf, eBPF, gVisor log) — a grep issuing socket()+connect()+fork() is not grep; catches escape attempts and behavioral anomalies. (3) NETWORK — connection attempts (allowed AND denied), DNS, byte volumes; a denied-connection BURST to one host = C2 attempt signature. (4) BEHAVIORAL — repeated failures (brute force), unusual command sequences (git from inside the pytest tool), unexpected file paths. The monitor DETECTS; the B7.2 controls PREVENT. Output feeds B8's observability pipeline."	c2b::b7::recall
"Why must the sidecar monitor run OUT-OF-BAND (outside the sandbox's trust boundary)?"	"A monitor that runs INSIDE the sandbox is a monitor the contained code can KILL before misbehaving — disabling the alarm before setting the fire. The out-of-band position (kernel-side eBPF/Falco, host-side process, separate namespace) means the contained code has NO PATH to disable or tamper with the monitor. This is the same 'governance beneath/beside the agent' principle from DD-09 NemoClaw applied to monitoring: if the agent (or the code it was coerced into running) can reach the enforcement/observation layer, a compromised agent can disable it."	c2b::b7::recall
"What is IronCurtain's credential quarantine, and how does it realize the blast-radius principle?"	"The agent is configured with FAKE API keys (e.g. FAKE_ANTHROPIC_KEY_abc123). When the agent makes an LLM API call, the request hits IronCurtain's TLS-terminating MITM proxy, which REPLACES the fake with the REAL key before forwarding, and SCRUBS any key reflection from error bodies on the way back. The agent NEVER sees a real credential. Realization of the blast-radius principle: even a fully-compromised, fully-ESCAPED agent cannot exfiltrate real credentials because it does not HAVE them. The worst it can do is use the fakes, which only work through IronCurtain's controlled proxy. This is the strongest defense against credential exfiltration studied in the course."	c2b::b7::recall
"What is OpenShell (DD-09, NemoClaw), and what is its load-bearing architectural principle?"	"OpenShell is NemoClaw's SANDBOX LAYER — the reference implementation for B7. Its load-bearing principle: THE AGENT NEVER TOUCHES THE SANDBOX DIRECTLY; every execution request goes through the GOVERNED API, which brokers access to an isolated execution environment. The agent cannot reach the sandbox to reconfigure it, disable its caps, or modify its egress policy. This principle applies regardless of which technology (container, microVM, WASM) sits behind the governed API — the architectural invariant is the brokered, unreachable boundary."	c2b::b7::recall
"What is the sidecar-compromise vector (vector 4), and what is the canonical instance?"	"The sandbox spawns a HELPER PROCESS — a language server, a file-format converter, a package installer, a TLS-terminating proxy — that runs with MORE privilege than the contained code. The contained code attacks the helper, and THROUGH the helper reaches something the sandbox itself could not. Canonical instance: a package installer that runs as ROOT inside the container and is tricked into running a malicious postinst script from a typosquatted npm/PyPI package. IronCurtain mitigates this by routing npm/PyPI installs through a VALIDATING REGISTRY PROXY, not the public registry."	c2b::b7::recall
"State the three concrete realizations of the blast-radius principle."	"(1) NO CREDENTIALS IN THE SANDBOX — sandboxed process has no API keys, no cloud-role reachability (network-layer block on metadata), no secrets in env/fs; IronCurtain's fake-key swap. (2) NO NETWORK FROM THE SANDBOX — the namespace's default-deny with per-task allowlists SURVIVES the escape; reaching the host kernel does not grant a new NIC. (3) NO PRIVILEGED HELPERS — every subprocess runs with minimum privilege (no root, no extra capabilities, capability-scoped IPC). Design so an escape is a detected-and-killed anomaly, not an incident."	c2b::b7::recall
"What is OWASP ASI09, and which sandbox control contains it?"	"ASI09 = Excessive Agency / Resource Exhaustion in agentic systems. An agent coerced (via injection) into running indefinitely (while true: pass), downloading a multi-gigabyte file into /tmp, a tight fork-bomb, or a loop that bills the LLM provider. It is the SANDBOX's problem because the sandbox is where the code executes. CONTROL: HARD RESOURCE CAPS — CPU, memory, wall-clock, process count, disk-write quota — enforced by cgroups (container), the hypervisor (microVM), or the runtime (V8 fuel, WASM gas). A sandbox without caps can be made to fail-open (OOM-kill the monitor) or fail-costly (run up the bill)."	c2b::b7::recall
"What is the tradeoff curve the isolation hierarchy sits on, and what determines the correct point on it?"	"The curve trades ISOLATION STRENGTH (blast radius if the contained code is hostile — decreases moving down the hierarchy) against OVERHEAD (cold-start latency, memory density, operational complexity — increases). The correct point is determined by WHAT CODE WILL RUN and WHO CHOSE IT: code the OPERATOR wrote and the agent invokes → process/container OK; code the AGENT wrote (generated script) → container minimum, gVisor preferred; code the agent was COERCED into running by injection → microVM (Firecracker) or WASM isolate AND the B7.2/B7.3 controls layered on top."	c2b::b7::recall
"An agent sandbox uses plain Docker and allow-all network egress because 'the agent needs web search.' Attack this design on two axes."	"(1) DOCKER is a defect for agent code — the boundary is the CVE-rich Linux kernel; gVisor or Kata is the floor. (2) ALLOW-ALL EGRESS is the most under-applied control — 'the agent needs web search' is an argument for the web_search tool reaching search.example-corp.net, NOT for reaching the whole internet. The defect conflates per-tool need with namespace-wide reachability. FIX: network-layer default-deny; per-tool/per-task allowlist (web_search → one host, install_deps → validating registry only); block 169.254.169.254 always. Default-deny contains secret exfiltration, C2, lateral movement, and SSRF-metadata in one control."	c2b::b7::analysis
"Your team proposes an LLM-as-judge command gate: every tool invocation goes to a runtime LLM that returns allow/deny. Why is this wrong for the allowlist, and what is the correct design?"	"WRONG because: (a) the allowlist is a FINITE ENUMERABLE SET — there is no semantic question the LLM needs to answer at runtime; (b) LLM judgment is PROBABILISTIC — a prompt injection in the command arguments can manipulate the judge into allowing a malicious call; (c) security-critical runtime decisions must be DETERMINISTIC. CORRECT design (IronCurtain model): write policy in plain English, COMPILE OFFLINE to deterministic JSON rules (allowlist patterns, per-tool scopes), VERIFY with a scenario pipeline at build time, enforce at runtime with pure if/then string matching — ZERO LLM at runtime. Reserve LLM-as-judge (if used at all) for the ARGUMENTS, and prefer structured validators (regex/schema/path-prefix) there too."	c2b::b7::analysis
"Design the egress policy for a sandboxed agent with three tools: web_search, fetch_docs, install_deps. What is the default, and what is the must-block special case?"	"DEFAULT: the network namespace starts with egress DENIED to everything. PER-TASK/TOOL ALLOWLIST: web_search → search.example-corp.net (and its search-API hosts); fetch_docs → docs.spec.host (the doc origin); install_deps → the VALIDATING REGISTRY PROXY only (not the public npm/PyPI registry — defends against typosquatting postinst scripts). MUST-BLOCK SPECIAL CASE: 169.254.169.254 (cloud metadata — hands out instance creds); block at the network layer always, even though no tool legitimately needs it. Enforcement at iptables/nftables/egress proxy/microVM NIC — NOT at an LLM judge (CrabTrap may sit on top for the semantic question, but the network layer is what holds when the judge fails)."	c2b::b7::analysis
"You discover your sandbox has no resource caps. Construct the ASI09 attack an injected agent could run, and the control."	"ATTACK (ASI09): an injected instruction coerces the agent into a generated script that does one or more of: while true: pass (burns CPU/bills the LLM provider); downloads a multi-gigabyte file into /tmp in a loop (fills disk); forks unboundedly (fork-bomb, exhausts PID table); allocates in a tight loop (OOM). The sandbox dutifully isolates the attack — and is itself killed or made to fail-open (OOM-killing the monitor) or fail-costly. CONTROL: hard resource caps enforced by CGROUPS (container) — cpuSeconds (wall-clock kill), memoryMb (OOM-kill the contained process, not the monitor), processCount (fork limit), diskWriteMb (write quota). Per-task thresholds (build tool may spike CPU; read_file may not). A sandbox without caps is a sandbox that can be weaponized against its own monitoring."	c2b::b7::analysis