In-placedeceptionconversion

This is the mechanism the whole system exists for. When risk crosses T, three ordered steps run against the container that is already there, all from outside it: detach every network it is on, attach deception_net and imds_net, then verify. Nothing runs inside the container to make isolation hold, because the attacker has root there and could undo it.

The session is on none of those networks. SSH reaches the shell through the Docker API and HTTP enters through a helper sharing the container's network namespace, which is why the session on the attacker's screen does not drop, stutter, or reconnect. PIDs, the process tree, cwd, shell history, environment variables, files they dropped, uptime and /proc all continue because it is the same container. The command that crosses T is held for the moment the swap takes, then runs against the new world.

The order fails closed. After the first step the session can reach nothing, so if attaching or verification fails it stays cut off, shown as QUARANTINED, while the conversion is retried. It is never handed back to the real backend, and a session that can't even be detached is terminated.

The alternative, relocating the session to a separate honeypot, was considered and rejected. Relocation leaves fingerprints: a fresh process tree, a reset uptime, a different disk identity, missing history, missing dropped files. Any one of them tells the attacker the environment changed. Continuity is the deception.