Interactive architecture lab
Design the boundary first. Then simulate how an autonomous coding run plans, executes tools, handles failures, and proves its own output inside an isolated workspace.
Network denied, scoped writes, and approval-gated tools contain the blast radius.
Execution model
Stage 1 of 7
Convert a broad request into explicit deliverables, prohibited actions, data boundaries, and acceptance tests before code execution begins.
{
"goal": "local issue triage",
"data": "uploaded JSON only",
"network": "not required",
"acceptance": ["filters", "charts", "export"]
}Least privilege
Threat model
Resilience drill
Evidence trail
Architecture review
Isolation limits impact. Verification establishes confidence. A production design needs both, plus a record that lets a human reconstruct what happened.
It gives the agent an isolated process, a limited filesystem, bounded resources, and a capability policy. It should be disposable: every run begins from known state and leaves evidence instead of residue.
A capability is narrow, explicit, and revocable. Granting “run shell” is broad; granting “execute this test command in this directory for five minutes” is an auditable capability.
Tests only cover their assertions. Verification should also inspect diffs, provenance, policy violations, dependency changes, generated assets, and the behavior users can actually observe.
Network egress, logs, crash reports, package registries, copied output, and long-lived secrets can cross an otherwise private boundary. Treat each as a separate data path.