Limitations & Scope

Documented boundaries of the Launcher Policy System, with concrete, vendor-neutral guidance on how to operate securely within these constraints today.

What You'll Learn

• Enforcement scope for launches and discovery
• Practical patterns for exclusions and negation
• ABAC attributes, context, and externalized decision inputs

Enforcement scope for launches

Launcher policy evaluation applies to applications discovered by configured providers and launched through the Launcher execution path.

Typical providers include OS application catalogs (e.g., Start Menu/Desktop shortcuts, App bundles, .desktop files), web entries (PWAs, SaaS, bookmarks), CLI/path discovery, portable apps, and Turbo Workspaces. See: Application Discovery.

Operate securely today

• Publish and launch managed software through the Launcher. Use Launch Profiles for approved variants.
• Use OS execution controls to constrain alternate vectors and require approved paths. Examples include enterprise application control policies and endpoint protections that restrict unapproved binaries and enforce allowlists.
• Route ad-hoc launches through the Launcher using shell integrations or CLI wrappers when available, ensuring the same policy evaluation path is used.
• Prefer managed file associations that open content via Launcher-authorized applications.

Notes

• Discovery providers are configurable; provider priority determines which record represents a given app. Policy authorizations and modifications are applied to discovered entries that match allow rules. See: Authorization & Visibility.

Process Tree Inheritance

Security controls (Network, Data Motion, Storage) apply to the authorized application and are strictly inherited by any child processes spawned within the sandbox.

Child Process Inheritance: For example, if powershell.exe is authorized but network-restricted, any script or binary it executes (e.g., curl.exe, script.ps1) inherits those exact network restrictions. This ensures that attackers cannot bypass controls simply by spawning a helper process.

Exclusions and negation

The policy language emphasizes positive, readable allow rules. There is no native "NOT" operator on matchers. Use one or both of the following patterns:

• Deny policies: Author an explicit action: "deny" policy that matches the variant to exclude. Deny takes precedence when both allow and deny match the same executable.
• Regex exclusions: Use a regex matcher with a negative lookahead to exclude specific arguments or paths when a single rule is preferred.

Examples

Deny the excluded variant (preferred for readability):

{
  "id": "deny-mytool-private",
  "enabled": true,
  "priority": 500,
  "matchAll": [
    { "type": "targetPath", "pattern": "**\\\\mytool.exe", "patternType": "glob" },
    { "type": "arguments", "pattern": ".*--private.*", "patternType": "regex" }
  ],
  "action": "deny"
}

Allow the standard variant:

{
  "id": "allow-mytool",
  "enabled": true,
  "priority": 400,
  "matchAll": [ { "type": "targetPath", "pattern": "**\\\\mytool.exe", "patternType": "glob" } ],
  "action": "allow"
}

Single-rule exclusion via regex (negative lookahead):

{
  "matchAll": [
    { "type": "targetPath", "pattern": "**\\\\mytool.exe", "patternType": "glob" },
    { "type": "arguments", "pattern": "^(?!.*--private).*$", "patternType": "regex" }
  ],
  "action": "allow"
}

See boolean logic and matching semantics: Matchers & Patterns — Boolean logic semantics.

ABAC attributes and external decisions

Attribute-based access control (ABAC) combines normalized identity attributes with contextual constraints.

• Identity attributes are provided by configuration.identity.claimsMapping and referenced from apps[].authorization.requirements.userAttributes.
• Contextual constraints (e.g., allowed geos, compliant host) are evaluated using configuration.security.hostAttestation and related posture signals.
• Policy decisions are made locally using the attributes available at evaluation time. Enterprises can externalize decision inputs by ensuring authoritative attributes are present in the identity token or by delivering pre-evaluated attributes through the policy delivery pipeline.

Operate securely today

• Keep claimsMapping stable and minimal; source authoritative values from your identity provider at sign-in and via session policies.
• Use contextual constraints (requireCompliantHost, allowedGeos, etc.) to reflect device posture and environment in authorization decisions.
• When decisions depend on externalized logic, propagate outcomes into mapped attributes (for example, entitlement or clearance claims) and author ABAC requirements against those attributes.

References

• ABAC authorization requirements: Authorization & Visibility
• Identity and posture configuration: Global Configuration

Interactive workflows and user justification

Data Motion rules are evaluated locally and synchronously with respect to clipboard, drag-and-drop, screen operations, browser uploads, peripherals (USB, printers), and external processors. Actions are limited to allow, deny, or process (pipelines) and do not display prompts or collect user justifications directly.

To implement workflows such as "require a justification before allowing a transfer", combine Data Motion policy with higher-level UX and exception mechanisms:

• Deny by default in policy: Author Data Motion rules that deny high-risk transfers (for example, based on classification or destination) so that the baseline posture is fail-closed.
• Collect justification in the UX layer: When a transfer is denied, the enclosing application or management console can present a dialog that explains the policy and allows the user to submit a justification or exception request.
• Use exception workflows: Process exceptions out-of-band (for example, via administrative approval flows) and materialize them as more permissive policies or short-lived overrides for specific users, groups, or workspaces.
• Audit decisions and justifications: Use Audit Trails to record both the original Data Motion decision and any subsequent override, including justification text where applicable, so reviewers can reconstruct why a transfer was ultimately allowed.

This pattern keeps Data Motion decisions deterministic and auditable, while still enabling interactive "justify and request override" workflows where required by modern DLP programs.

In practice, enterprises typically distinguish two categories of interactive workflows:

• User justification only: The deny decision stands in policy, but the enclosing UX collects a justification and may resubmit the operation under a narrowly scoped, short-lived exception (for example, user-scoped and time-bound) that is itself represented as policy.
• Delegated/managerial approval: The same deny event produces a structured exception request (with justification attached) that is routed to Workspace or Hub administrators. If approved, the grant is realized as a scoped override in policy (for example, workspace or group-scoped) and is fully audited.

Which path you use is governed by your exception configuration and audit requirements (see Audit Trails — Exception Requests), not by additional allow/deny variants in Data Motion itself.