Sandboxing and Permissions

Goal

Distinguish permission policy from process isolation and design layered controls for tool execution, file access, network access, and resource limits.

Permission and containment are different

A permission check asks whether an action is allowed. A sandbox asks what the executing process can actually reach. These controls overlap, but they solve different problems. A policy might allow a code tool for one task while the sandbox still blocks access to the host file system, unrelated network endpoints, or excessive CPU and memory.

Imagine the controller allows run_analysis on a user-provided CSV file. That permission does not mean the analysis process should read SSH keys from the host or send data to any internet address. A sandbox can expose only the mounted input directory, provide no credentials, restrict networking, and limit resources.

Layering matters because software can fail. A tool adapter might contain a bug, generated code might do something unexpected, or a dependency might behave differently than expected. If permissions are the only control, a bug inside an allowed tool may still reach too much. Isolation reduces the damage available to that process.

policy:  allow run_analysis on /workspace/task/report.txt
sandbox: process can reach /workspace/task only
request: /home/user/.ssh/id_rsa → blocked by containment

Layer trust and isolation

Zero trust is a security approach that avoids granting broad access merely because something is already inside a network or system. For an agent harness, the practical lesson is to verify each request against identity, task context, and policy, then give the execution environment only the resources required for that operation.

Containers are one common isolation boundary, but a container is not automatically a perfect sandbox. Configuration matters: mounted directories, capabilities, network mode, user privileges, secrets, and resource limits all change what the process can do. The useful learning target is least privilege, not the assumption that one technology name guarantees safety.

Resource limits are part of containment. A code tool that cannot read secrets may still consume all memory or run forever. Timeouts, CPU quotas, memory limits, process limits, and output limits help preserve system availability. These controls belong outside model instructions.

Keep scope narrow and auditable

Permissions should be narrow in both action and scope. 'Can write files' is much broader than 'can write one report file under this task directory.' 'Can access network' is broader than 'can call the inventory API endpoint needed for this task.' Scope reduces the consequences of mistakes.

Audit evidence should record the requested action, principal (the trusted user or service identity on whose behalf the action would occur), policy result, sandbox profile, and final outcome. This helps distinguish a denied request from an allowed request that failed inside the isolated environment.

Do not treat isolation as a reason to relax approval rules. A sandbox may limit technical reach, but a refund or deletion can still be harmful even when performed from a tightly restricted process. Authorization, approval, and sandboxing should reinforce one another.

Predict

A code tool is allowed for one task. What additional sandbox rule is still useful?

Mount only the task input/output directory and deny unrelated host accessExpose the full host file system because the permission check already approved the toolGive the process all available network credentials so it can recover from unexpected errors

Run the local Lab

Run:

python labs/notebooks/level-12/l12-05-sandbox-policy.py

The Lab evaluates requested file, network, and resource capabilities against a small sandbox profile.

1. Run it unchanged and confirm path, network, and memory checks are all True.
2. In request, find PurePosixPath("/workspace/task/report.txt"). Before editing, predict which one of the three checks should change if only the path leaves the permitted task directory.
3. Change only that path to PurePosixPath("/home/user/.ssh/id_rsa"), then rerun.
4. Confirm the path check becomes False while network and memory remain True, and the final assertion blocks the request. Restore the starter afterward.

Loading lab…

Write the core logic yourself

Open:

labs/notebooks/level-12/l12-05-sandbox-policy-exercise.py

Implement path, network-host, and memory checks. The good request must pass while each single-boundary violation remains blocked.

Run:

python3 labs/notebooks/level-12/l12-05-sandbox-policy-exercise.py

The starter intentionally fails at its TODO boundary. A completed implementation ends with a PASS: marker. Compare with the solved deterministic Lab only after attempting the implementation yourself.

Quick Check

1. What is the difference between permission and sandboxing?

They are two names for the same controller boolean and should be stored as one fieldPermission decides what is allowed; sandboxing limits what can be reachedSandboxing applies to files; permission applies to network calls

2. Which design best follows least privilege?

Allow broad network access in case the tool needs it laterMount the full host file system read-write but ask the model not to modify itExpose only resources required for the approved task

3. Why add resource limits to an isolated tool?

Because an isolated process can still consume excessive time, CPU, memory, or outputBecause resource limits make policy approval unnecessaryBecause limits catch logic errors in the generated code

0 of 3 questions answered.

Explain it back

For a code-execution tool, describe one permission rule, one file-system restriction, one network restriction, and one resource limit. Explain why each belongs to a different control layer.

Key Takeaways

• Authorization and isolation solve different problems.
• Least privilege narrows both action and scope.
• Container configuration determines the real boundary.
• Resource limits protect system availability.
• Sandboxing does not replace approval for high-impact actions.

Next Lesson

Next, L12.6 — Memory Retrieval and Compression examines how long-running agents keep useful context without silently losing important evidence.

References

• Open Container Initiative, Runtime Specification.
• NIST, SP 800-207 — Zero Trust Architecture.