Microsoft Copilot is the easiest agent for an enterprise to deploy and the hardest one to bound. It's already on the desktop, already authenticated against Entra, already wired into SharePoint, OneDrive, Teams, Outlook, and the developer's repo. The integration depth is the whole pitch — and the same integration depth is why a Copilot firewall is now table stakes for any organization that has rolled Copilot out broadly.
The Microsoft admin center exposes tenant-scoped controls: who can use Copilot, which connectors are on, which data sources are in scope. What it doesn't expose is what the agent does on a given laptop in a given session — what files it reads, what it writes, what it sends out, what helper agents it spawns, what extensions it loads. That's the gap the Copilot firewall closes.
Why a Copilot firewall has to operate at the OS layer
First-generation Copilot governance lives in the Microsoft control plane. That's necessary, but it's not sufficient — for three reasons:
- The action happens on the endpoint, not in the tenant. Copilot grounds against tenant data, then writes to a local file, runs a local script, opens a network connection, or drives another application. Tenant-scoped policy doesn't see those steps.
- Sub-agents and plugins multiply the surface. Copilot Studio agents, Graph connectors, and custom plugins each broaden the tool inventory. The OS doesn't know which ones a given session pulled in. The Copilot firewall does, because it sees the resulting kernel calls.
- GitHub Copilot agents act on a developer's machine. Editing files, running test suites, opening pull requests, executing shell commands. Tenant policy doesn't reach into the dev machine; OS-layer enforcement does.
The risk profile that's specific to Copilot
The Copilot family has a few characteristics that make the runtime risk distinct from other vendors' agents:
- Pre-authenticated to everything. By design, Copilot inherits the user's identity across the Microsoft graph. A successful prompt injection inherits that same scope.
- Indirect prompt injection from documents. A poisoned email, a poisoned SharePoint doc, a poisoned Teams message — all valid inputs to a grounded Copilot session, all capable of redirecting the agent toward an action the user did not intend.
- Heavy in-process integration. Copilot for Windows lives close to the OS. Its sub-agents and connectors don't show up as separate, easily-attributable processes; they operate as part of an integrated Microsoft surface.
- GitHub Copilot agents on developer machines. Different binary, different lifecycle, different blast radius — but increasingly the place where production credentials and proprietary code intersect.
The Copilot firewall isn't a substitute for Microsoft's controls. It's the OS-layer counterpart that makes those controls verifiable on the device where the action actually happens.
How Ospiri's Copilot firewall works
Ospiri's agent firewall applies the same kernel-grade isolation model to the Copilot family that it does to every other agent — with Copilot-specific signatures, policy templates, and attribution logic so the SOC can answer the question "what did Copilot just do on that machine?"
- Per-process network policy on Copilot binaries. Allow grounded queries against M365 services; restrict egress to third-party endpoints introduced by a plugin or connector. Built on the Windows Filtering Platform — the same kernel-level technology as the Windows firewall, enforced at the agent process level.
- Filesystem isolation with copy-on-write. When a GitHub Copilot agent edits a sensitive directory, the firewall clones the affected files into a sandbox. The agent gets the functionality it needs. The original tree is untouched until policy commits, discards, or escalates the change.
- Registry isolation. Stops a Copilot plugin or installer from establishing persistence, modifying autoruns, or tampering with other software on the device.
- Object isolation. Constrains the IPC surface so a Copilot Studio agent can't quietly orchestrate other processes on the box.
- Continuous Copilot signature coverage. M365 Copilot, GitHub Copilot agents, Copilot Studio runtimes, and the connector ecosystem are tracked by the same signature pipeline that handles every other agent — so a new release or a new plugin doesn't show up as an unknown binary.
Where this fits in the existing Microsoft security stack
Defender, Purview, and the Microsoft admin surfaces handle a lot — identity, conditional access, label propagation, tenant-level connector controls. Ospiri sits underneath all of it, on the kernel side of the OS, and answers a different question: given that this is Copilot, and given the environment it's running in, is this specific action within policy? The two layers compose. Tenant policy says whether Copilot is allowed to run; the Copilot firewall says what it's allowed to do once it does.