Sandbox security

The Sandbox is the isolation boundary. Independently created Environments have separate working files. Sessions explicitly attached to the same Environment share files, processes and VM-visible credentials. Separate conversation histories and output directories do not isolate code running in that Sandbox.

Explicit sharing is a shared Environment API. Your application controls which Sessions may share an Environment and which tools and external identities are available.

Rebyte obtains the organization from the authenticated API key and checks both organization and Environment ID on reference attachment, reads, file operations and deletion. Missing and foreign IDs return 404. An ID alone is not permission. Your application enforces end-user access within that organization and coordinates shared files, processes, MCP names and cleanup. The API does not add per-Session isolation inside a shared Sandbox. See the developer responsibility boundary.

Network access

Set the network policy when creating the Environment:

const environment = {
  type: 'openai_hosted',
  network: {
    access: 'restricted',
    allowed_domains: ['api.example.com'],
  },
};

access accepts enabled, disabled, or restricted. Domain allowlists apply to restricted access. Choose the policy required for your packages, setup commands, and tools.

Credential placement

Environment variables and inline stdio credentials are available to code running in that Sandbox. Treat them as credentials available inside the Environment, including to every Session sharing that Sandbox.

Use static_bearer or mcp_oauth Vault credentials for service-origin HTTP MCP authentication when the credential should remain outside the Sandbox. Session HTTP authentication and stored environment setup secrets are encrypted and omitted from public Session resources and events by the API.

Rebyte extension: sandbox_environment Vault credentials can be explicitly delegated through environment.vault_credentials. The selected Sandbox processes receive the actual values; the Agent and its code can read them. Rebyte does not inject them into model instructions or public resources, but code can disclose them in tool output or files. This is not a proxy that hides secrets from Sandbox code.

Bindings require an attached Vault in the Session's organization and an active, unexpired credential. Rebyte resolves the current value for new process launches. Rotation, deletion, and expiry do not change the environment of existing processes. Deleting a credential does not revoke its provider token. See Sandbox delegation for the contract, validation errors, and lifecycle limits. This extension is available from October 12, 2026.

In the shared preview, setup configuration and its authorized Vault selection belong to the Environment. A referencing Session cannot override that selection with its own vault_ids. Service-origin MCP credentials remain Session-owned.

Connection origin

Service-origin MCP requests run through Rebyte's service and use public HTTPS endpoints with validated DNS addresses and no redirects. Environment-origin MCP requests run in the Session VM and follow its network policy.

The Sandbox network policy does not govern service-origin requests or your application's function handlers. Review each execution location when deciding what access to grant.

Application permissions

Organization authentication scopes access to Sessions, environments, and Artifacts. Your application must enforce its own end-user authorization before using its organization key on a user's behalf. See Manage sessions.