AI controls for cloud workspaces and virtual desktops

What counts as a cloud workspace?

Three common forms. A virtual desktop runs a full desktop on a server and shows it on the user's screen. A cloud development environment gives a developer a remote machine, usually opened from a browser or an editor, where code is built and run. And some teams work almost entirely in browser-based SaaS, where the laptop is little more than a window.

In each case, the AI tool does its work somewhere other than the laptop. A coding agent in a cloud development environment reads files and runs commands on the remote machine. An AI feature inside a SaaS product runs on the SaaS vendor's servers.

Which control positions still apply?

• AI or MCP gateway: stronger. Traffic from servers you run is easy to route through a gateway, and remote MCP servers can be put behind it.
• Network or SSE proxy: stronger, for the same reason. The workspace's outbound traffic already passes infrastructure you choose.
• On-device control: it depends. The device is now the workspace image. If the vendor supports installing its component there, it can see the agent's local actions as it would on a laptop.
• Browser extension: still useful for browser AI on the laptop, but it sees nothing inside a remote desktop.

What about AI inside SaaS products?

AI features built into SaaS applications, such as assistants inside office suites or CRM systems, are controlled mostly through the SaaS vendor's own settings and through products that connect to those platforms. Several products here describe that kind of coverage: Zenity lists integrations with platforms including Microsoft 365 Copilot, Copilot Studio, Salesforce, Agentforce and ServiceNow, and Noma Security covers SaaS and homegrown agents as well as endpoints. Bay, by contrast, is endpoint only.

What does the finder do with this answer?

Partly cloud workspaces adds a point to the gateway position. Mostly cloud workspaces adds three points to the gateway and one to the network proxy, and it switches on a check for products that also cover SaaS, cloud or homegrown AI. In our example profile of cloud workspaces behind an SSE with regulated data, the finder starts at on-device control but picks the network and gateway positions as also relevant, and products whose pages describe the network and gateway positions move up the list.

What should you ask?

• Can your on-device component run inside our virtual desktop or cloud development environment images?
• Can your gateway sit in front of the MCP servers our workspaces use?
• Do you cover AI features inside the SaaS products we use, and how?

What is the common mistake?

Buying a laptop control for a workforce that does its sensitive work in remote workspaces. The control may install and report cleanly while the coding agents that matter run on servers it never sees. Before any pilot, write down where each team's AI tools actually execute: on the laptop, in a virtual desktop, in a cloud development environment, or inside a SaaS product. Then pick the control positions that cover those places, and test them there rather than on a spare laptop.

Sources