Security Isolation
FC Agent Sandbox provides isolated runtime environments for code execution, agent tool invocation, automated testing, and temporary tasks. Developers should treat a sandbox as a short-lived, disposable, controlled execution unit, not as an infinitely trusted business runtime.
The purpose of security isolation is to reduce the impact of untrusted code on business services, other tasks, and platform infrastructure. Isolation is not a single capability. It must be combined with identity and access control, network boundaries, file boundaries, resource limits, and log governance.
Isolation boundaries
FC Agent Sandbox mainly provides the following boundaries:
Runtime boundary: tasks run inside a sandbox instead of directly affecting business service processes.
Lifecycle boundary: a sandbox can be assigned timeouts, paused, resumed, and terminated, and resources should be released when the task completes.
File boundary: the local sandbox filesystem is used for input, temporary files, and output within the current sandbox lifecycle.
Network boundary: endpoints, access addresses, and public port capabilities control how a sandbox is reached and how services are exposed.
Control-plane boundary: API keys, endpoints, account scope, and region scope limit sandbox creation, connection, and management.
These boundaries do not replace business-side security controls. Code running inside a sandbox may still read environment variables, access allowed networks, generate malicious output, consume resources, or exfiltrate any data it can reach.
Boundaries users must control themselves
Users must control at least the following:
Who can create, connect to, and terminate sandboxes.
What code runs inside a sandbox, where it comes from, and whether it has been validated.
What files a sandbox can read, what external storage it can mount, and what cloud resources it can access.
Whether a sandbox can access the public internet, internal networks, databases, enterprise APIs, or third-party services.
Whether exposed sandbox ports require authentication, expiration, and access-scope restrictions.
Whether execution results, logs, exception stacks, and downloaded files are filtered for sensitive information.
If your workload handles multi-tenant data, define explicit data boundaries for each tenant, task, or session. Do not allow multiple untrusted tasks to share the same writable directory, the same long-lived credentials, or the same unauthenticated service port.
Network and port security
A sandbox can run temporary web services, preview services, or tool services. When exposing a port, treat it as a publicly reachable entry point, not as an internal debugging feature.
Recommendations:
Expose only the ports required by the workload. Do not expose debugging ports, management ports, database ports, or shell services.
Apply authentication, expiration, and minimum access scope to preview links, upload and download addresses, and public access addresses.
Do not allow untrusted code to access internal management addresses, databases, metadata services, or highly sensitive business APIs by default.
When access to enterprise internal networks or cloud data sources is required, design it through controlled proxies, VPCs, security groups, access policies, and audit paths.
If the current compatibility layer does not provide fine-grained outbound access control, do not assume that FC Agent Sandbox inherently blocks all outbound risk. Add access controls on the business side, the network side, and the data-source side.
File and storage security
The local sandbox filesystem is suitable for temporary task input, code, dependency caches, and output. After a sandbox is terminated, local files should not be treated as long-term durable data.
Recommendations:
Create a dedicated working directory for each task, such as
/tmp/tasks/<task-id>.Allow each task to read and write only that working directory and any required read-only input directories.
Restrict uploaded files by size, type, suffix, extraction depth, and destination path.
Do not pass unvalidated paths directly to file APIs or shell commands.
Data that must be retained or shared across sandboxes should be written to external storage such as NAS or OSS, with permission boundaries defined by tenant, project, and task.
Shared storage is a high-risk boundary. In multi-tenant scenarios, do not mount all sessions under a single writable root directory, and do not allow tasks to access other tenants' data through relative paths, symbolic links, or path traversal.
Template and dependency security
Templates define the base environment used when a sandbox starts. The more complex the template, the higher the supply chain risk.
Recommendations:
Use trusted base images and pinned dependency versions.
Do not write secrets into images, template files, or build logs.
Update system packages, language runtimes, browsers, CLI tools, and business SDKs regularly.
Use version or alias management for production templates, and switch traffic only after smoke validation passes.
Do not put debugging tools, unrelated services, default weak passwords, or long-running background processes into production templates.
Minimum validation
Before launch, validate at least the following:
Sandboxes are released when tasks complete, fail, or time out.
Untrusted code cannot read production secrets or files that belong to other tenants.
User input cannot trigger command injection, path traversal, or arbitrary file deletion.
No unauthenticated management interface is exposed through a public port.
Logs and returned results do not contain API keys, AccessKeys, database passwords, user privacy data, or download links.
For more on responsibility boundaries, see Shared Responsibility. For untrusted code governance, see Untrusted Code.