# Deep-Dive SDD-B05 — IronCurtain Offensive Analysis **Course**: 2B — Securing & Attacking Harnesses and LLMs **Deep-Dive**: SDD-B05 · **Duration**: 45 minutes · **Level**: Senior Engineer and above **Prerequisites**: Course 1 DD-20 (IronCurtain); Course 2B B0–B2; SDD-B01, SDD-B02, SDD-B03, SDD-B04 > *IronCurtain (Course 1 DD-20) is the strongest defense in the roster — deterministic enforcement at runtime, credential quarantine, a V8 isolate sandbox, and a full runtime wrap. It is the defense to beat. This deep-dive finds the surface where it is still probabilistic (compilation fidelity — a deterministic policy compiled by a probabilistic LLM), where it is a memory-unsafe boundary (the V8 isolate), and where it still needs a human who can be fatigued (escalation). Each break is measured against InjecAgent (SDD-B03), mapped to what it proves, and resolved into the defense-in-depth that no single layer — not even IronCurtain — provides alone.* --- ## Learning Objectives After completing this deep-dive, you will be able to: 1. Map IronCurtain's attack surface from the offensive side: the offline compilation pipeline that turns plain English into deterministic JSON (a probabilistic LLM compiling the rules a deterministic runtime enforces), the V8 isolate that sandboxes agent-generated code, and the escalate-to-human mechanism that handles edge cases — and identify the three primary attack surfaces that follow. 2. Construct the compilation-fidelity attack: how an attacker-influenced constitution or scenario set causes the build-time LLM to compile a rule that the runtime then enforces deterministically — the wrong rule, enforced consistently — and what a successful break proves about the deterministic thesis. 3. Explain the V8 isolate boundary as a real but escape-prone sandbox: the historical `isolated-vm` and V8 CVEs, the per-call fuel and memory limits as a partial defense, and what an isolate escape would mean for the credential quarantine. 4. Analyze the escalation-fatigue attack: how flooding the human-in-the-loop with approval requests conditions rubber-stamping, why it is the deterministic analogue of the latency/cost pressure on CrabTrap (SDD-B04), and what rate-limiting and batching partially control. 5. For each break, state precisely what it proves, what residual risk remains after IronCurtain's mitigation, and why no single layer suffices — framing the whole analysis as the motivation for defense-in-depth (B2's thesis). 6. Translate the IronCurtain offensive analysis into an engagement deliverable: the per-surface attack procedures, the compilation-fidelity fuzz harness, the escalation-fatigue simulator, and the layered prescription the client patches toward. --- ## Why this deep-dive exists Course 1's DD-20 introduced IronCurtain as the purest expression of beneath-agent governance: the agent is untrusted; security does not depend on the model being good. Two mechanisms make it architecturally distinct. The credential quarantine: the agent runs with fake API keys, a TLS-terminating MITM proxy hot-swaps fake for real at the boundary, and the agent never holds real credentials. The deterministic policy compilation: you write policy in plain English, an offline LLM pipeline compiles it to deterministic JSON rules, and at runtime enforcement uses zero LLM — pure if/then checks. SDD-B04 attacked CrabTrap, the probabilistic counterpoint, and found that the LLM-as-judge at runtime is injectable. The deterministic-first prescription pointed at IronCurtain as the fix: move the LLM to build time, remove it from runtime, and the judge-injection surface structurally disappears. That prescription is correct as far as it goes. This deep-dive is where it stops. The honest question: if IronCurtain has no runtime judge, where is the surface? Three answers, and each is a structural property of the design, not an implementation bug: First, **the deterministic policy is compiled by a probabilistic LLM.** IronCurtain's thesis is that LLMs are stochastic and security policy must be deterministic — so it removes the LLM from runtime. But the compilation step that produces the deterministic rules is itself an LLM, running at build time. The LLM is not eliminated; it is relocated. If the build-time LLM misinterprets the constitution during compilation, the wrong rule gets baked into the deterministic runtime — and the wrong rule is enforced consistently. You get predictable enforcement of potentially-wrong rules. This is the compilation-fidelity gap, and it is the target of the primary break. Second, **the sandbox is a V8 isolate, which has had escape CVEs.** IronCurtain's Code Mode runs agent-generated TypeScript in `isolated-vm`. The isolate is a hardened JavaScript-level execution boundary with per-call fuel and memory limits — not OS-level virtualization. V8 and `isolated-vm` have a history of sandbox-escape CVEs (type confusion, bounds errors, JIT bugs). An isolate escape is the path from "compromised agent" to "reaching the real credentials the quarantine is supposed to deny." The quarantine holds only as long as the isolate does. Third, **the deterministic system still needs a human in the loop for edge cases.** IronCurtain's escalate-to-human mechanism (terminal mux, Signal on mobile) pauses the agent and prompts the human for an allow/deny/whitelist decision. The optional LLM auto-approver handles unambiguous cases, but edge cases escalate. An attacker who can generate edge cases can flood the human with approval requests until rubber-stamping becomes the path of least resistance. This is escalation fatigue, and it is the deterministic analogue of the latency/cost pressure on CrabTrap's judge — a defense that is expensive to honor is a defense the human will defeat. Three sub-sections, fifteen minutes each: - **B05.1 — The Attack Surface: Compilation, Isolate, Escalation.** Mapping IronCurtain's architecture to its three primary attack surfaces, and what each surface's existence proves about the deterministic thesis. - **B05.2 — The Three Breaks.** The compilation-fidelity attack, the V8 isolate escape analysis, and the escalation-fatigue simulator — each constructed, each measured against InjecAgent, each mapped to what it proves. - **B05.3 — Defense-in-Depth: Why No Single Layer Suffices.** The residual risks after each break, the layered prescription that combines deterministic compilation, probabilistic review, sandbox defense-in-depth, and escalation rate-limiting — B2's thesis that this analysis is the motivation for. --- # B05.1 — The Attack Surface: Compilation, Isolate, Escalation *IronCurtain's architecture, read as an attacker. Three surfaces fall out of the deterministic design itself.* ## The deterministic thesis, restated for offense IronCurtain's thesis (quoting the DD-20 architect's verdict): the agent is untrusted; security does not depend on the model being good. Operationally, this means two things. At runtime, enforcement is deterministic JSON rule evaluation — zero LLM, no judge to inject, no semantic surface for request-body manipulation (the SDD-B04 Break 1 vector). And at the boundary, the agent holds fake credentials — even a fully compromised agent cannot exfiltrate real secrets because it does not have them. Read defensively, this is the strongest position in the roster. The two surfaces SDD-B04 broke (the injectable judge, the credential-exfil path through the judge) are structurally closed. Read offensively, the question is not "can we re-run the SDD-B04 attacks?" — we cannot, the judge does not exist at runtime. The question is "where did the probabilistic component go, and what are the new boundaries?" Three surfaces fall out. ## Where the probabilistic component went: the compilation pipeline The LLM was not eliminated; it was relocated to build time. IronCurtain's constitution pipeline runs offline: ``` constitution.md → [Annotate] → [Compile] → [Resolve Lists] → [Generate Scenarios] → [Verify & Repair] → compiled-policy.json (content-hash cached) ``` Each stage is an LLM call. The Compile stage translates English to deterministic if/then rules. The Generate Scenarios stage creates test cases. The Verify & Repair stage runs an LLM judge to repair failures, up to two rounds, and the build fails if the policy cannot be verified. This is a real defense — the verify-and-repair pipeline catches many miscompilations. But it does not eliminate the root property: **a probabilistic system is producing the rules a deterministic system enforces.** The verification is itself an LLM, judging the compilation of another LLM. A miscompilation that the verifying LLM agrees with passes. This is the structural surface. The deterministic runtime is only as correct as the compilation that produced it. An attacker who can influence the constitution (via the scenario set, the resolved lists, or the constitution text itself) can attempt to steer the compilation toward a rule that permits the attacker's intended action. The rule, once compiled, is enforced deterministically — consistently, predictably, and without the runtime chance of refusal that a CrabTrap-style judge would provide. ## The three primary attack surfaces From the architecture, three surfaces fall out. Each has a structural cause rooted in the deterministic design itself. | Surface | Structural cause | The break (B05.2) | | --- | --- | --- | | **Compilation fidelity** (the build-time LLM) | The deterministic policy is compiled by a probabilistic LLM; verify-and-repair mitigates but does not eliminate | Steer the compilation toward a permissive rule via constitution/scenario/list manipulation | | **The V8 isolate boundary** | Code Mode runs agent TypeScript in `isolated-vm`; a JS-level sandbox with escape CVE history | Analyze the escape path from isolate to the proxy that holds the real credentials | | **Escalation fatigue** (the human-in-the-loop) | Edge cases escalate to a human; a human who is flooded rubber-stamps | Flood the escalation channel until auto-approve becomes the path of least resistance | Note what is *not* on this list: the runtime enforcement engine. Pure if/then rule evaluation against a JSON policy has no semantic surface. You cannot inject an if-statement. The runtime is the part of IronCurtain that genuinely has no attack surface beyond the policy it enforces — and the policy is the compilation output, which is surface one. This is why the compilation step is the load-bearing break: it is the only place a probabilistic system touches the deterministic enforcement. ## What each surface's existence proves Each surface is evidence of a structural property, not just a finding: - The compilation-fidelity surface proves that **relocating the LLM from runtime to build time does not eliminate the probabilistic component — it concentrates it.** A single miscompilation becomes a consistently-enforced wrong rule. The deterministic thesis is correct about runtime; it is incomplete about build time. - The V8 isolate surface proves that **the credential quarantine holds only as long as the sandbox does.** The quarantine is the strongest primitive in the course — but it depends on the agent being unable to reach the proxy. An isolate escape is the path from "compromised agent" to "real credentials." - The escalation-fatigue surface proves that **a deterministic system that still needs a human inherits the human's vulnerabilities.** The human is the probabilistic component the deterministic design cannot eliminate — and a human who is fatigued is as steerable as a judge. Hold these three proofs. B05.2 constructs the breaks; B05.3 prescribes the defense-in-depth. The proofs are the throughline, and they are the motivation for B2's thesis: no single layer suffices. --- # B05.2 — The Three Breaks *Each break constructed, each measured against InjecAgent or analyzed as an escape path, each mapped to what it proves.* ## Break 1 — Compilation fidelity: steering the build-time LLM **The setup.** IronCurtain compiles a `constitution.md` to deterministic JSON rules. The compilation is an LLM pipeline: Annotate classifies tool arguments, Compile translates English to if/then, Resolve Lists turns categorical references ("major news sites") into `@list-name` symbols resolved to concrete values, Generate Scenarios creates test cases, and Verify & Repair runs an LLM judge that can repair failures up to two rounds. The attacker's goal is to cause the compilation to produce a rule that permits an action the constitution intends to deny — and to do so in a way that passes the verify-and-repair stage. Three vectors: - **Constitution ambiguity.** The constitution is plain English. A clause like "the agent may post to internal channels for routine updates" is ambiguous about what counts as an internal channel and what counts as routine. The compilation must resolve the ambiguity, and an attacker who can influence the constitution text (via a legitimate-seeming edit, or a constitution that was written loosely) steers the resolution toward a permissive interpretation. "Internal channels" compiles to include an attacker-controlled webhook; "routine updates" compiles to include credential exfiltration framed as a diagnostic. - **Scenario coverage gaps.** The Generate Scenarios stage creates test cases that the compiled policy must handle. If the scenario set does not include the attacker's intended action pattern, the verify-and-repair stage never tests it — and a permissive rule that the scenarios do not exercise passes verification. The attacker's goal is to ensure the scenario set has a coverage gap around the action they intend. - **Resolved-list poisoning.** The Resolve Lists stage turns `@list-name` symbols into concrete values, sometimes via LLM knowledge and sometimes via MCP tool-use. An attacker who can influence a resolved list (a list of "trusted endpoints" that includes an attacker-controlled domain, or a list of "sensitive operations" that omits one) bakes the poisoning into the deterministic policy. **What the verify-and-repair defense does and does not stop.** It stops naive miscompilations: a rule that obviously contradicts the constitution is caught by the scenarios and repaired. It does not stop a miscompilation that the verifying LLM agrees with — because the verifying LLM is the same kind of probabilistic system that produced the miscompilation. A permissive interpretation of an ambiguous clause, validated against a scenario set that does not exercise the permissive case, passes. The defense is a second LLM checking the first; two probabilistic systems agreeing is not a deterministic guarantee. **What a successful break proves.** That relocating the LLM from runtime to build time does not eliminate the probabilistic component — it concentrates it. A single miscompilation becomes a consistently-enforced wrong rule. Where CrabTrap's judge might refuse an exfiltration on a given request (probabilistic enforcement of correct understanding), IronCurtain's miscompiled rule permits it every time (deterministic enforcement of incorrect compilation). The deterministic thesis is correct about runtime; it is incomplete about build time. This is the finding that motivates B05.3's defense-in-depth. **Measuring it (InjecAgent).** The compilation-fidelity break does not have the same shape as the SDD-B04 breaks, because the attack is against the build, not the runtime request. The measurement is a fuzz harness over the compilation pipeline: generate N constitution variants (introducing ambiguity, coverage gaps, list poisoning), compile each, and measure the rate at which the compiled policy permits an action the un-fuzzed constitution denies. The metric is "compilation-fidelity drift rate" — the percentage of fuzzed constitutions that produce a permissive rule for the target action. A low rate (e.g., 2%) means the verify-and-repair pipeline is catching most miscompilations; a high rate means it is not. This is the build-time analogue of the InjecAgent runtime delta: a measured effectiveness claim, not an assertion. ## Break 2 — The V8 isolate boundary **The setup.** IronCurtain's Code Mode runs agent-generated TypeScript in a V8 isolate via `isolated-vm`. Every tool call exits the sandbox as a structured MCP request through the policy engine. The isolate provides per-call fuel (computation limits) and memory limits — a hardened JavaScript-level execution boundary. The credential quarantine depends on the isolate holding. The agent holds fake keys (`FAKE_ANTHROPIC_KEY_abc123`). The real keys live in the TLS-terminating MITM proxy that does the hot-swap. The agent cannot reach the proxy directly — it can only make LLM API calls that transit the proxy, where the swap happens. The quarantine holds because the agent's execution environment (the isolate) cannot reach the proxy's execution environment (the host process). **The attack surface.** V8 and `isolated-vm` have a history of sandbox-escape CVEs. V8 is a JIT compiler with a garbage collector and a complex type system; escapes have come from type confusion, bounds-check errors, JIT optimization bugs, and garbage-collection edge cases. `isolated-vm` adds a transferable-handle mechanism for sharing references between isolates, which has had its own CVEs. An isolate escape is a memory-corruption-class vulnerability: the attacker (the compromised agent, running code in the isolate) exploits a V8 or `isolated-vm` bug to execute code in the host process, outside the isolate's boundary. **What an escape would mean.** The credential quarantine is defeated. Once the agent's code runs in the host process, it can reach the proxy's memory (where the real keys live), the proxy's network stack (to make calls with real credentials directly), or the policy engine's configuration (to modify the compiled rules or the audit log). The isolation that made the quarantine hold is gone. This is the path from "compromised agent" to "real credentials" — and it is a path that depends entirely on the V8 isolate not having an exploitable bug at the time of the attack. **The honest framing.** This break is an escape-path analysis, not a constructed exploit. The course does not teach V8 exploitation — that is a deep specialization, and a working isolate escape is a zero-day with a short shelf life. What the analysis establishes is the structural dependence: **the credential quarantine holds only as long as the isolate does.** IronCurtain's documentation acknowledges this implicitly — the isolate is a "hardened execution boundary," not a "guaranteed execution boundary." The defense-in-depth prescription (B05.3) treats the isolate as one layer among several, not as the load-bearing boundary. **Measuring it.** There is no InjecAgent delta for an escape-path analysis, because the escape depends on a specific V8 version and a specific bug. The measurement is a dependency-CVE audit: is the deployed V8 / `isolated-vm` version current? Are there known escape CVEs in the deployed version? This is the same class of finding as a traditional sandbox-escape audit, and it is an audit finding, not a benchmark number — like SDD-B04's Break 3 configuration-drift audit. ## Break 3 — Escalation fatigue **The setup.** IronCurtain's enforcement has three outcomes per tool call: Allow (rule match), Deny (default, no allow-rule match), and Escalate (pause the agent, prompt the human). Escalation uses a terminal multiplexer (`ironcurtain mux`) with single-key a/d/w (allow/deny/whitelist) or Signal on mobile. The optional LLM auto-approver handles unambiguous cases (e.g., "user said push my changes" auto-approves the subsequent `git_push`). Edge cases escalate. The human is the probabilistic component the deterministic design cannot eliminate. The auto-approver handles the unambiguous cases, but anything genuinely ambiguous — a tool call the policy does not clearly permit or deny — escalates. And a human making allow/deny decisions under load is a known-fragile system. **The attack.** The attacker generates edge cases. Each edge case is a tool call that is ambiguous under the compiled policy — not clearly permitted, not clearly denied, forcing an escalation. The attacker's goal is volume: flood the escalation channel until the human's allow/deny decisions degrade into rubber-stamping. Three pressure patterns: - **Volume fatigue.** Generate many escalations in a short window. The human, faced with a backlog, defaults to allow (the path that keeps the agent moving) rather than carefully evaluating each. Each allow is a policy decision the deterministic engine was supposed to make — delegated back to a fatigued human. - **Contextual fatigue.** Generate escalations that are similar but not identical to previously-approved calls. The human, having approved the similar call, approves the new one by analogy — without noticing the difference that makes it an attack. This is the semantic analogue of the allowlist-widening pattern from SDD-B04 Break 3. - **Timing fatigue.** Generate escalations during periods when the human is known to be busy (a launch, an incident, off-hours). The approval rate goes up; the scrutiny goes down. This is why Signal-on-mobile is a double-edged design: it makes escalation responsive, but it also makes it easy to approve from a phone without full context. **What a successful break proves.** That a deterministic system that still needs a human inherits the human's vulnerabilities. The human is the probabilistic component, and a fatigued human is as steerable as a judge. This is the deterministic analogue of the latency/cost pressure on CrabTrap: a defense that is expensive to honor (in human attention) is a defense the human will defeat. IronCurtain's documentation acknowledges this — escalation fatigue is listed as a known limitation, with rate-limiting and smart batching as partial controls. **Measuring it.** Build an escalation-fatigue simulator: generate a stream of escalating tool calls (varying ambiguity, volume, and timing), simulate a human approver with a fatigue model (approval rate increases with volume and decreases with scrutiny time), and measure the rate at which attacker-intended actions are approved under fatigue versus a rested baseline. The delta (e.g., "attacker action approval rate rises from 4% rested to 31% fatigued") is the honest measurement of the surface. This is an engagement simulator, not a production measurement — and it is the finding that most directly motivates the rate-limiting and batching controls. --- # B05.3 — Defense-in-Depth: Why No Single Layer Suffices *The residual risks after each break, and the layered prescription that is B2's thesis made concrete.* ## The residuals, restated IronCurtain is the strongest single defense in the roster. SDD-B04 showed it closes the two surfaces CrabTrap leaves open (the injectable judge, the latency/cost pressure that dissolves when enforcement is cheap). This deep-dive shows it has its own honest residuals: - **Compilation fidelity.** A probabilistic LLM compiles the deterministic rules. Miscompilation is consistently enforced. The verify-and-repair pipeline mitigates but does not eliminate — two LLMs agreeing is not a deterministic guarantee. - **The V8 isolate boundary.** The credential quarantine depends on the isolate holding. V8 and `isolated-vm` have escape CVE history. The quarantine is the strongest primitive in the course, but it is one memory-corruption bug from defeat. - **Escalation fatigue.** The human is the probabilistic component. A flooded human rubber-stamps. Rate-limiting and batching are partial controls, not eliminations. No single residual is a defeat — IronCurtain is still stronger than CrabTrap alone, and stronger than no defense. But the residuals are real, and they are the motivation for the thesis that runs through B2 and this course: **no single layer suffices.** ## The layered prescription The engagement deliverable is not "IronCurtain is broken, abandon it." It is a layered prescription, and the layering is the defense-in-depth that SDD-B03's delta measurement shows reaching single-digit injection rates: 1. **Deterministic compilation, with a human review gate.** Keep IronCurtain's deterministic runtime enforcement — it genuinely has no semantic attack surface. Add a human review of the compiled policy (the `compiled-policy.json`) before it is deployed, with a diff against the last-reviewed version. The verify-and-repair pipeline catches most miscompilations; the human review catches the residual that the verifying LLM agreed with. This closes most of the compilation-fidelity surface without adding a runtime LLM. 2. **Sandbox defense-in-depth.** Do not treat the V8 isolate as the load-bearing boundary. Layer it: the isolate (inner), a seccomp filter or capability-based sandbox around the host process (middle), and network egress controls that deny the proxy's host process any outbound path except the controlled channels (outer). An isolate escape now has to defeat three layers, not one. The credential quarantine is preserved at the outer layer even if the isolate falls. 3. **Escalation rate-limiting and smart batching.** Cap the escalation rate (e.g., max N escalations per hour; above that, deny-by-default). Batch similar escalations so the human evaluates one representative call, not twenty near-duplicates. Require a second human for high-impact allow decisions (the two-person rule from 2A's change-management module). This turns the fatigue surface into a bounded residual rather than an unbounded one. 4. **A probabilistic second layer, positioned after the deterministic one.** This is the surprise: the deterministic-first prescription from SDD-B04 adds an LLM-as-judge *back*, but only for the cases the deterministic layer escalates. The judge's injectability (SDD-B04 Break 1) is now a residual on the escalated subset, not the primary surface — and the human still reviews the judge's decisions for high-impact calls. The layered defense uses the judge's semantic flexibility where the deterministic rules are ambiguous, without making the judge the load-bearing boundary. This is the defense-in-depth that closes more surface than IronCurtain alone. Each layer addresses a residual the others leave: human review addresses compilation fidelity; sandbox defense-in-depth addresses the isolate boundary; rate-limiting addresses escalation fatigue; the probabilistic second layer handles the ambiguous cases the deterministic layer escalates. No single layer is load-bearing; each is a backstop. ## Why this is B2's thesis B2's central claim is that defense-in-depth is not a best practice — it is a structural necessity, because every layer has a residual. SDD-B03 measured it (the delta across layered defenses reaches single-digit injection rates where single defenses sit near the baseline). SDD-B04 demonstrated it (CrabTrap alone has residuals; the deterministic-first prescription points at IronCurtain). This deep-dive completes the argument: even IronCurtain, the strongest single defense, has residuals. The compilation-fidelity gap, the isolate boundary, and the escalation-fatigue surface are not implementation bugs — they are structural properties of any single-layer defense. The only complete answer is layers, and the only honest engagement deliverable is the layered prescription. --- ## Anti-Patterns ### Treating IronCurtain as a complete defense "The deterministic runtime has no attack surface, so IronCurtain is unbreakable." Cure: the runtime has no surface, but the compilation pipeline, the isolate boundary, and the escalation mechanism do. Each is a structural residual. Measure all three; prescribe layers for each. ### Trusting verify-and-repair as deterministic verification "The verify-and-repair pipeline catches miscompilations, so the compiled policy is correct." Cure: verify-and-repair is a second LLM checking the first. Two probabilistic systems agreeing is not a deterministic guarantee. Add a human review of the compiled policy before deployment; diff against the last-reviewed version. ### Treating the V8 isolate as the load-bearing boundary "The isolate is hardened, so the credential quarantine always holds." Cure: V8 and `isolated-vm` have escape CVE history. The quarantine holds only as long as the isolate does. Layer the sandbox (isolate, seccomp/capability sandbox, egress controls) so an isolate escape has to defeat three layers. ### Measuring escalation without a fatigue model "The human approves each escalation carefully." Cure: build an escalation-fatigue simulator with a fatigue model (approval rate rises with volume and falls with scrutiny time). The delta between rested and fatigued approval rates is the measurement of the surface. Rate-limiting and batching are partial controls, not eliminations. ### Prescribing "replace IronCurtain with something else" Treating the residuals as a reason to abandon the deterministic approach. Cure: the deterministic runtime is the strongest single layer. The prescription is to layer around it (human review, sandbox defense-in-depth, escalation rate-limiting, probabilistic second layer), not to remove it. ### Reporting a compilation-fidelity break without a drift-rate measurement "I tricked the compiler" without the fuzz-harness drift rate. Cure: every compilation-fidelity break is measured as a drift rate over N fuzzed constitutions. The rate (not the single success) is the effectiveness claim. --- ## Key Terms | Term | Definition | | --- | --- | | **Compilation fidelity** | IronCurtain's primary residual: a probabilistic LLM compiles the deterministic rules; miscompilation is consistently enforced. The target of Break 1 | | **Verify-and-repair** | IronCurtain's build-time defense: an LLM judge repairs compilation failures up to two rounds. Mitigates but does not eliminate — two LLMs agreeing is not deterministic | | **V8 isolate (`isolated-vm`)** | IronCurtain's Code Mode sandbox; a JS-level execution boundary with per-call fuel and memory limits. Has escape CVE history | | **Credential quarantine** | IronCurtain's fake-key swap; holds only as long as the isolate does. An escape is the path to real credentials | | **Escalation fatigue** | Flooding the human-in-the-loop until rubber-stamping; the deterministic analogue of CrabTrap's latency/cost pressure | | **Compilation-fidelity drift rate** | The measured effectiveness claim for Break 1: the percentage of fuzzed constitutions that produce a permissive rule for the target action | | **Sandbox defense-in-depth** | Layering the isolate (inner), seccomp/capability sandbox (middle), and egress controls (outer) so an isolate escape defeats three layers, not one | | **Layered prescription** | Deterministic compilation + human review, sandbox defense-in-depth, escalation rate-limiting, probabilistic second layer — B2's thesis made concrete | --- ## Lab Exercise See `07-lab-spec.md`. The lab has you build a compilation-fidelity fuzz harness (generate N fuzzed constitutions, compile each through a simulated pipeline, measure the drift rate), construct an escalation-fatigue simulator (vary volume, ambiguity, timing; measure approval-rate delta rested vs fatigued), audit the V8-isolate dependency for known escape CVEs, and assemble the four-layer prescription. No GPU; Python 3.10+ with type hints; the compilation pipeline and the human approver are simulated so the lab runs deterministically offline. --- ## References 1. **IronCurtain source** — github.com/provos/ironcurtain (TypeScript, Apache-2.0). The deterministic governance runtime this deep-dive attacks. 2. **Course 1 DD-20 (IronCurtain)** — the defensive reading; the deterministic thesis and the two mechanisms (credential quarantine, compiled policy). Lists compilation fidelity and escalation fatigue as known limitations. 3. **Course 1 DD-19 (CrabTrap)** — the probabilistic counterpoint; SDD-B04 attacks it and prescribes the deterministic-first layering this deep-dive extends. 4. **Course 2B SDD-B04 (CrabTrap Offensive Analysis)** — the sibling deep-dive; the layered prescription there points at IronCurtain as the fix. This deep-dive is where that fix is itself attacked. 5. **Course 2B SDD-B03 (InjecAgent)** — the measurement instrument; the compilation-fidelity drift rate and the escalation-fatigue delta are the build-time and human-layer analogues of the runtime InjecAgent delta. 6. **Course 2B B2** — the injection-defense layer; the defense-in-depth thesis this deep-dive is the motivation for. 7. **`isolated-vm`** — the V8 isolate library IronCurtain uses; the sandbox boundary whose CVE history Break 2 analyzes. 8. **V8 security advisories** — the historical isolate-escape CVEs (type confusion, bounds errors, JIT bugs) that define the Break 2 attack surface. 9. **OWASP Agentic AI Top 10 (2026)** — the escalation-fatigue pattern maps to ASI03 (excessive agency) and the human-in-the-loop bypass. 10. **Niels Provos blog / WIRED coverage** — the design rationale for the deterministic thesis, read here as the attack-surface map.