Sandbox Security

A sandbox is an isolated environment where software or code can run safely without affecting the host system — a controlled playground for testing and analyzing behavior without risk to production or to other tenants. For a platform that invites third-party development, sandbox security is what makes attorney-client privilege defensible while still enabling an open ecosystem. The developer-facing experience is covered in Developer Sandbox; this page covers the security model beneath it.

Isolation Model

flowchart TB
  INFRA["Shared infrastructure (Kubernetes)"]
  subgraph T1["Tenant A namespace"]
    C1["Containers + policies"]
  end
  subgraph T2["Tenant B namespace"]
    C2["Containers + policies"]
  end
  subgraph T3["Developer sandbox namespace"]
    C3["Isolated test env"]
  end
  INFRA --> T1
  INFRA --> T2
  INFRA --> T3

Sandbox Principles

• Isolation — untrusted code is separated from the host system and from other tenants.
• Rigorous analysis — the environment continuously checks for malicious activity such as unauthorized access, file changes, or suspicious network connections.
• Strict containment — any suspicious or malicious behavior is confined to the sandbox, so the host system and other tenants remain unaffected.
• Realistic yet safe testing — developers get a production-like environment without endangering live systems.
• Prevention of system failures — software faults are contained, minimizing broader outages.

Implementation

PHX Terminal’s sandbox combines three complementary isolation technologies:

Technology	Role	Notes
Virtual machines (VMs)	Full hardware-level isolation	Each VM has its own isolated network and no direct connection to production resources; programs cannot share memory with the host.
Containerization (Docker, Kubernetes)	Lightweight process isolation	Containers share the OS kernel but enforce strong separation, with constrained CPU, memory, and network access.
Multi-tenancy (Kubernetes namespaces)	Shared-infrastructure tenant separation	Tenants are split into namespaces with granular policies that restrict API access, resource usage, and container privileges.

This layered model lets many developer sandboxes run efficiently on shared infrastructure while preserving strong data separation.

Data Isolation Techniques

Within the sandbox, sensitive legal data is protected through:

• Rigorous access control — developers apply for sandbox access with project rationale; credentials are vetted and verified, with mandatory data-security training where appropriate.
• Anonymization and de-identification — test data is anonymized, de-identified, or aggregated wherever possible to protect individual identities.
• Encryption — all data is encrypted in transit and at rest inside the sandbox (see Encryption & Data Isolation).
• Decentralized / federated analysis — for highly sensitive data, analysis is sent to the data’s location and only aggregated or encrypted partial results are shared, keeping data local to its source.
• Strict data retention — a zero data-retention policy ensures no user data is stored long-term after processing.

Stringent controls — SOC 2 alignment, RBAC, multi-factor authentication (MFA), and regular security audits — are fundamental to the sandbox.

Mitigating Supply-Chain Risk

By running external code in a tightly controlled sandbox, PHX Terminal contains supply-chain risk: even if a third-party application contains bugs or malicious code, its impact is confined to its isolated environment and cannot compromise the core platform or sensitive client data. This containment is essential for maintaining trust in a highly regulated industry, and it transforms data protection from a checkbox into a verifiable, core feature of the platform.