Shared Responsibility

Security boundaries must be defined during the integration design phase. They cannot be deferred until after launch and then patched with logs and support tickets.

Platform responsibilities

The platform is responsible for the security of the FC Agent Sandbox service itself, including:

• Providing sandbox lifecycle management, including create, connect, pause, resume, terminate, and timeout-based reclamation.

• Providing runtime isolation and resource boundaries to reduce the risk of interference across tasks, users, and sandboxes.

• Providing control-plane authentication so that only authenticated and authorized callers can manage FC Agent Sandbox resources.

• Providing baseline security mechanisms for API keys, endpoints, templates, files, commands, and access addresses.

• Protecting server-side infrastructure, the control plane, data-plane links, and platform operations according to Alibaba Cloud product security requirements.

The platform's isolation capabilities reduce risk, but they do not replace business-side access control, input validation, secret management, log redaction, data classification, or compliance auditing.

User responsibilities

Users are responsible for their own accounts, configurations, code, data, and business access paths, including:

• Managing API keys, RAM identities, STS temporary credentials, and third-party tokens to avoid leakage and over-privileged access.

• Deciding what code is allowed to run inside sandboxes, and validating user input, AI-generated code, uploaded files, and third-party dependencies.

• Controlling which files, environment variables, networks, cloud resources, and public ports a sandbox can access.

• Setting reasonable sandbox timeouts, command timeouts, output size limits, and cleanup logic for each task.

• Filtering sensitive information from stdout, stderr, exception stacks, downloaded files, and returned results.

• Isolating storage directories, external data sources, and access credentials by tenant, task, environment, and data classification.

• Adding authentication, expiration, access-scope control, and auditing for sandbox services exposed to the public internet.

If a workload exposes production secrets, database permissions, internal management addresses, or high-privilege cloud account credentials to untrusted code, data leakage, privilege abuse, or resource misuse can still occur even if that code runs inside FC Agent Sandbox.

Shared risks

When using FC Agent Sandbox, you should identify at least the following risks:

• Credential leakage: environment variables, logs, exception stacks, command output, or downloaded files contain API keys, AccessKeys, database passwords, or third-party tokens.

• Unauthorized data access: one task accesses data directories, NAS or OSS paths, or database resources that belong to another tenant, session, or project.

• Command injection: user input is concatenated directly into shell commands, causing unexpected command execution.

• Network abuse: untrusted code accesses internal management addresses, databases, metadata services, third-party sites, or performs scanning, crawling, or data exfiltration.

• Resource exhaustion: infinite loops, large file writes, background processes, recursive downloads, dependency installation, or high-concurrency tasks create cost or availability risks.

• Supply chain risk: system packages, language dependencies, browser extensions, CLI tools, or image sources installed in templates contain vulnerabilities or backdoors.

• Public exposure: an unauthenticated debugging service, management interface, or temporary web service is exposed through a sandbox port.

• Log and metadata leakage: user privacy data, business data, secrets, or download links are written into logs, metadata, labels, file names, or support tickets.

Minimum security baseline

Before using FC Agent Sandbox in production, you should meet at least the following baseline:

• Do not use long-term primary-account credentials to call FC Agent Sandbox. Prefer least-privilege RAM identities and short-lived credentials.

• Do not inject long-lived high-privilege secrets into sandboxes. When external resource access is required, use task-level, short-lived, least-privilege credentials.

• Use a dedicated sandbox or a dedicated working directory for each task. Do not reuse runtimes that contain sensitive state.

• Validate all user input, file paths, URLs, command arguments, and downloaded files.

• Set timeouts for commands and sandboxes, and release resources in finally blocks or equivalent cleanup logic.

• Apply authentication, expiration, and access-scope control to public ports, upload and download addresses, and preview links.

• Redact logs, outputs, and error messages. Do not return the full execution context directly to end users.

• Pin template and dependency versions, verify sources, and patch vulnerabilities regularly.

Related documents:

• Security Isolation

• Credential Security

• Untrusted Code