Credential Security

API key management

FC Agent Sandbox API keys are used to create, connect to, and manage sandboxes. Recommendations:

• Split API keys by application, environment, team, or tenant. Do not let multiple people or systems share the same long-lived key.

• Do not use a personal local development key in production.

• Do not expose full API keys in source repositories, images, templates, logs, screenshots, tickets, or documentation examples.

• Use environment variables or .env files for local development, and make sure .env is not committed to source control.

• Use pipeline secret management for CI/CD instead of writing secrets into build artifacts.

• If a key is leaked, disable or delete the old key immediately, generate a new one, and roll it out gradually.

Recommended configuration:

export E2B_API_KEY="<your-api-key>"
export E2B_API_URL="https://api.<region>.e2b.fc.aliyuncs.com"
export E2B_DOMAIN="<region>.e2b.fc.aliyuncs.com"

New E2B CLI versions authenticate with E2B_API_KEY. E2B_ACCESS_TOKEN is a deprecated legacy E2B authentication variable and should not be used in new integration flows.

Do not inject high-privilege credentials into sandboxes

Environment variables are suitable for task parameters, non-sensitive configuration, and short-lived credentials, but they are not suitable for directly exposing long-lived high-privilege secrets. Command-level environment variables in the E2B SDK have a narrower scope, but they are still not private at the operating system level.

High-risk practices:

• Injecting a primary-account AccessKey, a production database password, or a long-lived Git token into a sandbox.

• Injecting shared cloud resource credentials used by multiple tenants into every task.

• Storing production secrets in environment variables that AI-generated code can read.

• Printing environment variables in exception stacks, printenv, debug logs, or task output.

Safer practices:

• Inject only the minimum configuration required by the current task.

• Use task-level, short-lived, least-privilege credentials. When STS temporary credentials are available, do not use long-lived AccessKeys.

• Split credential permissions across environments, tenants, and tasks.

• Redact output, logs, and downloaded files.

• Terminate the sandbox proactively after the task ends to avoid leaving credentials behind in background processes or temporary files.

Environment variable and metadata boundaries

Environment variables enter the sandbox runtime and can be read by processes inside the sandbox. Metadata is used for control-plane tagging, lookup, and correlation, and it should not contain sensitive payloads.

Recommendations:

• Put non-sensitive runtime parameters or short-lived credentials in envs.

• Put searchable identifiers such as task IDs, tenant IDs, and application versions in metadata, not user privacy data, business data, or secrets.

• Do not write sensitive information into template names, file names, labels, log fields, error messages, or observability metrics.

• If the same field needs both control-plane searchability and process-level readability, evaluate the visibility of metadata and envs separately.

Secret rotation

Production environments should establish rotation for API keys and external resource credentials:

• Generate a new key or new temporary credentials.

• Roll out the new configuration gradually.

• Verify the full flow for sandbox creation, command execution, required resource access, and resource release.

• Delete the old key, and confirm it no longer appears in logs, images, templates, or pipeline variables.

Secret rotation is not complete just because a new key exists. If the old key is still visible in templates, images, CI/CD caches, or logs, the risk remains.