The mechanism
A tool that executes code needs an operating-system boundary as well as an application permission check. A filesystem view, process identity, network access, system-call policy and resource limits constrain different behaviors. Linux namespaces isolate selected resource views; syscall filtering addresses another layer. Neither a container label nor a prompt establishes that every unwanted effect is impossible. A runner should grant only the files, endpoints and credentials needed for its declared task, report denied operations, and distinguish termination from successful completion. Secrets should not be copied into prompts or routine trace output. The incident experience has local capability checks but does not execute arbitrary code inside a Linux sandbox. The example below is a resource ledger and boundary analysis, not a claim that such isolation has been deployed.
- The task defines the files, network endpoints and operations needed by the code runner.
- Runtime enforcement applies those permissions where the process attempts the effect, independently of generated instructions.
- Memory and time limits bound consumption; denied or killed execution returns a distinct result.
- The exported evidence identifies the tested input and outputs while excluding credential material.
Science and assumptions
Execution boundaries for code and tools · explicit relationship
Peak live payload is the maximum sum of buffers that coexist at the same time.
Symbols and units
- Bpeak
- Peak modeled live buffer payload
MiB
- 𝓛(t)
- Buffers live at time t
buffer set
- Bᵢ
- Payload size of buffer i
MiB
A hypothetical runner has a 64 MiB memory limit. It retains a 40 MiB input buffer and allocates a 32 MiB output buffer before releasing the input, giving at least 72 MiB live payload. That schedule does not fit, even though neither buffer individually exceeds the limit. Streaming can reduce overlap if the algorithm permits it; relabeling the limit cannot. Separately, denying network egress prevents an unrelated outbound call but does not make a wrong local patch correct. Resource feasibility, effect containment and task evaluation remain different checks.
Assumptions Payload-only ledger; excludes allocator overhead, runtime memory and operating-system state. One MiB is 2^20 bytes. No real sandbox or memory measurement is executed here.
Engineering example
A hypothetical runner has a 64 MiB memory limit. It retains a 40 MiB input buffer and allocates a 32 MiB output buffer before releasing the input, giving at least 72 MiB live payload. That schedule does not fit, even though neither buffer individually exceeds the limit. Streaming can reduce overlap if the algorithm permits it; relabeling the limit cannot. Separately, denying network egress prevents an unrelated outbound call but does not make a wrong local patch correct. Resource feasibility, effect containment and task evaluation remain different checks.
Distinctions and tradeoffs
A sandbox label or a model instruction is not a complete, tested execution boundary.
Tighter restrictions reduce available effects but may reject legitimate operations; a usable runner needs a narrow, testable contract.
Coding and data agents transform model proposals into process execution, where OS-level limits become consequential.
Specifications and interfaces
- Mechanism boundary
- What limits code after it starts running?
Payload-only ledger; excludes allocator overhead, runtime memory and operating-system state. One MiB is 2^20 bytes. No real sandbox or memory measurement is executed here.
- Evidence type
- Authored worked example
Worked explanation with a bounded numeric or state example. This lesson does not claim an executing implementation of an external model or platform.
Interfaces
- Declared input and state Input
- The task defines the files, network endpoints and operations needed by the code runner.
- Checked outcome Output
- Separate process containment, resource budgets and task correctness in a generated-code execution.
Check your understanding
A 40 MiB input and 32 MiB output overlap under a 64 MiB limit. Does the live payload fit?
- Yes, because each allocation is below the limit
- No, because at least 72 MiB is live
- Yes, if the code says it is safe
Answer and reasoning
No, because at least 72 MiB is live
The live-set boundary includes both overlapping allocations, before metadata and other process memory.
Evidence and scope
This is a worked explanation, not an executing external platform, model or robot. The quantities and fixtures are authored. Source scope is recorded in the automation learning review manifest; no source benchmark or private system behavior is claimed. Payload-only ledger; excludes allocator overhead, runtime memory and operating-system state. One MiB is 2^20 bytes. No real sandbox or memory measurement is executed here.
The worked example explains this mechanism. General numerical labs are a reference; they do not execute this lesson’s full mechanism.