Gemini lands in enterprises in a different shape than Claude or Copilot. Most large organizations are a Microsoft shop on the endpoint, then add Google for a specific reason — a Workspace pocket, a research function, a long-context use case, a developer using a Gemini-powered coding tool. The result is the hardest configuration to govern: a Google-identity agent acting on a Windows device that the Microsoft admin surface doesn't model.
The Gemini firewall is the OS-layer answer. It treats Gemini agents as a known class with their own signature set and policy templates, enforced at the kernel — independently of what either Google or Microsoft's tenant controls expose.
What a Gemini firewall actually has to govern
The Gemini surface on Windows is broader than the Gemini brand suggests. A useful Gemini firewall has to model each piece:
- Gemini desktop and Gemini-in-the-browser. Reads local content for context, increasingly drives the browser to take actions, talks to user-configured tools.
- Gemini coding agents. Edit files, run shell commands, install packages, call out to model-side tools — same shape as other coding agents, with Google's identity rather than Microsoft's or Anthropic's.
- Gemini for Workspace integrations. Grounding against Google Drive, Gmail, and Workspace data on a device that's enrolled in a Microsoft tenant. The cross-cloud data path is invisible to the local DLP stack.
- Browser automation and computer-use capabilities. Gemini's browser-driving features collapse the perimeter the same way Claude Dispatch does — the agent is taking UI actions on behalf of the user, often with no human in the loop on each step.
The risk profile that's specific to Gemini
Gemini's risk profile on a Windows endpoint is shaped by three things: cross-cloud identity, broad grounding scope, and the speed at which Google is shipping autonomous capabilities.
- Cross-cloud identity. Gemini-on-Windows often runs as a Google identity on a Microsoft-managed device. Conditional access in Entra doesn't see the Workspace side; Google's admin console doesn't see what happened on the local filesystem. Without an OS-layer view, neither side has the full picture.
- Long-context grounding. Gemini's context windows make it well-suited to grounding on large local document sets — which is also exactly the surface where indirect prompt injection from a poisoned document is most effective.
- Browser-driving and computer-use capabilities. The agent takes UI actions across applications, often faster than a SOC analyst can review. The default policy class for these sessions has to be restrictive.
- Rapid release cadence. Google ships new Gemini binaries and capabilities frequently. A signature pipeline that updates monthly will lag.
If you let a Google-identity agent take browser actions on a Microsoft-managed laptop, the Microsoft admin surface and the Google admin console will both see half of what happened. The Gemini firewall is what sees the rest.
How Ospiri's Gemini firewall works
Ospiri's agent firewall applies the same kernel-grade isolation model to Gemini that it does to every other agent — with Gemini-specific signatures, policy templates, and attribution logic so the SOC can answer the question "what did Gemini just do on that machine?"
- Filesystem isolation with copy-on-write. When a Gemini coding 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.
- Per-process network policy. Built on the Windows Filtering Platform. Allow Gemini to reach Google APIs and the destinations your policy permits; restrict reachability for any unfamiliar endpoint introduced by a plugin or grounding source.
- Registry isolation. Stops a Gemini installer or extension from establishing persistence, modifying autoruns, or tampering with other software on the device.
- Object isolation. Constrains the IPC surface so Gemini's browser-driving and computer-use components can't quietly orchestrate other processes on the box outside policy.
- Continuous Gemini signature coverage. Gemini desktop, Gemini coding agents, browser-driving runtimes, and emerging Google capabilities are tracked by the same signature pipeline that handles every other agent — so a new release doesn't show up as an unknown binary.
Where the Gemini firewall fits with EDR and Workspace controls
EDR sees a signed Google binary writing files and reaching the network — and by EDR's lights, that's not a threat. Google Workspace's admin controls see what the Gemini service did on the Google side, but not what the local Gemini process did on a Windows filesystem. Microsoft's admin surface sees the device but not the cross-cloud agent. The Gemini firewall sits beneath all of them and asks a different question: given that this is Gemini, and given the environment it's running in, is this specific action within policy?