Security and isolation

GlobalStacks treats runtime isolation as something that must be reported, placed, and audited explicitly.

Docker and Firecracker are different isolation classes:

• Docker reports process_container.
• Firecracker reports hardware_virtualized_microvm.
• Docker traits cannot satisfy micro virtual machine (microVM) placement requirements.

Runtime boundary

Managed micro virtual machine (microVM) capacity requires agents to report Kernel-based Virtual Machine (KVM), Firecracker, jailer, control group version 2 (cgroup v2), tap networking, firewall support, and storage support before activation.

The control plane stores runtime and isolation reports on agents, allocations, and sandbox runtime records. Placement failures include runtime mismatch reasons so operators can see why a workload could not run on a host.

Network boundary

Network access is policy checked:

• sandboxes do not receive infra mesh credentials
• provider-backed hosts are not customer-accessible hosts
• public ingress is explicit
• firewall rules are attached to runtime endpoints
• private network access is scoped to approved networks and aliases

Authority boundary

Providers do not receive tenant authority. Provider extensions can report capacity and perform brokered provider operations, but GlobalStacks owns placement, runtime approval, pricing, billing, audit, and customer-visible state.

Managed agents cannot self-select tenant, cluster, provider, pool, or allocation. They enroll with scoped tokens and receive authority from the control plane.

Secret boundary

Provider application programming interface (API) credentials, agent credentials, tenant secrets, and extension runtime credentials are separate. Extension user interface (UI) and runtime code must use declared permissions and brokered operations; there is no host shell fallback.