Why viruses don't matter when the base image can't be changed
Traditional endpoint security is an arms race: new threat, new signature, new update, repeat forever. Immutable desktops sidestep the entire game. The base operating system and application layer cannot be persistently modified. Period. Reboot the desktop and every unauthorized change — malware included — is gone.
Each desktop VM runs from a read-only base layer (the golden image). User data lives in a separate writable layer that persists across sessions. The base layer is cryptographically hashed, and the hash is verified at boot. If a single byte of the base layer has been modified, the desktop refuses to start and alerts the administrator.
During a session, malware can technically execute in memory and write to temporary storage. But it cannot modify system binaries, install persistent services, alter boot sequences, or survive a reboot. The next time the desktop starts, it boots from the verified, unmodified golden image. The infection is gone without anyone doing anything.
This isn’t detection. It’s physics. The base layer is read-only at the storage level. There is no privilege escalation that grants write access to it because the write path doesn’t exist. Root access inside the VM cannot modify the base layer because the base layer isn’t mounted read-write.
The security industry is raising alarms about AI-generated malware — polymorphic code that rewrites itself, social engineering at scale, zero-day discovery automation. These are real concerns for traditional endpoint security, where defense depends on recognizing the attack.
Immutable desktops don’t recognize attacks. They don’t need to. The defense is mathematical: the base image has a known hash, the running system must match that hash, deviations are detected by comparison rather than classification. It doesn’t matter how sophisticated the malware is, how novel the attack vector is, or whether a human or an AI wrote it. If it modifies the base layer, the hash changes. If the hash changes, the system flags it. If it doesn’t modify the base layer, it doesn’t survive reboot.
AI makes attacks smarter. Immutability makes that irrelevant. You’re not trying to outsmart the attacker — you’re refusing to play the game they’re playing.
The recommended deployment uses non-persistent desktops for most users. Log in, do your work, log out. Next login gets a fresh desktop from the current golden image. User files are stored in the persistent data layer or synced via Cloud Sync. Application state that needs to survive sessions (browser profiles, IDE settings) is redirected to the persistent layer explicitly.
For users who need persistent desktops, Mythos scans run on schedule to compare the running state against the golden baseline and flag any drift. This gives you the flexibility of persistence with the auditability of immutability.