GX Sandbox starts from a verified principal declared by your app, launches the agent inside an isolated microVM, and governs its permissions, outbound connections, traffic, and execution logs within one boundary.
Your app authenticates and authorizes the user, then declares that verified identity to GX Sandbox.
A Firecracker-based microVM starts, and the user’s permissions are injected into the boundary as environment and execution context.
Connections like Google Drive, Teams, and Slack — and MCP tools — are loaded scoped to the running user. The same agent stays isolated per user.
Bash, Python, and Node.js execution, outbound traffic, SaaS integrations, and login context are recorded and persisted per sandbox.
Firecracker microVMs are the isolation boundary, orchestrated as a cluster. Run many agents safely, scoped per user and per task.
External connections are bound to the principal and kept inside the boundary, avoiding over-broad permissions and un-auditable access.
Control outbound network requests from a sandbox with per-project policy — default-deny as the baseline — and record them.
Persist execution, history, integrations, and login context so activity can be traced and audited after the fact.
Because the permission boundary and the sandbox boundary are the same, traffic, execution, SaaS integrations, and login context are all managed per sandbox. Outbound connections and execution logs are recorded and persisted, so you can reconstruct what happened later.
Keep a record of which user’s permissions ran which agent, which external services it reached, and what it executed — for audit, incident investigation, and compliance.