Skip to main content
AI Watch ships as one signed package per operating system. Deploy it once, then manage its behavior from Runlayer or package configuration. macOS and Windows are supported equally: both packages provide the same Monitor, Protect, Enforce, and Sessions behavior. Their installers receive only bootstrap credentials; behavior arrives through the same Runlayer settings sync. See platform support for supported architectures and Linux.

Features

Project and client-config detection is always enabled after AI Watch is installed. Before the first successful settings sync, the endpoint starts in Monitor with Sessions and optional runtime discovery disabled, so no hooks are installed. One organization API key authenticates AI Watch scans, hooks, session events, and managed updates; no enrollment keys are required.
  • Running-process and container discovery are disabled until the synced settings enable them.
  • Monitor is the default mode.
  • Sessions and hooks fail closed before settings sync. A successful settings sync or an explicit legacy MDM Sessions=true / Protect / Enforce setting enables them.
  • Sessions coverage follows the client surface. Installing the full hook set does not make a client emit events it does not support. Cursor’s classic IDE and Agents Window load the endpoint hook config, while Cursor CLI emits a subset. Cursor Cloud Agents require the separate repository/team hook collector; it is monitor-only and does not inherit endpoint configuration.
Hooks are installed whenever Mode is Protect/Enforce, Sessions is enabled, or Track MCP tool usage without content is enabled; otherwise AI Watch removes stale Runlayer hooks while preserving third-party hooks.
Legacy fleets only: on AI Watch builds that predate settings sync, push the native keys manually and pair them — Monitor with Enforcement=false, Protect and Enforce with Enforcement=true. A valid Mode value overrides the legacy Enforcement boolean.
On macOS and Windows, admins can change Mode, Sessions, process/container discovery, project depth, and project timeout from Settings → AI Watch → Manage settings. Devices fetch the complete settings snapshot during the privileged hook reconcile, typically within an hour, without an MDM policy update. On macOS with AI Watch 0.29.6 or newer, the same settings page can install or remove the managed Chrome and Firefox extensions and configure their mode and Sessions behavior without an MDM profile update. The tenant host, organization API key, and CPU/memory limits remain MDM-owned. Advanced scan tuning (optional). Detect scans walk each user’s home directory to a bounded depth within a per-scan time budget, and keep CPU and memory use within configurable caps. The defaults fit most fleets — override them only if scans miss deeply-nested project configs (raise depth), run out of time on very large home directories (raise timeout), or you want a smaller footprint on constrained hosts (lower the CPU / memory caps). All are integers. Project depth and timeout are delivered by the Runlayer settings sync on macOS and Windows; native MDM values remain a legacy fallback. CPU and memory caps remain MDM-owned (<integer> on macOS, matching AIWATCH_* MSI properties on Windows). Omit them to keep the defaults. Values outside the range are clamped; non-integer or non-positive values are ignored. The CPU / memory caps are best-effort: the scan is throttled to stay within the configured CPU budget and aborts if it exceeds the memory ceiling.

Package and platform support

No. The signed .pkg / .msi is the same artifact for every customer — nothing tenant-specific is compiled into it. Your tenant host and organization API key are supplied separately through MDM configuration (the macOS Configuration Profile, or the Windows MSI properties / registry), not baked into the binary. That means the package can be verified once (signature, notarization) and reused unchanged across all of your configurations.
No. The package is fully self-contained: it installs a single aiwatch binary with everything it needs bundled. No separate runtime or CLI install is required. Use the package-based Test Device guide for one device without MDM; the uv tool install runlayer path documented on Detect and Enforce remains a per-user alternative.
macOS and Windows have feature parity — Detect, Monitor/Protect/Enforce, and Sessions are available on both through synced Runlayer settings (see Features). Linux is Detect only: deploy as native .deb / .rpm packages (cron-scheduled scans) or as a container image — see Linux (Detect only) or Container. The signed MDM package ships for Apple Silicon Macs and 64-bit Windows. For Intel Macs or other architectures, use the cross-platform uv tool install runlayer CLI path, or contact your Runlayer account team. AI Watch runs on managed-device hardware; it is not installed inside the AI assistant’s containers.
Outbound HTTPS (443) to your Runlayer tenant host only — the same hostname configured in your MDM profile (for example runlayer.dev.company.com or *.runlayer.com). Scans, hook decisions, session events, and update checks on every supported platform all use that one endpoint, and no inbound ports are opened. If your Runlayer instance is self-hosted (including air-gapped networks), AI Watch only needs to reach that internal tenant host — no public-internet egress is required. Behind a TLS-inspection proxy, exempt the tenant hostname or install the corporate root CA in the OS trust store — see Troubleshooting.

Package configuration

Use Settings → MDM configuration to create an AI Watch deployment. The wizard picks your MDM, mints a single organization API key, and puts the tenant host and key into the downloaded artifacts; behavior settings live in Runlayer and reach devices through the settings sync. Every artifact — including the signed installer, at the version selected by your Client Updates policy — downloads directly from the wizard; re-open it later via View deployment setup on the deployment card. After deployment, select Manage settings on the deployment card to change Mode, Sessions, DetectProcesses, DetectContainers, ProjectDepth, or ProjectTimeout. macOS and Windows packages fetch these settings on their hourly settings sync, typically within an hour. If a fetch fails or returns invalid data, AI Watch keeps the last valid snapshot; without one it uses any explicit native policy fallback. Generated macOS profiles and Windows MSI commands carry no capability values, so bootstrap-only devices remain Monitor + Sessions off. The tenant host, organization API key, identity overrides, optional GrokHome, and CPU/memory limits remain MDM-owned. Re-deploy the profile or MSI/registry values to change them. GrokHome is required only when Grok CLI uses a custom directory; set it to a path within the console user’s home because root/SYSTEM jobs cannot read shell-defined environment variables. On macOS devices running AI Watch 0.29.6 or newer, browser installation, browser mode, and browser Sessions are managed from Runlayer under Manage settings → Browser extension. Enabling or disabling Chrome and Firefox does not require an MDM profile change or package reinstall. See Browser extension for the rollout steps, supported pages, and mode behavior. The managed updater installs the version selected by your Client Updates policy on its own schedule; to hold a version, pin it in Client Updates.

Enable Chrome and Firefox on an existing macOS deployment

  1. Under Settings → AI Watch, confirm the target devices run AI Watch 0.29.6 or newer. Use Settings → Client updates to move them to a supported version when needed.
  2. Under Configurations, select Manage settings for the deployment and open the Browser extension tab.
  3. Turn on Install browser extension, configure browser mode and Collect browser session data as needed, then select Save changes.
  4. Under Settings → Agent session monitoring, enable Full session scanning APIs and the Browser extension Hook client.
  5. Allow up to one hour for the macOS bootstrap daemon to reconcile the managed Chrome and Firefox policies, then restart the browsers.
Do not edit or re-deploy the tenant’s existing com.runlayer.aiwatch.mobileconfig for this change. The package uses the profile’s existing tenant host and organization API key to fetch the browser setting. Firefox does not require a user account. Follow Verify a browser deployment to confirm installation, enforcement, and Sessions.

macOS artifacts

The macOS package is a signed and notarized .pkg plus a single MDM Configuration Profile, both downloaded from the Settings → MDM configuration wizard (the profile comes pre-filled): Deploy the Configuration Profile before the .pkg so tenant config and TCC grants are present before the first scan tick. If you need multiple tenant configurations (different host or key), deploy one copy of com.runlayer.aiwatch.mobileconfig per group. The .pkg is universal; the PPPC and Login Items payloads are identical across copies, only the tenant-config values differ. Fleets deployed before the profile consolidation ran three separate profiles (com.runlayer.aiwatch.config.mobileconfig, com.runlayer.aiwatch.pppc.mobileconfig, com.runlayer.aiwatch.loginitems.mobileconfig). The merged profile does not supersede them automatically — remove the legacy profiles when scoping the merged one.

Jamf Pro

Upload Configuration Profiles and the .pkg via Policy.

Workspace ONE

Use Custom Attributes for tenant host and organization API key.

Iru / Kandji

Edit the tenant profile and deploy through Blueprints.

SimpleMDM

Upload profiles and package through device groups.

Mosyle

Deploy profiles and package through Mosyle device groups.

Intune (macOS)

Upload Configuration Profiles and the .pkg as a macOS app.

Other macOS MDM

Use any MDM with Custom App and Custom Profile support.
Migrating from the legacy script-based macOS Detect rollout? Run Legacy macOS Detect Cleanup before rolling out the .pkg.

Windows artifacts

The Windows package is a signed MSI wrapped for Intune, downloaded from the Settings → MDM configuration wizard. The MSI writes tenant config to HKLM\Software\Runlayer\AIWatch and registers device-local Scheduled Tasks that run scans (all real user profiles) and assert hooks (SYSTEM) on a recurring schedule — no Intune Remediations required.

Intune

Deploy the MSI with host and organization API key — scans and hooks schedule themselves on the device, and Mode and Sessions are managed in Runlayer.

Linux artifacts (Detect only)

The Linux deployment bundle (aiwatch-<version>-linux-x86_64.zip) contains a .deb and an .rpm (both named runlayer-aiwatch), SHA256SUMS, and the config templates. The package installs the aiwatch binary plus a cron entry that scans all users every 15 minutes. Linux is Detect-only — the device’s Protect, Enforce, and Sessions features show Disabled in the dashboard by design.

Linux

Install the .deb / .rpm via configuration management and configure the two files under /etc/runlayer/aiwatch/.

SaltStack

Roll out and continuously assert the Detect-only scanner from a Salt master — package from salt://, config from pillar.

Container

Run the scanner as a container over bind-mounted host homes — standalone docker run or a Kubernetes DaemonSet / CronJob.

Manual and custom workflows

For individual test devices and custom workflows:

Test Device

Install AI Watch on one macOS, Windows, or Linux device without an MDM.

Run Detect manually

Install the Runlayer CLI and run runlayer scan.

Install Enforce manually

Install client hooks with runlayer setup hooks.

User and Identity Mapping

Understand how device usernames map to Runlayer users.

Remove AI Watch

Remove package-based and legacy script-based deployments.
For custom macOS or Windows fleet integrations outside a supported MDM, use the same package configuration model: install AI Watch once, provide host and organization API key, leave Detect running, and manage Mode, Sessions, and optional process and container & WSL discovery from Settings → AI Watch → Manage settings.

Detect

What scans read and how discovery works

Endpoint modes

Monitor, Protect, and Enforce configuration

FAQ

Pre-deployment, platform, and network questions

Troubleshooting

Common issues and solutions