Planning

Decisions and checks to make before rolling Levee out to many Windows 11 computers

Rolling Levee out is mostly a standard MSI deployment, run by IT. Two things make it different: Levee runs Windows containers on each computer, and it puts your policy between the AI agent and your network, data, and files. Work through this page before you go beyond a pilot group.

For business owners, the page answers one question: what must be decided before people can use Levee. The main decisions are which AI tools and models to offer, which websites, databases, and folders an agent may reach, and where the audit trail goes.

Deployment checklist

What does Levee change on a computer?

Levee adds Windows services, a private container engine, and a file-system driver. Each AI agent session runs in a Windows container on the computer itself, not in a virtual machine. Use this list to brief your endpoint, network, and security teams:

• Two Windows services run as LocalSystem: LeveeService and LeveeContainerEngine. Both start automatically.
• Windows containers with process isolation. Each running project is a container that shares the host kernel. No Hyper-V, no virtual machine, no hardware virtualization.
• A private container engine. Levee's engine is separate from Docker Desktop or any other Docker engine. Those can stay installed. Levee does not use them, and they do not affect Levee.
• The LeveeFS file-system driver (LeveeFs) and its Windows service, LeveeFSHost. They show the files and folders a user shares with a project inside the sandbox. The Levee MSI installs them.
• One active project per computer. Levee runs one project at a time on a machine. A second start is refused until the first project stops, even when another Windows user started it.
• Operating-system network enforcement. Levee blocks any container traffic that does not go through its policy channels. Endpoint firewalls must allow local traffic between the container network and the host.
• A per-session certificate authority for TLS inspection, used only for domains where your policy turns inspection on. See Web access.
• Programs under Program Files, data under ProgramData. Programs go in %ProgramFiles%\Vediram\Levee, where only administrators can change them. Policy, the audit log, logs, container images, and engine data go in %ProgramData%\Vediram\Levee. Plan for several GB. See Files & locations.

Users do not need administrator rights to use the Levee app.

Windows container compatibility

The container image Levee runs must match the Windows build of the computer. Levee picks and checks that image for you, and Vediram keeps it aligned with supported Windows 11 releases.

What this means for you:

• Don't override the container image (container.baseImage) in policy unless Vediram support asks you to.
• Include Levee in your Windows update pilot ring. Validate Levee on pilot machines before a Windows 11 update (monthly or yearly) reaches the whole fleet, as you would for any software that runs containers.
• If projects fail to start after a Windows update, see After a Windows update.

Antivirus and EDR

Exclude one folder, the container engine's data folder, from real-time scanning. Keep scanning everything else, including the users' project folders.

Container images and container file systems are made of many small files that are unpacked and opened at container start. Real-time scanning of those files slows image loading and project start dramatically.

Exclude this folder from real-time scanning:

%ProgramData%\Vediram\Levee\engine\data

For Microsoft Defender Antivirus, from an elevated prompt or through your management tool:

Add-MpPreference -ExclusionPath "$env:ProgramData\Vediram\Levee\engine\data"

Do not exclude the project folders (%USERPROFILE%\LeveeProjects). That's where the agent writes files, and your normal scanning policy should apply there.

Microsoft Defender for Endpoint and most EDR products recognize Windows containers and coexist with Levee. If your EDR flags the Levee service or container engine, add a process exclusion for the binaries in %ProgramFiles%\Vediram\Levee\bin and %ProgramFiles%\Vediram\Levee\engine, and let us know through a support request.

Network and proxies

The computer itself makes every outbound connection, through Levee. The agent's traffic stays subject to your normal perimeter controls and to the Levee policy.

Outbound access the host needs:

Corporate web proxies: Levee sends the agent's outbound web traffic through the machine's system proxy configuration, including PAC files. Changes to the system proxy take effect when the project restarts. Proxies that require their own authentication challenge (HTTP 407) are not supported for agent traffic. Allow the machine to reach the destinations without an interactive proxy challenge.

VPN clients: Always-on VPN clients that force all routes into the tunnel (for example, some Cisco AnyConnect or GlobalProtect configurations) can capture the local traffic between the container and the host. The symptom is that agents in every project time out on every request. If you see this, exempt the local container network from the VPN's enforced routes. See Project won't start.

Central or local policy?

Most organizations manage policy centrally in Vediram Cloud. Organizations without a cloud connection deploy a policy file instead. Either way, each computer enforces one file, %ProgramData%\Vediram\Levee\policy.json.

You can combine them: Cloud policy replaces only the sections it defines and leaves the others as they are in the local file. The exception is web access, which always comes from the Cloud policy once one is applied. See How policy works.

Without a policy, Levee denies everything. Plan your first policy before users get the app.

Which features to plan for

Each feature below stays closed until your policy opens it. Decide with the business owners what each team needs.

Virtual desktops

Levee runs in single-user Windows 11 virtual desktops on any hypervisor, because it needs no nested virtualization. Multi-session hosts are not supported.

Supported platforms include Windows 365, Azure Virtual Desktop personal host pools, VMware Horizon, Citrix, and Nutanix. For VDI:

• Enable the Containers feature in the golden image.
• Size the desktop for the hardware requirements, especially memory and disk.
• For non-persistent desktops, the container runtime image is downloaded on each fresh desktop unless it's in the image. Pre-stage it in the golden image (see Container runtime) or point devices at a nearby mirror.

Know the support position

Levee's protection rests on the network and data channels it controls, not on the container boundary alone. Share this section with your security reviewers.

Levee's sandbox uses Windows containers with process isolation on Windows 11. Microsoft documents process isolation on client editions of Windows for development and testing scenarios, and does not treat the process-isolation boundary as a serviced security boundary. Levee is designed with that in mind. See Security model & limits.

Pilot first

Start small with rules that ask before allowing, then tighten them from what the audit log shows.

1. Deploy to a small pilot group with a permissive-but-audited policy: escalate rules for web access, so users approve what the agent needs.
2. Review the audit log after a week to see which domains, models, and data sources agents actually use.
3. Turn the approved destinations into allow rules and the rest into deny.
4. Widen the rollout in rings, and keep Levee in your Windows update pilot ring.

Next steps

• Enterprise deployment: silent install and Intune or Configuration Manager packaging.
• Connecting to Vediram Cloud.