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.
Only when Detect running processes is enabled; it is off by default. Detect reads process-table and local listening-socket metadata to correlate running AI clients, MCP servers, and agents with configuration. It does not read process memory or environment variables, capture packets, inspect network payloads, or proxy traffic. Readable command arguments are scrubbed and bounded before submission, the complete command line is retained only as a one-way hash, and the working directory is reduced to a scrubbed project-directory name. Agent sightings may also include a sanitized root path that redacts usernames, URL credentials, and secret-looking segments while preserving enough path shape for installation correlation. Raw command arguments and unredacted working directories are never submitted to Runlayer. See Runtime process discovery.
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. A cooperative in-process governor also caps the scan’s CPU and memory footprint (--cpu-cores / --max-cpu-percent / --memory-limit-mb, all also settable via MDM) — defaults are generous, tighten them on constrained hosts. 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 primary governance path does not depend on your Anthropic plan at all. Runlayer governs Claude Code, Claude Desktop, and other clients through client hooks deployed by AI Watch, authenticated by a single Runlayer organization API key carried in your MDM configuration. Because hooks fire inside the AI client (not through Anthropic’s org APIs), they work the same on any Claude plan — individual, Pro, Team, or Enterprise — and on any harness/model. See How Enforce works and Deploy AI Watch.Only two optional provider-side integrations depend on the Anthropic plan tier, and neither is required to get visibility, policy enforcement, or Sessions telemetry from local clients:
Yes — that is the intended deployment model, and no end user has to touch a config file. There are two central rollout paths:
  • MDM (recommended for managed fleets). Push the AI Watch .pkg / .msi and its Configuration Profile (macOS) or MSI properties (Windows) through Jamf Pro, Intune, Kandji, SimpleMDM, Mosyle, Workspace ONE, or the generic “Other MDM” flow. The package installs hooks for the supported clients (Claude Code, Cursor, VS Code, Copilot CLI, Codex, and more) idempotently and re-asserts them on each check-in. See Deploy AI Watch.
  • Auto Sync / org install (for connectors and Runlayer Plugin). Admins enable Auto Sync on connectors or the plugin, and runlayer setup sync (which your MDM can schedule) writes the client config across detected clients. For Claude specifically you can also use the Anthropic org install. See Auto-Sync to Clients and Connecting AI Clients.
Synced hook and connector entries are re-applied on every run, so local edits or deletions are reverted on the next check-in — there is no “go to each Claude Code client and redirect it” step. See What if a developer disables or deletes their hooks? above.
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 packages or container image; see Linux or Container). 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.
No. AI Watch does not install an OS-level network proxy, VPN, or TLS-intercepting middlebox, and it does not change system proxy settings or re-route device traffic. It runs alongside your existing VPN, secure web gateway, or SASE agent without competing for the network path.AI Watch operates at the application layer, not the network layer:
  • Detect reads local AI-client configuration files and skill/plugin artifacts on disk — it does not observe network traffic at all. See What the scan reads.
  • Endpoint modes and Sessions use client hooks that fire inside the AI client on its pre-tool / post-tool events. Protect applies scanner decisions plus fail-open, allow-unless-denied MCP source governance. Enforce adds local-tool controls and fail-closed, deny-by-default MCP source governance, while managed MCP calls scan at the gateway. There is no network shim, packet capture, or system proxy involved. See How endpoint modes work.
  • The Runlayer gateway is an application-level MCP proxy: an AI client is explicitly pointed at a Runlayer MCP URL, the same way you would configure any MCP endpoint. It is not a transparent network proxy and does not sit in the path of unrelated traffic. See Connecting AI Clients.
Because none of these components operate at the network layer, they do not collide with VPN/SASE routing, split-tunnel rules, or OS proxy configuration. Zscaler, Netskope, Cloudflare WARP, Palo Alto Prisma, and similar tools continue to handle traffic routing exactly as before.The one network-layer interaction to plan for is TLS inspection. If your VPN/SASE terminates and re-signs TLS, the aiwatch binary and the runlayer CLI must trust the corporate root CA used by the inspection appliance. This is honored automatically through the OS trust store (macOS Keychain, Windows certificate stores, Linux CA bundle) when the root is installed system-wide; if it is not, use the --ca-bundle / RUNLAYER_CA_BUNDLE / SSL_CERT_FILE / REQUESTS_CA_BUNDLE overrides described in Troubleshooting (see also the TLS-inspected-network note in MCP Troubleshooting).Reaching MCP servers on a private network (e.g. internal servers only accessible behind your VPN or Cloudflare WARP) is a separate connectivity topic — it is about where the Runlayer platform and its connectors sit relative to the private network, not about AI Watch on the endpoint. See Networking and Deployment overview.
Yes. On current macOS and Windows packages, change Mode, Sessions, process/container discovery, project depth, or project timeout from Settings → AI Watch → Manage settings. Connected devices fetch the complete settings snapshot during the privileged hook reconcile, typically within an hour, with no MDM policy update.On macOS with AI Watch 0.29.6 or newer, use Manage settings → Browser extension to install or remove the managed Chrome and Firefox extensions and configure their mode and Sessions behavior. This does not require editing or re-deploying the MDM profile. Host, organization API key, identity overrides, AutoUpdate, and CPU/memory limits remain MDM-owned; re-deploy the profile or MSI/registry values to change those. No package reinstall is required. See Package configuration.

​
Operation

Yes, for supported AI web chats. On managed macOS devices running AI Watch 0.29.6 or newer, admins can force-install the Runlayer extension in Chrome and Firefox from Settings → AI Watch → Manage settings → Browser extension. Precise provider adapters support prompt monitoring, Sessions, masking, and blocking; observation-only pages support monitoring and Sessions but cannot rewrite or stop a provider request. Unknown pages are not monitored. Users do not need a Chrome or Firefox account.
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, the managed Chrome and Firefox extension on supported web pages, Runlayer Agents, the Hooks SDK, Claude Cowork OTLP, and supported web chat imports. Unsupported clients, disabled hook clients, unknown browser pages, and unmanaged web apps can sit outside Runlayer’s real-time visibility.
Endpoint discovery requires the AI Watch agent on the device. Detect runs from the aiwatch binary (or the runlayer CLI for manual scans) that you deploy through MDM — it reads AI-client configuration, MCP servers, skills, plugins, and agent definitions on that device’s disk. On a device where you cannot install the agent (a personal laptop, an unmanaged contractor machine, a BYOD phone), there is no endpoint scan, so that device’s local AI usage does not appear in Shadow AI → Devices.Runlayer does not discover Shadow AI by watching the network. AI Watch is not a network proxy, VPN, or TLS-intercepting middlebox, and Detect does not capture packets or inspect network payloads — so there is no passive, agentless “see every AI request on the wire” mode for devices you don’t manage. See Does AI Watch act as a network proxy? and What the scan reads.What you can still govern or observe without an endpoint agent on the device:
  • Gateway-proxied MCP traffic. Any client pointed at a Runlayer MCP URL — including on an unmanaged device — is still subject to connector policies, ToolGuard scanning, audit logs, and analytics. This governs traffic that flows through Runlayer, but it cannot reveal MCP servers or AI clients the user configured entirely outside Runlayer. See Connecting AI Clients and Policies.
  • Cloud/web chat compliance imports. Where a provider exposes a compliance API (e.g. the Anthropic Compliance API for Claude web/desktop), Runlayer can import those sessions for monitor-only review regardless of the endpoint. These are source-specific and do not replace endpoint discovery. See Sessions → web chat and compliance imports.
Practical guidance: to bring an unmanaged population into scope, either enroll the devices in MDM and push AI Watch, or route their AI clients through the Runlayer gateway so their managed MCP traffic is governed even though the endpoint itself is not scanned. Truly unmanaged, non-gateway AI usage on a device you cannot touch is outside Runlayer’s discovery surface — a boundary shared by any endpoint-agent-based tool. See Do I need AI Watch on every laptop? and Deploy AI Watch.
Yes. Monitor is the default mode: hooks still forward Sessions and event telemetry whenever Sessions is enabled, but endpoint decisions are not applied. Protect applies scanner Block/Mask and blocks configured MCP sources that match its denylist; unmatched sources and source-check failures remain allowed. Enforce applies local scanner/policy decisions and fail-closed, deny-by-default MCP-source governance; managed MCP content is scanned at the gateway. See Endpoint modes → Monitor rollout.
Disabling or deleting a client’s hooks removes only that client’s real-time telemetry — Sessions and Enforce fire inside the AI client, so a user who removes their own hook entries stops live session capture and hook-based blocking for that client. It does not hide the underlying shadow AI, and on managed devices it does not stick:
  • Detect still finds it. Endpoint discovery runs as a scheduled root/SYSTEM scan that reads AI-client config, MCP servers, skills, and plugins on disk — completely independent of user-level hooks. On macOS it is a launchd job, on Windows the AIWatchScan SYSTEM task, and on Linux a root cron entry (every 15 min). A user who disables their hooks but still has a shadow MCP configured will surface in Shadow AI → Devices/Discovery on the next scan. See What the scan reads.
  • Managed hooks re-assert themselves. With MDM deployment, the aiwatch setup hooks install --mdm reconcile job (launchd / the AIWatchHooks SYSTEM task / the recurring script) re-writes the expected hook config on its next tick — idempotently — so removed entries come back automatically without a package reinstall. See Deploy AI Watch and How Enforce works.
  • Drift is visible. A device whose hooks were tampered with reports an Error or Drifted badge for Enforce/Sessions in Shadow AI → Devices, so the gap is observable rather than silent. See Shadow AI overview.
  • Windows adds tamper resistance. The Runlayer Task Scheduler folder and tasks are locked to SYSTEM/Administrators (read + execute only for standard users), so a standard user cannot modify or delete them. See Tamper resistance.
A local administrator can still uninstall the agent entirely — the same trust boundary as any managed app. That removal is itself visible as the device going stale (backend last-seen) in the dashboard.
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

Endpoint modes

Monitor, Protect, and Enforce behavior

Troubleshooting

Auth, discovery, and package issues