Skip to main content
Answers to the questions security, IT, and procurement teams ask most often when evaluating or rolling out AI Watch. Each answer links to the page with the full detail.

​
Privacy and data handling

Detect is a metadata-first configuration scanner. For MCP servers it submits parsed configuration metadata — the server command / args / url, the client, and any project path — not your raw config files. For skills and plugins it submits metadata plus bounded artifact text (capped at 1 MB per file and 5 MB per artifact) so the backend can risk-classify the artifact. See What the scan reads.
Yes. The crawl is confined to the signed-in user’s home directory and skips high-noise and cache directories (node_modules, .git, .venv, caches, Library/Application Support, AppData, and more). Project-level discovery is bounded by --project-depth (default 7) and --project-timeout (default 60 seconds), and --no-projects skips project-level scanning entirely. See What the scan reads.
Scope is defined by the home-directory boundary, not by a drive-type filter. Paths outside the home directory are never traversed, so a network share or removable drive mounted elsewhere on the system is not crawled — but there is no separate exclusion that skips a drive mounted under the home directory. See What the scan reads.
MCP discoveries are metadata only. Skill and plugin discoveries include bounded file text (≤1 MB per file, ≤5 MB per artifact) needed for risk classification, deduplicated by fingerprint so the same artifact’s text is not re-uploaded from every device. See What the scan reads.

​
Organization API key

It is deliberately down-scoped. The key carries a single role — Shadow AI Scan (mcp_watch_scan) — and is accepted on AI Watch submission endpoints plus the narrow self-update target and installer-download endpoints. It cannot read tenant telemetry, organization settings, rollout policy, or release history; other API routes reject it. It has tenant-only identity (it is not tied to a user), cannot impersonate a user, and is blocked from policy-based access control. See Deploy AI Watch and User and Identity Mapping.
Limited to AI Watch ingestion and self-update for your tenant. A leaked key can submit scan and telemetry data, resolve the backend-selected binary target, and download its installer, but it cannot read tenant telemetry or organization settings, act as a user, or reach unrelated API routes. Rotate it from Settings → MDM Configuration — regenerating the configuration mints a new key — and re-push the profile/MSI; the old key stops working once revoked (401). See Troubleshooting → Authentication.
On the device it lives in MDM-managed configuration (OrgApiKey in macOS managed preferences, or the OrgApiKey registry value under HKLM\Software\Runlayer\AIWatch on Windows, written by the MSI’s AIWATCH_ORG_API_KEY install property). On the Runlayer backend it is stored only as an HMAC-SHA256 hash — the plaintext is shown once at creation and cannot be retrieved later. If it is lost, regenerate the configuration to mint a new one. See Troubleshooting → Authentication.
The key authenticates the tenant; user attribution comes from each device’s scan context (OS username, device name), which Runlayer resolves to a user. See User and Identity Mapping.

​
Deployment and platform

You need AI Watch on each managed laptop where you want endpoint discovery, hook-based enforcement, or full Sessions telemetry from local AI clients. Gateway-only traffic that already flows through Runlayer can still be governed by connector policies, ToolGuard, audit logs, and analytics without an endpoint agent on that device. Cloud telemetry imports such as Claude Cowork can also feed Sessions without laptop hooks, but they are source-specific and do not replace endpoint discovery.
No — the signed .pkg / .msi is identical for every customer. Your tenant host and organization API key are supplied through MDM configuration, not compiled into the binary. See Package and platform support.
No. The MDM package is self-contained — a single signed aiwatch binary with its runtime bundled, no Python or CLI prerequisite on managed devices. The uv tool install runlayer CLI is only for manual single-device testing. See Package and platform support.
Managed deployment ships for macOS (Apple Silicon / arm64), Windows (x64), and Linux (x86_64, Detect only — .deb / .rpm, see Linux). For Intel Macs or other architectures, use the CLI path or contact your account team. See Package and platform support.
The public deployment guides cover Jamf Pro, Intune, Iru/Kandji, SimpleMDM, Mosyle, Workspace ONE, and a generic “Other MDM” path for macOS tools that support custom apps and custom configuration profiles. Addigy is not named in the public docs today; use the Other MDM flow or ask your Runlayer team to confirm the exact deployment pattern.
Outbound HTTPS (443) to your Runlayer tenant host only — no inbound ports. Self-hosted (including air-gapped) instances only need to reach the internal tenant host. See Package and platform support.
Yes. Flipping Enforcement / Sessions (and other config) only requires re-pushing the profile or MSI properties — on macOS, bump the profile’s PayloadVersion so the MDM re-delivers it. The .pkg / .msi is reinstalled only to upgrade the AI Watch binary. See Package configuration.

​
Operation

Public docs focus AI Watch on supported desktop and CLI AI clients, MCP configurations, skills, plugins, and client hooks. They do not document a Chrome, Chromium, Edge, or enterprise-browser extension that blocks arbitrary personal web AI usage. For supported web chat sources, Runlayer can import sessions for monitor-only review when the provider exposes a compliance API; real-time blocking requires a supported client hook or gateway path.
Detect covers the clients listed in the Detect support matrix. Enforce covers the smaller hook-client matrix listed in Enforce. Sessions covers enabled hook clients, Runlayer Agents, the Hooks SDK, Claude Cowork OTLP, and supported web chat imports. Unsupported clients, disabled hook clients, and unmanaged web apps can sit outside Runlayer’s real-time visibility.
Yes. With Enforcement off (the default), hooks still forward Sessions and event telemetry whenever Sessions is enabled — you get full visibility without blocking. Blocking happens only when Enforcement=true. See Enforce → Monitoring-only rollout.
Risk levels are a heuristic triage signal from analyzing the skill’s instructions, not a malicious verdict, so legitimate skills can score High or Medium. Review the flagged instructions, bring sanctioned skills under management, and re-analyze to refresh the classification. Detect never blocks skills. See Troubleshooting → Interpreting Discovery Results.

Detect

What scans read and how discovery works

Deploy AI Watch

Package, platform, and configuration

Enforce

Blocking vs. monitoring-only

Troubleshooting

Auth, discovery, and package issues