Under the hood

Architecture

How readable security rules become one portable decision that Warden can enforce without weakening it.

One decision, five clear responsibilities

Sandbox Policy sits between the place where permissions are chosen and the system that runs the workload. Each layer has one job, so security intent stays understandable and execution technology remains replaceable.

ARCHITECTUREPolicy-to-enforcement pipeline

- Policy frontendDatalog · JSON compiler · C builder
- libmaelys-mircanonicalize + validate + hash
- Sandbox PolicyMIR → immutable SandboxPlan
- Wardenlifecycle + backend + receipt
- Netdmediated network enforcement

Policy frontend → libmaelys-mir
libmaelys-mir → Sandbox Policy
Sandbox Policy → Warden
Warden → Netd

Layer	Owns	Does not own
Policy frontend	authorization rules, facts, trusted configuration	OS enforcement
`libmaelys-mir`	canonical encoding, decoding, validation, digest	conditional reasoning
Sandbox Policy	backend capability matching and immutable SandboxPlan	process lifecycle
Warden	prepare, spawn, wait, stop, native backend, execution receipt	deciding user rights
Netd	authenticated proxy, DNS/pinning, allowlist, byte relay	filesystem sandbox

The portable handoff

CODE

              decision
 Datalog ─────────────┐
 JSON compiler ───────┤
 C builder ───────────┘
                      │
                      ▼
════════════ canonical MIR v2 ════════════
                      │
                  resolution
                      ▼
                SandboxPlan

Consumers verify that MIR is already canonical. They do not silently normalize hostile input, invent missing grants or evaluate conditional rules.

Refuse what cannot be guaranteed

The caller queries a named backend, then resolves the MIR for exactly those capabilities. The same backend identity must be used at execution time. If the backend cannot guarantee a required semantic, plan creation fails.