OS-level agent workspaces: the OS as the permission gate

Two platform vendors are now building the permission boundary for agents into the operating system itself, not the app layer above it.

For most of the last two years, an agent's permissions have lived wherever the agent framework put them: a config file, a list of allowed tools, a runtime check before a risky call. That works until the agent needs to touch the filesystem, click through a real app, or run unattended while you're doing something else. Microsoft and Apple are both, separately, moving that boundary down a level — into the account system and the app-integration API, respectively. Neither is finished. Both are worth understanding now, because if either one sticks, it resets where every agent product on that platform has to draw its permission lines.

Windows: an agent gets its own account

Microsoft's mechanism is called Agent Workspace, and the idea is architecturally blunt: an agent acting on your Windows PC doesn't run as you. It runs under its own Windows account — separate sign-in, separate desktop session, an identity backed by Microsoft Entra rather than your personal login — inside a contained workspace that Microsoft documents as isolated from your own activity and files unless you explicitly grant access (Experimental Agentic Features). That's the same trick operating systems have used for decades to separate users on a shared machine, pointed at a new problem: separating a person from the software acting on their behalf.

The first real feature built on it is Copilot Actions, now rolling out through the Windows Insider program's Copilot Labs channel, gated behind an opt-in toggle that ships off by default. It requires a recent Copilot app build (Insider coverage puts the minimum at 1.25112.74) and hands the agent a visible, separate desktop where it works through multi-step local tasks — sorting photos, pulling tables out of PDFs, batch-converting files — while you keep using your own session in parallel. You can watch it, pause it, stop it, or take over mid-task (Copilot Actions on Windows Insiders; Windows Insider Program releases Copilot Actions).

Microsoft isn't pretending this is solved. Its own platform security guidance, published the same day as its Build 2026 developer keynote, walks through the isolation model and lays out mandatory logging, least-privilege scoping, and explicit user approval for sensitive actions as requirements for anyone building on top of it — not suggestions (Windows platform security for AI agents; Windows security book: agentic security). Coverage of the feature has been blunter still about what's at stake in getting that wrong (Windows 11 agentic features are a security nightmare, Microsoft confirms). The enterprise half of the story — governing which agents exist and what they're allowed to touch — runs through Microsoft Entra Agent ID, which issues each agent its own identity object so IT can manage, audit, and revoke agent access the same way it manages a human account (Microsoft Entra Agent ID: what are agent identities).

Apple: the boundary is what you declare, not where you run

Apple isn't building an isolated session for agents at all. Its bet is that the agent should never get generic access to an app in the first place — it should only be able to call the specific, discrete actions a developer has explicitly published.

The mechanism is App Intents, and WWDC 2026 was the point where it stopped being optional. Apple formally deprecated SiriKit, making App Intents the sole framework through which Siri — and, by extension, any on-device agentic feature — can act inside a third-party app (Apple outlines major AI and developer tool updates). A developer declares entity schemas (what content exists) and intent schemas (what actions can be taken on it); those get indexed into Spotlight's semantic layer and become the only surface an agent can reach. A new View Annotations API extends the same idea to whatever's on screen, and an App Intents Testing framework lets developers validate the integration through the real system pathway instead of UI automation (WWDC26 Apple Intelligence guide). Alongside it, Apple expanded its on-device Foundation Models framework — multimodal input, tool-calling, and "Dynamic Profiles" that swap models and instructions mid-session — as the substrate for building agentic app behavior on top of that declared surface.

The permission logic here is closer to a capability grant than a sandbox: there's no separate account or session, because there's no path to anything the developer hasn't explicitly typed and shipped. Apple's app review becomes the point where an agent's reach gets audited, the same way it already reviews what an app can ask permission for.

Same problem, opposite mechanism

Both approaches share the same instinct that shows up everywhere else in agent UX: don't ask the agent to police itself, and don't ask the human to approve every action one at a time either — build the fence into the substrate the agent runs on, the same idea behind graduated permission modes at the application layer. Microsoft is fencing the process; Apple is fencing the API. Neither has shipped broadly enough yet to say which shape wins, or whether they end up complementary — an isolated workspace on the desktop, calling into apps only through a declared intent surface, would combine both bets rather than pick one.

If you're designing agent permissions today, the practical takeaway is narrower: don't build your own ad hoc sandbox if the OS is about to hand you one for free, and don't assume "off by default" means "not yet relevant" — Copilot Actions and App Intents' Siri requirement are both live enough now that they'll shape what users expect an agent to ask before it acts.

We're tracking both as early-stage entries — worth a look before either becomes the assumed default on its platform.