[P1] Sandbox execution layer — planner/executor isolation without third-party deps

[JerrettDavis]

Objective

Build a lightweight process isolation layer inspired by Sandlock's XOA (Execute-Only Agent) architecture. Enforces disjoint capabilities: the LLM planner cannot see real data, the executor cannot reach the network. No third-party dependencies — custom implementation for supply chain safety.

Architecture (inspired by multikernel.io/sandlock)

• Planner process: has API access (LLM calls), no filesystem/data access
• Executor process: has filesystem/tool access, no network access
• Connected by unidirectional kernel pipe (stdout → stdin)
• Sequential: planner completes before executor touches data

Platform support

• Linux: Landlock LSM for filesystem restriction, seccomp-bpf for syscall filtering
• Windows: Job Objects for resource limits, Restricted Tokens for capability stripping, CreateProcessAsUser for isolation

Deliverables

• JD.AI.Sandbox project with ISandboxPolicy and SandboxedProcess abstractions
• Linux implementation using Landlock + seccomp (P/Invoke, no native deps)
• Windows implementation using Job Objects + Restricted Tokens
• Pipeline operator: Sandbox(plannerPolicy).Pipe(Sandbox(executorPolicy))
• Integration with WorkflowFramework: sandboxed step execution
• Benchmark: <20ms overhead per sandboxed step

Blocking Order

Depends on #402 (bridge layer) for WorkflowFramework integration.
Independent for standalone sandbox primitives.

Security note

No third-party dependencies. All OS primitives accessed via P/Invoke or .NET APIs. This is a supply chain safety requirement.

[JerrettDavis]

Closed by PR #434 — JD.AI.Sandbox with process isolation (Windows Job Objects, Linux Landlock+seccomp), pipeline operator, and tests.