a sandbox
Children's sandboxes have a wall around them for a reason: whatever mess happens stays inside, and the rest of the yard is safe. A software sandbox is the same idea for running code you do not fully trust. You let the program run, but inside a tightly walled-off environment where it can only touch a small, controlled set of resources — so that even if it turns out to be buggy or outright malicious, the damage it can do is confined to the box.
A sandbox works by tightly limiting what a process can do and see. It is built by stacking the protection mechanisms of the OS: run the code with least privilege so it has almost no rights to begin with; restrict which system calls it may make (a malicious program that cannot call the network or open arbitrary files is largely defanged); give it only a restricted view of the filesystem and no access to other processes; and rely on hardware protection so it cannot reach outside its own memory. A web browser is the everyday example: each website's untrusted JavaScript, and often each tab's rendering engine, runs in a sandboxed process that cannot read your files or other tabs — so a malicious page that exploits a rendering bug is still trapped inside that one sandbox and cannot reach your documents. Mobile apps run the same way, each in its own sandbox so one app cannot rummage through another's data.
Sandboxing is one of the most effective modern defenses precisely because it assumes the code inside might be hostile and contains it anyway — it is the practical embodiment of least privilege and defense in depth. The honest caveat is that a sandbox is only as strong as its walls. A sandbox escape — a bug in the sandbox enforcement itself, or in the kernel underneath it — lets the contained code break out, and such escapes, though hard, are highly prized by attackers. Note also that a sandbox is not the same as a virtual machine: a sandbox typically still relies on the host kernel to enforce the boundary (so a kernel flaw can break it), whereas a virtual machine runs a whole separate guest OS for stronger isolation at higher cost.
You open a malicious web page. Its code exploits a bug in the browser's rendering engine and runs arbitrary instructions — but that engine sits in a sandboxed process with no file access and a restricted set of allowed system calls. The attacker has code execution, yet cannot read your documents or touch other tabs. To truly escape they would need a second bug in the sandbox or kernel.
Code execution inside a sandbox is contained — escaping needs a further bug.
A sandbox is only as strong as its walls — a sandbox-escape bug, or a kernel flaw beneath it, lets contained code break out. And a sandbox is not a VM: it usually relies on the shared host kernel, which is lighter but weaker isolation.