Stage 2 — Tighten the Policy
With the app proven on fulltrust (Stage 1), the goal now is to remove trust until the session is isolated to the level your data sensitivity requires — without breaking the app. The technique is incremental: clone the working policy, change one thing, test, and only keep the change if the app still works. Because compatibility was already established in Stage 1, any regression you see is caused by the last setting you touched.
Set up an editable policy
- Clone
fulltrustin the Policies editor and give the copy a working name (for examplemyapp_tuning). Never edit the built-in templates. See Policy Sets & the Editor. - Assign the clone to your Stage 1 Virtual Desktop workspace so you keep testing in the same known-good delivery mode.
- Change one setting, save, relaunch, and re-run your core workflow. Keep the change if the app still works; revert it if it does not, and note why.
You are moving from fulltrust toward lowtrust (or notrust/disposable for the most sensitive workloads). The right stopping point is the loosest policy that still meets your isolation requirement — over-tightening only creates support tickets.
Isolation checklist
Work down this list. Each row maps an isolation goal to the policy node that controls it and the reference page with the exact properties, units, and any app.config.xml overrides. Change one row at a time.
| Isolation goal | Policy node | Reference |
|---|---|---|
| Restrict which files and paths the app can reach | security.fileSystem (trustLevel, allowed/blocked paths, virtual shares) | File System |
| Stop data leaving through copy/paste | security.clipboard (enabled, direction, max size) | Clipboard |
| Control upload/download across the browser boundary | security.dataTransfer (upload/download toggles, max file size) | Client Data Transfer |
| Confine or block network access | security.network (isolation, allowed/blocked domains, loopback) | Network Isolation |
| Prevent the app from spawning other processes | security.childProcessPolicy (allow child processes, allow/block lists) | Child Process Control |
| Govern file picker behaviour | security.dialogs (headless dialogs, native fallback) | File Dialogs |
| Control printing / document egress | security.printing (enabled, physical printers, max output size) | Printing |
| Discard or persist user state between sessions | session.sessionIsolation (profile cleanup, registry/filesystem persistence) | Session Isolation |
| Cap CPU, memory, resolution, and frame rate | resources (CPU/RAM limits, resolution, FPS, disk quota) | Resources |
Common regressions while tightening: the app can no longer open or save where it expects (file system), an updater or helper fails to start (child process control), activation or a backend call fails (network isolation), or settings no longer persist between sessions (session isolation). Each maps directly to a checklist row, so revert that one node and reconsider the requirement.
Some policy values are capped, gated, or forced by the Gateway's app.config.xml. If a setting does not take effect as expected, check the override notes on the relevant reference page and see Policies for how the two layers combine.
Once the app runs correctly at your target isolation level, you have a policy you trust. Continue to Stage 3 — App Collection Delivery to project just the single app.