AppContainers & capabilities

Everything in this level so far — tokens, DACLs, integrity levels, privileges — predates modern app sandboxing by years and remains the default model for ordinary desktop processes. AppContainer is a stricter isolation model, built on top of those same primitives rather than replacing them, designed originally for Store/UWP-style apps and now used more broadly, including by parts of modern browsers for sandboxing untrusted content.

A locked box by default

An AppContainer process runs with an AppContainer SID — a per-app, per-package identity distinct from the signed-in user's own SID — combined with the Low integrity level already introduced in UAC, integrity levels, and the secure desktop. The practical effect: by default, an AppContainer process can access almost nothing outside its own isolated per-app storage area, regardless of what the signed-in user could otherwise do. It isn't running "as the user, but restricted" in the way a filtered UAC token is — it's running as an essentially separate, much narrower identity that happens to be associated with that user's session.

Capabilities: specific, named holes in the box

Since a fully sealed box is often too restrictive to be useful, Windows lets an app declare capabilities — specific grants like internet access, access to the microphone or webcam, access to the Documents library, or access to removable storage. Each declared capability adds a corresponding capability SID to the app's token, and resource access checks then combine three things at once: the ordinary DACL, the integrity level, and whether the specific capability required for that resource is present.

This is meaningfully different from classic UAC/DACL-based restriction, which is coarse (essentially: standard user vs. administrator) — capabilities let an app be granted exactly the specific categories of access it declared needing, and nothing else, decided largely at install/package time rather than through ad-hoc runtime prompts for each resource.

Brokers: the escape hatch for everything not covered by a capability

Plenty of legitimate operations don't fit cleanly into a predefined capability — picking a single file via an open dialog, for instance, shouldn't require blanket filesystem access just because the user wants to pick one file. Windows handles this with broker processes: a trusted, more privileged process performs the sensitive operation (like showing a file picker and reading whatever file the user explicitly selected) on the sandboxed app's behalf, then hands back only the specific result — the app itself never gains the broader capability that operation would otherwise have required.

A worked example: why a sandboxed app's "everything looks fine" folder is still off-limits

Imagine an AppContainer app trying to read an ordinary folder in a user's profile that has entirely ordinary, permissive DACL entries for that user. The DACL check alone (from Security descriptors & ACLs) would allow it. But the AppContainer identity is a different SID than the signed-in user's own SID, and unless the folder's DACL (or a relevant capability) specifically grants access to that app's AppContainer SID, the request is denied — the ordinary user-level permissiveness of the folder never even comes into play, because the app isn't running as that user in the sense the DACL was written to anticipate.

A common mistake

Confusing AppContainer with UAC is common, but they solve different problems: UAC is about distinguishing "this administrator is acting as a standard user right now" from "this administrator has explicitly elevated." AppContainer is about isolating an application — regardless of who's running it, admin or standard user alike — down to a narrow, explicitly-declared set of capabilities. A Store app running under a standard user account still gets the full AppContainer sandbox; a Store app running under an administrator account doesn't get any less sandboxing because the account happens to be privileged.

Where this connects

• UAC, integrity levels, and the secure desktop supplies the Low-integrity foundation AppContainer isolation builds on.
• Access checks & the Security Reference Monitor is where capability checks get folded into the same overall access-check flow as DACL and integrity checks.