Understand first
New to this knowledge point
Complete the prerequisite concepts, read the principles and counterexamples, and then explain why in your own words.
Start with core principles →Knowledge catalogChoose core direction and segmented content
Understand → Implement → Debug → Design
Isolate resources and capabilities when executing code
Examine files, networks, processes, credentials, and resource limits.
Knowledge content check2026-10-03 · Check the source of the original question2026-10-02
It is recommended to understand first:
Tool calls: structure, authorization, and business contracts →Approval targets and execution-time authorization →Which step do you want to learn from this knowledge point?
Select the starting point based on the current basis, or you can go deeper one by one. When you encounter an unfamiliar concept, go back to the core principles first; use the knowledge exercises to check your understanding when you are finished.
Realize again
Prepare to write the principles into code
Understand implementation steps and boundaries, complete small tasks, and check results against acceptance requirements.
Reading implementation and trade-offs →Will troubleshoot
Need to handle failures and changes in conditions
Follow the continuous questioning to locate the failure premise, and then compare the migration cases to explain how the plan should be adjusted.
Continue to delve deeper into the problem →Able to choose
Need to design or review plans
Combine engineering deductions and senior self-evaluation standards to explain the applicable conditions, costs and alternatives of the plan.
Analyze engineering scenarios →Knowledge unit directory
LEARN · PRACTICE · REFLECT
Knowledge learning and personal records
First read along the principles, Q&A and migration cases. When you need to check your understanding, switch to reinforcement exercises or start personal recording.
Answers and personal notes
Can be practiced directly. After logging in, answers, favorites, and notes will be saved to your account.
Log in and saveEach modified commit will be kept as an independent history. Your level of mastery is up to you to evaluate yourself against the standards.
Core concept · Isolate resources and capabilities when executing code
Understand the core principles first
Preparatory concepts:Process permissions, File path parsing, Container resource limits
Code execution risk depends on the capabilities the process actually possesses. Restrictions must be enforced by the execution environment over files, networks, credentials, process trees, and resources, and conventions in the prompt are not a substitute for isolation.
A working directory is not isolation
Programs can read absolute paths, follow symlinks, launch background processes, and access networks. Define visible files, execution identity, allowed system calls, and outbound destinations. Avoid host secrets and credentials exceeding task needs.
Container configuration determines protection
Containers share the host kernel and may lack resource limits. Mounting a Docker daemon socket can grant host-container control. Assess stronger isolation for risky untrusted code under a threat model. A zero exit code does not establish security. Bound CPU, memory, duration, subprocesses, and disk growth.
Treat exported artifacts as untrusted
Stop the entire task execution domain before extracting allowed artifacts. Reject symlinks, special files, oversized files, and disallowed content. Path checking before opening has a race; Linux openat2 can support constrained resolution where available. This is platform-specific guidance, with no new sandbox attack experiments.
Check understanding with a question
Let the Agent execute Python or Shell, what needs to be isolated in the production sandbox?
Constrain files, outbound network, privileges, system calls, CPU, memory, disk, and time, with separate task identity and workspace. Inject short-lived credentials only where needed, avoiding sensitive host mounts. Inspect exports and retain redacted audits. Docker is an isolation mechanism, not proof of safety.
Realization and trade-offs
Identify threats and assets
The code may read keys, access internal services, fill up disk, or start background processes. Assign independent workspaces and lowest-privilege identities by task, and prohibit hosts from dangerously mounting and managing sockets. Read-only dependencies are separated from writable output directories. Path normalization and real path checking prevent symbolic links from crossing boundaries; the path and size must also be checked when decompressing compressed packages.
Network and Credentials
By default, limited outbound targets are opened according to task requirements, and redirection, domain name resolution changes, and intranet target access are checked. Use restricted tool gateways when you need to call business services, and do not expose high-privilege keys to arbitrary execution code. Short-term credentials limit the audience, scope and validity period, and desensitize logs and error output. Hiding environment variable names is not a security isolation in itself.
Resources and life cycle
Set CPU, memory, number of processes, disk, output size, and absolute deadline. To terminate the task process tree and reclaim resources on timeout, you cannot just stop reading stdout. Depend on the source and version of the installation to prevent unchecked installation scripts from gaining host permissions. Writable directories are not shared between concurrent tasks, preventing one task from reading the artifacts of another task.
Export and Verify
Only use files in the allowed directory as candidate artifacts, verify the format, size and content policy, and then hand them over to the user. Test boundaries such as reading parent directories, accessing internal addresses, outputting large logs, and timeout residual processes, and verify them with harmless test objects. Choose stronger isolation mechanisms for high-risk execution; evaluate based on threat models rather than calling all environments safe containers in interviews.
Engineering deduction
- scene
- Interview Hypothesis: The Data Analysis Agent can run Python files uploaded by the user.
- design decisions
- Each task has an independent restricted execution environment and reads necessary data through the gateway.
- Verify target
- Unable to read other task files, timeout without leaving process or infinite log.
- applicable boundary
- Isolation strength depends on the operating platform and threat model and must be verified in practice.
Continuous questions and answers
Continue reading along with the premises and constraints of the problem. Understand the reference answers first, then try to put away the answers and explain the cause and effect and trade-offs in your own words.
Level 1What are the risks of mounting a Docker socket?
Container boundaries will be expanded by control sockets, requiring specific capabilities.
Reference answer
The ability to control daemons may start high-privilege containers, mount host files, and change the host environment. The risk is far greater than ordinary code file access. Do not provide sockets to untrusted tasks; use isolated build services and least privilege interfaces when build capabilities are required. Rootless can reduce some risks and cannot automatically prove that shared sockets are safe.
Level 1What should I do if the main process exits after the code opens a background subprocess?
Execution lifetime limits need to cover the entire process tree.
Reference answer
The end of the main process does not mean the end of the task domain. The supervisor should manage the entire tree by container or controlled process group, enforce total time and resource limits, and export the artifact after cleanup is completed. Verify the child process leaving the session, network connection and write residue; only sending a termination signal to the parent PID may miss background work.
Level 1Can restricting only file paths prevent symlinks from going out of bounds?
File access restrictions must account for path resolution and race conditions.
Reference answer
Not enough. The string path is within the allowed directory and may still point to the outside after link resolution; changing the link after checking may also cause a race condition. Use isolated mounts, descriptor relative opening, and appropriate link prohibition/out-of-bounds resolution mechanisms to verify the true file type when exporting; don't rely solely on the startsWith directory prefix.
Follow this answer further
Level 2Check the realpath first, and then open it according to the original path. Does the race condition still exist?
The parent question indicates that the link is out of bounds, and the child question checks whether common patches close the check usage window.
Reference answer
exists. Attackers can replace directories or links between inspection and opening. Have path constraints take effect within the same controlled open, use safe descriptor relative resolution, or export from a controlled snapshot after the task is stopped and mounted read-only; still need to verify platform behavior and file types.
Follow this answer further
Level 3If the file is opened safely, is the content still likely to change during copying?
The parent asks to ensure path resolution and continues to ask about the variability of the file content itself.
Reference answer
Possibly. If the writing process is still running, open ordinary files will also be overwritten. Stop the entire task domain or use a consistent snapshot, then check the size, type, and summary and export the same content; continuing to read from the variable path after verification will reintroduce the window.
Draw inferences from one example: If the conditions change, how to deduce it?
First find out the conditions for change, and then determine which premises in the original plan still hold true. The following cases are teaching deductions to facilitate the transfer of principles to new problems.
Compilation tasks require downloading dependencies
Changing conditions:The original network sandbox requires a small amount of controlled outbound.
Extended question:Do you want to directly open all networks?
Derivation and reference solutions
Should not. Limit target, protocol and package versions by relying on mirrors or proxies, prohibit access to internal metadata and sensitive networks, and inject build credentials to a short-term minimum range. The download cache and artifacts are still not trustworthy, and the source and verification need to be recorded; the reachable goal is capacity expansion and needs to be re-evaluated.
The principles that remain unchanged:New capabilities must have clear scope and independent mandatory boundaries.
Legitimate code exhausts resources
Changing conditions:There is no intention to steal data, but it continues to fork or write large files.
Extended question:Are files isolated from the network enough?
Derivation and reference solutions
Not enough. Set independent limits on the number of processes, CPU, memory, disk and total execution time to ensure that recycling covers all child processes; when resources are exhausted, a controlled failure should be returned and limited logs should be retained. Security includes protecting the availability of other tasks, not just checking whether secrets are leaked.
The principles that remain unchanged:The execution environment limits the actual capabilities and resources, covering all task processes.
Easy to make mistakes
- Containers are secure by default
- Inject all environment variables into the executor
- Timeout only disconnects output without killing the process tree
References
It is designed based on public technical information; the reference materials support the technical mechanism, and the scenarios and scoring standards are designed by this website and do not represent the original interview questions of a certain company. New Q&A and migration cases are added for principle explanation, and source verification and case operation verification are recorded separately.
Check how far you understand
After reading, you can explain the principles, boundaries, and trade-offs against these standards. It is up to you to evaluate your mastery; if further verification is needed, complete the small tasks below.
- Basic standards met
- File, network, process and resource limits can be listed based on task needs.
- Intermediate and advanced signals
- Able to design task identities, short-term credentials, process recovery and artifact exports.
- Senior Signal
- Consider symbolic links, redirects, installation scripts, and cross-task isolation verification.
Hands-on verificationComplete on demand · Suggestions15 minutes
Write a least-privilege manifest and kill process for tasks that only require reading CSV and generating charts.
Expand acceptance requirements and checkpoints
- No extraneous networks and secrets
- Bounded resource and process tree cleanup
- Product export checked
Key inspections
- Isolation covers multiple resource areas
- Credentials and networks have minimum scope
- Timeout cleanup process tree and artifact exit