Skip to main content

Prerequisites

Common requirements that apply to every Quilr Endpoint Agent rollout — Windows or macOS, Intune / Jamf / Kandji / ManageEngine / manual. Each deployment guide additionally lists a short platform-specific prereq table (e.g. Intune Win32 Content Prep Tool, Jamf inventory freshness).

What you need before starting​

RequirementDetails
Quilr environmentKnow which Quilr tenant your bundle was built against (e.g. quilr-saas-usa-prod, quilr-saas-japan, quilr-saas-ind-prod). The environment determines which backplane hosts you allowlist in § Firewall and Network Allowlist. Confirm with Quilr support if unsure.
Install bundleLatest signed install bundle obtained from Quilr support (support@quilr.ai). Verify the checksum before extracting. Bundle contents differ by platform — Windows: quilr-endpoint-agent.msi + 2 CA .crts. macOS: quilr-endpoint-agent-installer.pkg + 2 CA .cers + Configuration Profile templates.
MDM accessAdmin rights on your MDM platform: Microsoft Intune (Intune Administrator), Jamf Pro (Site or Cloud admin), Kandji (admin), ManageEngine Endpoint Central (admin). For macOS the device must be MDM-supervised (DEP / Automated Device Enrollment is preferred so System / Network Extensions are auto-approved).
Endpoint OSWindows: 10 1809+ or 11, x64 only. macOS: 12 Monterey or later, Apple Silicon or Intel. Older OS versions are not supported by the agent's WFP driver / System Extension.
Network egress (TCP 443)Endpoints must reach the Quilr backplane hosts on TCP 443. The full allowlist (shared hosts + per-tenant Base URL / DLP) is in § Firewall and Network Allowlist below.
TLS-intercepting SWG (if used)Zscaler / Netskope / Symantec WSS / Forcepoint / iboss must SSL-bypass every Quilr backplane host. The agent pins TLS against Quilr's internal CA chain (deployed in Part 2 of each guide) — SWG re-signing breaks the handshake.
Pilot groupA small group of devices (suggested naming Quilr-Pilot) to validate against before broad rollout. Promote to Quilr-Production after validation.
CA trust deploymentThe agent's leaf cert chains to a Quilr root + intermediate that must land in the system trust store before the agent service starts. Each deployment guide's Part 2 covers this.

Platform-specific add-ons​

Each guide lists the tools / preconditions unique to that MDM. Quick pointer to where the platform-specific prereqs live:

MDM / pathPlatform-specific prereqs in
Microsoft Intune (Windows)Intune — Windows guide § Prerequisites
Microsoft Intune (macOS)Intune — macOS guide § Prerequisites
Jamf ProJamf Pro guide § Prerequisites
KandjiKandji guide § Prerequisites
ManageEngine Endpoint CentralManageEngine guide § Prerequisites
Manual macOS installManual install guide § Prerequisites

Firewall and Network Allowlist​

The Quilr Endpoint Agent makes outbound HTTPS (TCP 443) to a small set of Quilr backplane hosts. Where the perimeter is enforced — corporate firewall, egress proxy, or TLS-intercepting Secure Web Gateway (Zscaler, Netskope, Symantec, Forcepoint, etc.) — these hosts must be allowed before the agent installer is deployed.

Pick the row that matches your tenant

The host set depends on which Quilr environment your bundle was built against (bff, dlpPrefix, updateUrlPrefix). Confirm with Quilr support if you are unsure which environment applies.

Step A. Quilr control-plane hosts​

Shared across all environments — allowlist these regardless of tenant:

HostPurpose
discover.quilrai.devTenant / endpoint discovery
log.quilrai.devDiagnostic log shipping (enabled when diagnostics are turned on)
quilr-extensions.quilr.aiBrowser-extension / agent update distribution (default CDN)

Per-environment — pick the row that matches your tenant:

EnvironmentBase URLDLP
quilr-saas (US — default)app.quilr.aidlpone.quilr.ai
quilr-saas-ind (IN)platform.quilr.aidlp-platform.quilr.ai
quilr-saas-ind-prod (IN, .com)platform.quilrai.comdlp-platform.quilrai.com
quilr-saas-usa-prod (US, .com)app.quilrai.comdlpone.quilrai.com
quilr-saas-japanapp-jp.quilr.aidlpone-jp-1.quilr.ai
poc-saas-uaetrust.quilr.aidlp-platform.quilr.ai
quilr-saas-psr (pre-prod)psr.quilr.aidlppreprod.quilr.ai
quartzquartz.quilr.aidlpone.quilr.ai
quilr-poc2secure.quilr.aidlpone.quilr.ai
Dedicated PaaS / on-prem deployments

If your tenant runs on a customer-owned domain (your own DNS / on-prem control plane), the shared hosts above still apply — Quilr support provides the tailored Base URL + DLP allowlist for your specific deployment. Contact support@quilr.ai.

Step B. Additional update / artifact CDN (env-specific)​

Most environments use the default quilr-extensions.quilr.ai (already in Step A). A few environments use an additional CDN — allowlist the matching row in addition to Step A:

HostUsed by environments
quilr-extensions.quilrai.comquilr-saas-ind-prod, quilr-saas-usa-prod
quilr-hub.quilr.aiquilr-poc2

If your environment is not listed above, Step A alone covers update distribution.

Step C. TLS-intercepting proxies — SSL-bypass​

If your egress sits behind Zscaler / Netskope / Symantec WSS / Forcepoint / iboss / etc., add every host from Steps A and B to the SSL-bypass (no TLS inspection) list. The agent pins TLS to Quilr's internal CA chain (deployed in Part 2 of each deployment guide) — re-signing through the SWG's CA breaks the handshake and the agent will fail to connect.

For the upstream SWG rules covering monitored AI hosts (ChatGPT, Claude, Gemini, etc.), see the companion URL Exception List — AI Apps and URL Exception List — Non-AI Apps — those cover apps the agent inspects, not the Quilr backplane itself.

Step D. Validate egress from a pilot device​

From a pilot endpoint, verify reachability before installing the agent:

Windows (PowerShell, elevated):

# Replace the first two hosts with the row from Step A that matches your tenant.
$targets = @(
    'app.quilr.ai',              # Base URL
    'dlpone.quilr.ai',           # DLP
    'discover.quilrai.dev',      # Discover (shared)
    'log.quilrai.dev',           # Diagnostic log (shared)
    'quilr-extensions.quilr.ai'  # Update / extension CDN (shared)
)
foreach ($h in $targets) {
    $ok = Test-NetConnection -ComputerName $h -Port 443 `
            -InformationLevel Quiet -WarningAction SilentlyContinue
    "{0,-40}  TCP/443  {1}" -f $h, $(if ($ok) { 'OK' } else { 'BLOCKED' })
}

macOS (same allowlist applies — the agent backplane is platform-agnostic):

for h in app.quilr.ai dlpone.quilr.ai discover.quilrai.dev log.quilrai.dev quilr-extensions.quilr.ai; do
  out=$(nc -zv -G 5 "$h" 443 2>&1)
  if [[ "$out" == *succeeded* ]] || [[ "$out" == *open* ]]; then status=OK; else status=BLOCKED; fi
  printf "%-40s  TCP/443  %s\n" "$h" "$status"
done

Any BLOCKED host means the firewall / SWG / corporate proxy still needs adjustment. Re-run the test after the network team applies the allowlist.

Notes on endpoint firewalls​

On a default install of either Windows or macOS, outbound TCP 443 is unrestricted — per-host outbound rules on the endpoint firewall are normally not required. The standard path is to allowlist Quilr backplane FQDNs at the egress proxy / SWG / corporate firewall, not on the per-endpoint Defender Firewall (Windows) or PF (macOS).

If your fleet enforces an outbound block-by-default policy on the endpoint, each deployment guide's Section 3 covers the platform-specific path: program-path allow rules for Windows Defender Firewall, PF anchors via the agent .pkg postinstall on macOS.

See also​