Additional Terms: Sandboxes (GCP — Compute Engine)

Effective Date: April 16, 2026
Cloud Provider: Google Cloud Platform
GCP Services: Compute Engine, Container Runtime (Kata Containers)
Document ID: QUOME-LEGAL-SANDBOX-GCP-001

These Additional Terms govern your use of the Quome Sandboxes service ("Sandboxes") when running on Google Cloud Platform. These terms supplement the Terms of Service.

1. Service Description

Sandboxes provides isolated, ephemeral compute environments (containers) for interactive development, code execution, workflow runs, and AI agent tasks. Sandboxes run on dedicated Compute Engine VMs within your GCP project, using hardware-isolated Kata Container runtimes for security.

2. Infrastructure Ownership

2.1 Customer-Owned Resources

• Compute Engine VMs hosting sandbox containers
• VPC networking, firewall rules, NAT gateways
• Load balancer for sandbox host communication
• Sandbox disk volumes and snapshots
• Container images in your Artifact Registry

2.2 Quome-Managed Configuration

• Sandbox host VM provisioning and lifecycle
• Container creation, execution, and teardown
• Secret injection into sandbox environments
• File upload/download and port exposure
• Sandbox template management
• Resource quota enforcement

3. Customer Responsibilities

3.1 Code Execution

You are solely responsible for all code executed within Sandboxes. This includes:

(a) Application code, scripts, and commands executed interactively or via workflows;

(b) Third-party packages and dependencies installed in sandbox containers;

(c) Network requests made from sandbox containers (outbound network access is enabled by default for workflow sandboxes);

(d) Any data created, processed, or stored within sandbox filesystems.

3.2 Sensitive Data in Sandboxes

(a) Secrets injected into sandboxes are available as environment variables during the sandbox lifetime and are destroyed when the sandbox is terminated;

(b) You must not persist sensitive data to sandbox filesystems unless the sandbox volume is appropriately secured;

(c) Sandbox containers have outbound network access — you are responsible for ensuring that code running in sandboxes does not exfiltrate sensitive data;

(d) Sandbox environments are ephemeral by design — data not explicitly saved to persistent volumes or uploaded as artifacts will be lost on sandbox termination.

3.3 Resource Consumption

Sandbox compute resources (CPU, memory, disk) are consumed from your GCP project's Compute Engine quota and billing. Misconfigured sandboxes (long-running processes, excessive resource allocation) may result in unexpected cloud provider charges.

4. Isolation Model

(a) Sandboxes use Kata Containers with hardware-virtualized isolation (VM-level boundary per container);

(b) Each sandbox runs as a separate microVM on the host;

(c) Cross-sandbox access is prevented at the hypervisor level;

(d) Sandbox host agents authenticate all requests using per-organization tokens;

(e) Quome does not guarantee that the isolation model prevents all possible container escape vectors. While Kata provides hardware-level isolation, you should not rely solely on sandbox isolation for compliance with security regulations.

5. Termination Effects

Upon termination:

(a) Active sandboxes will be terminated;

(b) Sandbox host VMs in your GCP project may continue running — you should verify and shut down any remaining VMs;

(c) Sandbox volumes and snapshots remain in your GCP project;

(d) You are responsible for cleaning up Compute Engine resources after Quome access is revoked.

Cloud Provider Reference

AWS (EC2 + Firecracker) and Azure (VM + Kata) Additional Terms will be published when those providers reach general availability.