Isolation
Every sandbox runs in a dedicated namespace with no access to developer machines, company secrets, or other workloads. For code that needs kernel-level separation from the host, sandboxes can additionally run under a stronger runtime class such as gVisor or Kata on dedicated node pools. See the isolation model for how this is configured.Egress control
Network egress is governed by aNetworkPolicy. With the managed policy enabled, the sandbox namespace is default-deny: a sandbox only reaches the destinations you explicitly allow, and administrators can block additional network ranges (for example a cloud metadata endpoint or internal CIDRs) when enabling the component. Generated code cannot quietly exfiltrate your source or data to the open internet.
Access control
Sandboxes inherit the platform’s existing roles and permissions. Who can create, access, and delete sandboxes is governed by the same RBAC and workspace scoping that applies to the rest of your cluster — there is no separate, parallel permission system to keep in sync.Attribution & audit
Every create, exec, and egress attempt is attributed to the authenticated developer or agent and recorded in the audit log. When someone needs to reconstruct what an agent did — or prove it to an auditor — the record is there.Sovereignty
Sandboxes run on your Kubernetes: any cloud, on-prem, or air-gapped. No code and no data leave your infrastructure, which keeps Agent Sandbox compatible with GDPR and data-residency requirements that rule out third-party, US-hosted sandbox services.mogenius is ISO 27001 certified (TÜV Saarland), a CNCF Silver Member, and a Certified Kubernetes product. Because Agent Sandbox reuses the platform’s isolation, RBAC, and audit, the controls above are the same ones already in scope for your mogenius deployment.