What you will build
A proposed controller design for Rithru Labs, starting with a fake backend. “Rithru Sandbox Controller” is the application developed in this learning path; it is not a Docker product or a claim of an existing production deployment.
- Validated task contract
- Dry-run capability plan
- Local or cloud adapter
- Evidence and reconciliation ledger
Conceptual flow. Follow the lesson for prerequisites, exact commands and verification limits.
Read the mechanism
A controller sits between user intent and execution authority. Its job is not to turn every string into a shell command. It validates a finite task specification, selects an allowed backend, records the plan and observes execution against an output contract.
Keep policy separate from agent reasoning. The model may propose an operation, but an ordinary program should validate source revision, allowed files, command arguments, network needs, time/resource budget and publication rights. Approval should apply to a concrete plan rather than an abstract “let the agent work.”
Backend adapters should expose their capabilities explicitly. A local direct mount cannot be implemented by silently uploading a whole home directory to cloud. If the requested backend cannot satisfy a requirement, reject the plan or produce a revised plan for review.
Worked example · task specification
{
"taskId": "parser-edge-cases",
"backend": "fake",
"inputRevision": "replace-with-reviewed-commit",
"workspaceMode": "mountless",
"allowedFiles": ["parse.mjs", "parse.test.mjs"],
"commands": [["node", "--test", "parse.test.mjs"]],
"networkProfile": "no-new-destinations",
"maxRuntimeSeconds": 120,
"maxOutputBytes": 1048576,
"publication": "review-required"
}The JSON is a proposed controller contract, not an sbx configuration. The dry-run output should list every mount, transfer, credential service reference, destination, command and resource that will be created. Raw credentials must never appear.
Implement the first adapter as an in-memory fake using chapter 24’s interface. Test a valid task, a traversal path such as ../private.txt, a command outside the allowlist, a negative timeout and an oversized output. Pass process arguments as arrays; do not concatenate user-controlled values into sh -c.
When you later implement a local adapter, detect the installed CLI version, use fixed supported flags and reject unsupported capabilities. Add a cloud adapter only after its separate identity, budget and cleanup semantics are defined.
Expected observations
A rejected plan should produce no resource creation. A successful fake run should produce a trace of accepted states and an artifact manifest. A cancellation should stop new work and enter cleanup/reconciliation, not erase the record.
Define acceptance independently: the expected files exist, hashes match the exported bytes, tests meet the contract and the resource is in a known terminal state. An agent’s “done” message is not one of those invariants.
Troubleshooting
If the adapter needs increasingly broad permissions, revisit the task contract. If an output path escapes the export root through a symlink, reject it. If cancellation races with creation, preserve the request key and reconcile the potentially created resource.
Do not log unbounded stdout. Use a byte limit and an explicit truncation marker while preserving exit status and artifact references.
Interview practice
Where should policy enforcement live?
In deterministic controller and backend checks that validate each capability request, with the runtime enforcing its own boundaries too. Model instructions alone are not authorization enforcement.
What is a useful dry run?
A concrete resource and capability plan the reviewer can assess: exact inputs, commands, mounts, destinations, credentials by reference, limits, outputs and cleanup actions.
Completion check
Present a rejected unsafe specification, a successful fake trace, and a cancellation that leaves no untracked resource. Label real-backend implementation and deployment as future work until tested.
Sources and version notes
Checked 6 October 2026; current baseline: sbx v0.46.0. Run sandboxes in CI · Errors and retries · SDK cookbook
Make the understanding yours.
Use the completion check above. Mark this chapter when you can explain the mechanism and its limits.
Self-assessed reading progress. This does not certify that a lab ran or a system is secure.