The innermost ring limits what any code can do, regardless of how it got there or whether it was reviewed. Even if a malicious script executes, it can't escape the sandbox (MIT01), can't phone home (MIT02), can't exhaust resources (MIT03), can't escalate permissions (MIT04), and can't steal credentials (MIT07).
This ring operates at the OS and infrastructure level — not at the code level. It works even when the code is adversarial and the agent has been fully compromised.
The middle ring inserts human or automated judgment between generation and execution. Pre-execution code review (MIT05) catches dangerous patterns before they run. Confirmation gates (MIT06) require explicit approval for irreversible operations.
This ring catches the cases that the hardened environment can't prevent — scenarios where the code is within the sandbox's permitted scope but would cause unintended harm (like deleting the wrong database, which the sandbox has legitimate access to).
The outer ring operates after execution (MIT08) or before deployment (MIT09). Execution logging provides the audit trail for post-incident investigation and feeds behavioral anomaly detection. Generated code scanning catches backdoors and security issues before they reach production repositories.
This ring is the only defense available against Type 5 (backdoor insertion) in a deployment workflow where code is generated and committed but not immediately executed — the other rings don't apply until execution time.
If resources are constrained: implement MIT01 + MIT02 + MIT03 first — they eliminate entire vulnerability classes (Type 1 sandbox escape, Type 3 exfiltration, Type 6 resource exhaustion) through infrastructure controls that require no per-code-execution work. Add MIT06 next — a confirmation gate before destructive operations is the highest-leverage single control for preventing unintentional damage.