> ## Documentation Index > Fetch the complete documentation index at: https://quintsecurity.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Fleet Management > Enroll, monitor, and manage Quint daemons across your organization # Fleet Management Fleet management is how security teams deploy and control Quint across developer machines, CI runners, and cloud VMs. From a single dashboard, you can enroll new machines, push policy updates, monitor daemon health, and maintain fleet-wide visibility into AI agent activity. ## How It Works ```mermaid theme={null} sequenceDiagram participant Admin as Security Admin participant Dash as Quint Dashboard participant API as Quint Cloud API participant Daemon as Edge Daemon Admin->>Dash: Generate deploy token Dash->>API: POST /v1/auth/keys (scope: fleet:enroll) API-->>Dash: Deploy token (qk_...) Admin->>Daemon: curl install script --token Daemon->>Daemon: Download binary, register service Daemon->>API: Register (token + machine fingerprint) API-->>Daemon: Enrollment confirmed + policy bundle loop Every 30s Daemon->>API: Heartbeat (status, agent count, tier) API-->>Daemon: Policy updates (if changed) end loop Every 10s Daemon->>API: Batch sync (audit events) end Admin->>Dash: View fleet status Dash->>API: GET /v1/fleet API-->>Dash: All machines, agents, health ``` ## Enrollment Every daemon enrollment follows the same three-step flow: A security admin creates a deploy token in the Quint dashboard. Tokens are scoped to an organization and can be restricted to specific machine groups or environments. Each token is a standard Quint API key (`qk_...`) with `fleet:enroll` scope. Install via the `.pkg` installer (macOS) or the one-line install script: ```bash theme={null} # macOS .pkg sudo installer -pkg quint-latest.pkg -target / # Or one-line install script Deploy the signed `.pkg` through your MDM (Jamf, Intune, Kandji) with the deploy token as a payload variable. See /operations/installation. ``` The `.pkg` installs the LaunchDaemon and QuintAgent.app (ES extension). The script auto-detects the OS and architecture. On first start, the daemon sends a registration request to the Quint cloud API with the deploy token and a machine fingerprint (hostname, OS, architecture, MAC address hash). The API validates the token, creates a machine record, and returns the organization's policy bundle. Deploy tokens can be revoked at any time from the dashboard. Revoking a token prevents new enrollments but does not affect already-enrolled daemons. ## Fleet Deployment Methods | Method | Status | Use Case | | -------------------------- | --------- | --------------------------------------------------- | | `.pkg` installer | Shipped | macOS: LaunchDaemon + QuintAgent.app (ES extension) | | `curl` + deploy token | Shipped | Individual developer machines, quick setup | | Signed `.pkg` via MDM | Next | Jamf, Intune, Kandji distribution | | Ansible / Puppet / Chef | Post-seed | Configuration management at scale | | Helm chart | Post-seed | Kubernetes clusters and containerized workloads | | GitHub Actions / GitLab CI | Post-seed | CI/CD pipeline protection | The `.pkg` installer and `curl` script are the shipping methods today. The `.pkg` includes both the Go daemon and the QuintAgent.app (ES system extension). Configuration lives at `/etc/quint/config.yaml`. ## Policy Distribution Policies flow from the dashboard to every daemon in the fleet: ```mermaid theme={null} flowchart LR A["`**Dashboard** Define policies`"] --> B["`**Cloud API** Store + version`"] B --> C["`**Policy Sync** Push on heartbeat`"] C --> D["`**Daemon** Enforce locally`"] D --> E["`**Audit Log** Record verdicts`"] E --> B ``` 1. **Define** -- Security admins create or update policies in the dashboard (risk thresholds, blocked tools, alert rules) 2. **Store** -- The cloud API versions each policy change and stores it in Postgres 3. **Sync** -- Daemons receive policy updates on their next heartbeat (every 30 seconds). Policies can also be force-pushed for critical changes. 4. **Enforce** -- The daemon applies policies locally with zero cloud dependency. If the cloud is unreachable, the last-synced policy remains in effect. 5. **Report** -- Policy verdicts (ALLOW, BLOCK, ALERT) are included in audit events synced back to the cloud Daemons enforce the last-synced policy if they lose cloud connectivity. Design your default policies with this in mind -- they should be safe to run independently. ## Health Monitoring Every daemon sends a heartbeat to the cloud API every 30 seconds. The heartbeat includes: | Field | Description | | ----------------- | ------------------------------------------- | | `machine_id` | Unique machine fingerprint | | `hostname` | Machine hostname | | `os` / `arch` | Operating system and architecture | | `daemon_version` | Installed daemon version | | `protection_tier` | Current tier: `proxy`, `kernel`, or `both` | | `uptime` | Time since daemon last started | | `active_agents` | Number of AI agents currently tracked | | `last_action_at` | Timestamp of most recent intercepted action | | `policy_version` | Hash of currently enforced policy bundle | | `status` | `healthy`, `degraded`, or `error` | ### Health States Daemon is running, intercepting traffic, and syncing with cloud. Heartbeat received within the last 60 seconds. Daemon is running but reporting issues: cloud sync failures, certificate expiry warnings, or high memory usage. No heartbeat received for more than 5 minutes. Machine may be off, daemon may have crashed, or network is unreachable. ## Dashboard Fleet View The fleet view in the Quint dashboard provides a single pane of glass for all enrolled machines: | Column | Description | | ---------------- | ---------------------------------------------------------- | | **Machine** | Hostname and OS badge | | **Status** | Health indicator (healthy / degraded / offline) | | **Protection** | Current tier (Proxy / Kernel / Both) | | **Agents** | Number of active AI agents on this machine | | **Last Seen** | Time since last heartbeat | | **Risk Summary** | Breakdown of recent verdicts (allowed / blocked / alerted) | | **Policy** | Currently enforced policy version | | **Version** | Daemon version with upgrade-available indicator | ### Fleet Grouping Machines can be organized into groups for targeted policy application: * **By environment** -- Development, Staging, Production * **By team** -- Engineering, Data Science, Security * **By role** -- Developer workstations, CI runners, Cloud VMs Groups are assigned during enrollment (via deploy token scope) or manually in the dashboard. ## Fleet Lifecycle Generate deploy token, run install script on target machine. Daemon registers and receives initial policy bundle. Dashboard shows real-time fleet health. Alerts fire for offline daemons, policy drift, or version mismatches. Push policy changes from the dashboard. All daemons in scope pick up changes within 30 seconds. New daemon versions are distributed via the same install mechanism. The daemon restarts with zero downtime (graceful handoff). Revoke the machine from the dashboard. The daemon stops syncing and can be uninstalled. Audit history is retained in the cloud.