The layer that runs your workspace is now fenced in too

A ZeroLog workspace does not talk to the host kernel. Its system calls go to gVisor, a kernel written in userspace, and that process, together with its file helper, is what actually touches the machine. Until now nothing stopped it from reading files it never needed. It is now confined by a security profile attached to the program itself rather than to a container, so it covers every way a workspace can start: ordinary workspaces, agent containers, and the short-lived sandboxes used for website previews and export checks. The runtime keeps everything it needs, meaning image layers, your workspace directory and the network. It loses access to what it never needed: ZeroLog's database, its service keys, the configuration of the outbound tunnel, the container engine's own socket, raw disks, kernel modules. It also cannot attach to any other process on the machine, and it cannot change the rules that confine it. Three things had to be learned the hard way while building this, and all three are now written down rather than rediscovered. The profile has to permit user namespaces and the system bus explicitly, or no workspace starts at all. The file helper mounts your workspace under a path that a blunt rule would have blocked, which would have locked out every workspace at once. And an explicit denial is silent, so a wrong rule breaks without saying so. Nothing here is visible from inside a workspace. Commands, files, ports and network behave exactly as before. What changed is what would happen if the layer underneath ever broke: the next wall is already standing.