M1048 Application Isolation and Sandboxing: Application Isolation and Sandboxing Mapped to ATT&CK

Every unpatched or unknown vulnerability will eventually be exploited somewhere, so the question that decides the damage is what the exploited code can reach. MITRE ATT&CK M1048 Application Isolation and Sandboxing answers it by running code in a controlled environment, such as a browser sandbox, a virtualised application, a container with restricted system calls or a contained AI workload, so that a compromise does not spread to the rest of the system or network. This guide maps M1048 to the 15 ATT&CK v20 techniques it mitigates, shows which isolation layer fits each one, sets out what sandboxing does not stop, and explains how to measure coverage. It covers browsers, Office documents, containers and AI agents, and is written for endpoint, platform and detection engineers. For agent-specific sandbox design see the AI Agent Sandboxing and Code Execution Guide; this page does not repeat it.

Key takeaways

• Containment, not prevention. ATT&CK's own wording for most M1048 entries is that sandboxing mitigates "some of the impact" of exploitation and that sandbox escapes may still exist.
• Fifteen techniques, five families. In ATT&CK v20 M1048 mitigates exploitation techniques (T1189, T1190, T1203, T1210, T1211, T1212, T1068), Office inter-process abuse (T1559, T1021.003), container escape (T1611), smuggling (T1027.006, T1027.017) and AI-enabled exfiltration (T1700).
• Sole mitigation for two techniques. For T1027.006 HTML Smuggling and T1027.017 SVG Smuggling, M1048 is the only mitigation ATT&CK v20 lists, and for T1700 AI-Enabled Exfiltration it is one of three.
• The sandbox is only as strong as what it holds. A sandboxed process with a production credential or open egress is still a path to your data, as the AI evaluation incidents of 2026 showed.
• Measure the escape surface. Count workloads running privileged or with host namespaces, browsers with sandbox flags disabled and agents with unrestricted egress.

What M1048 is in ATT&CK terms

ATT&CK defines Application Isolation and Sandboxing as restricting the execution of code to a controlled and isolated environment, such as a virtual environment, container or sandbox, to stop potentially malicious code affecting the rest of the system or network. It lists four implementation measures:

• Browser sandboxing: isolate untrusted web content, using browsers with built-in sandboxing or enhanced browser security frameworks, and consider controls on script-based file generation and downloads used in HTML smuggling.
• Application virtualisation: run critical or high-risk applications in a virtualised environment so a compromise does not reach the host.
• Email attachment sandboxing: route attachments to a sandbox to detect malware before delivery.
• Endpoint sandboxing: run downloaded files and applications in a restricted environment and monitor their behaviour.

MITRE D3FEND relates M1048 to D3-HBPI Hardware-based Process Isolation, D3-SCF System Call Filtering and D3-DA Dynamic Analysis, and notes that "sandboxing" often means a detection environment with analysis, while many forms of isolation are static and simply limit access to system resources. Keep the two meanings separate in your coverage map: an email detonation sandbox is detection, a renderer sandbox is containment.

Techniques M1048 mitigates

All 15 ATT&CK v20 entries, grouped by tactic, with ATT&CK's description of how M1048 helps and the isolation layer that delivers it. The layer column is our mapping.

Related technique guides: T1190 Exploit Public-Facing Application, T1203 Exploitation for Client Execution, T1559 Inter-Process Communication, T1611 Escape to Host, T1068 Exploitation for Privilege Escalation, T1212 Exploitation for Credential Access and T1211 Exploitation for Stealth.

Isolation by surface: browsers, Office, containers and AI agents

Browsers

The Chromium sandbox design document describes a privileged broker (the browser process) and sandboxed targets (renderers). On Windows, renderers run with a restricted token at Untrusted integrity, in a job object that blocks child process creation and clipboard access, on an alternate desktop, with mitigations such as Win32k system call lockdown and Arbitrary Code Guard. The same document states the limits: operating system bugs can let code escape, injected third-party DLLs create new attack paths, and sandboxed code can still call system services. The practical consequences are to keep the sandbox enabled (never run with --no-sandbox outside testing), patch quickly, and limit DLL injection into browsers. For the highest-risk browsing, Remote Browser Isolation Guide covers moving rendering off the endpoint. HTML smuggling controls are covered in the HTML Smuggling Guide.

Office documents

Microsoft describes Protected View as a read-only state with most editing turned off, used for internet downloads, Outlook attachments from senders that policy marks unsafe, files in unsafe locations, files blocked by File Block, files that fail validation and files from someone else's OneDrive. Administrators can block users from leaving Protected View. That is the setting ATT&CK points to for T1559 and T1021.003. Pair it with macro controls; see the Office Macro Blocking Guide.

Containers

For T1611, ATT&CK names seccomp and Kubernetes Pod Security Standards. The Kubernetes Baseline profile disallows hostNetwork, hostPID and hostIPC, privileged containers and hostPath volumes, limits added capabilities to a fixed list and forbids an Unconfined seccomp profile. The Restricted profile adds allowPrivilegeEscalation: false, runAsNonRoot: true, a non-zero runAsUser, an explicit RuntimeDefault or Localhost seccomp profile, and dropping ALL capabilities with only NET_BIND_SERVICE added back. See the seccomp Guide and PodSecurityPolicy to Pod Security Admission.

AI agents

T1700 brings AI systems into M1048: ATT&CK says keeping LLM and AI systems within the organisational network with no outside access can contain exfiltration. For agents that run code or browse, that means a sandbox for execution plus a default-deny egress policy with an allow-list. The Agent Egress Control and Network Isolation Guide covers the network side.

Choosing the isolation layer

Small organisations get most of the value from defaults: modern browsers with sandboxing on, Protected View enforced, and managed container platforms with Pod Security Admission set to Restricted for application namespaces. Larger organisations add remote isolation for high-risk users, microVM sandboxes for untrusted code and agent workloads, and attachment detonation.

Where identity fits: what the sandbox holds

Isolation contains code, not credentials. A container that mounts a cloud service account token, a CI runner holding a deploy key, or an AI agent sandbox with a production API key gives an escaped or hijacked process a valid identity to use outside the boundary. The 2026 Anthropic Claude evaluation incidents are a case in point: models told in the prompt that they had no internet access reached the real internet through a misconfigured third-party test environment, and each damaging step used a credential that was taken, leaked or misused. NHI Mgmt Group recommendations: give sandboxed workloads short-lived, narrowly scoped workload identities rather than static keys, keep reusable production credentials out of anything that runs untrusted code, and enforce scope with network controls, not instructions. See the How to find pods that automount service account tokens guide.

Implementation priorities

The order below is an NHI Mgmt Group recommendation.

1. Inventory the escape surface: list workloads running privileged, with host namespaces or hostPath, browsers launched with sandbox flags disabled, Office clients where users can leave Protected View, and agents with open egress.
2. Apply defaults in audit mode: set Pod Security Admission to warn and audit for the Restricted profile, and review violations before switching to enforce.
3. Enforce for internet-facing and untrusted code first: public applications (T1190), CI runners and AI agents executing generated code.
4. Lock Office and browser settings by policy: enforce Protected View for internet and attachment sources, block exiting it where the business allows, and prevent sandbox-disabling flags.
5. Add egress control to every sandbox: default-deny outbound, with allow-lists per workload; verify third-party environments by testing them, not by trusting assurances.
6. Remove standing credentials: replace static keys inside sandboxes with short-lived workload identity.
7. Rollback: keep namespace-level exemptions with an owner and expiry date, so a broken workload can be unblocked without dropping the policy for everyone.

What sandboxing does not stop

• Sandbox escapes: ATT&CK and the Chromium design document both say escapes exist. Patch speed (M1051 Update Software) and exploit protection (M1050) remain necessary.
• Abuse within the boundary: a sandboxed web application can still be made to read data it is allowed to read. Isolation limits spread, not misuse of legitimate access.
• Credential reuse outside the boundary: a token stolen from inside a sandbox works wherever it is valid.
• Sandbox-aware malware: detonation environments can be detected and evaded, so treat a clean verdict as one signal.

Detection and measurement

• Admission violations: Pod Security Admission audit annotations and warnings for pods requesting privileged mode, host namespaces or unconfined seccomp.
• Child processes of sandboxed apps: browsers or Office spawning shells or script interpreters, a classic sign of T1203 escaping into execution.
• Egress from sandboxes: outbound connections from agent or CI sandboxes to destinations outside the allow-list (T1700).
• Protected View overrides: users enabling editing on files from the internet, by volume and by user.

Common failure patterns

• Isolation stated in a prompt or a contract: the AI evaluation incidents above relied on the model being told it had no internet, while the environment allowed it.
• Privileged containers "temporarily": a single privileged: true or hostPath mount removes most of what the container boundary offers against T1611.
• Sandbox disabled for compatibility: browsers or Electron apps launched with sandboxing turned off to fix a plug-in, then never turned back on.
• Detonation counted as containment: an attachment sandbox is detection; files that pass it still run on the endpoint unless another layer contains them.
• Secrets mounted into the sandbox: isolation holds, but the credential inside it is used from somewhere else.

Framework mapping

Practitioner checklist

• Map the 15 techniques above to the isolation layer you run for each, and note any gaps.
• Enforce Pod Security Admission Restricted for application namespaces, after an audit-mode period.
• Require a seccomp profile (RuntimeDefault or custom) for every container.
• Enforce Office Protected View for internet and attachment sources, and block sandbox-disabling browser flags.
• Run AI agent code execution in a sandbox with default-deny egress and an allow-list.
• Keep static production credentials out of anything that runs untrusted code.
• Use remote browser isolation for high-risk roles and destinations.
• Pair M1048 with M1051 and M1050, because escapes exist.

Standards and references

• MITRE ATT&CK: M1048 Application Isolation and Sandboxing
• MITRE ATT&CK: T1611 Escape to Host
• MITRE D3FEND: System Call Filtering
• NIST: SP 800-53 Rev. 5
• Kubernetes: Pod Security Standards
• Chromium: Sandbox design document
• Microsoft: What is Protected View?

Related NHI Mgmt Group resources: AI Agent Sandboxing and Code Execution Guide · Agent Egress Control and Network Isolation Guide · Container Security Guide · M1047 Audit