Sandboxing is the practice of placing code in an isolated environment and deciding what that code is allowed to touch safely.
The word names the habit and the controls, while the sandbox names the confined place where the code actually runs.
How it works
Teams apply the practice to browser tabs, mail attachments, untrusted builds, and unknown programs from vendors.
Someone must choose the policy: which files are visible, whether the network is open, and how long the run may last.
Doing it well includes resetting state, logging what the code tried to do, and refusing extra permission by default.
Simply owning an isolated machine does not mean the practice is in place if people bypass it for speed.
Concrete examples
- A mail gateway opens attachments in isolation before a person can click them on a workstation.
- A developer policy requires every contributed pull of code to build inside a fresh restricted container.
- A help desk detains unknown utilities in isolation instead of running them on the support laptop.
Protective measures
- Write a default deny policy for files, network, and privileges, and grant exceptions only for a named task.
- Log behavior inside the isolation and alert when code asks for rights it was not given.
- Stop staff from copying untrusted files out to a normal desktop just because the isolated run feels slow.
- Review the policy when a new application arrives so convenience does not silently punch a hole.