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 Runlayer 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 scan stays within the signed-in user’s home directory, skips common high-noise folders, and limits project depth, scan time, CPU, and memory use. For managed devices, adjust these limits in the deployment settings; manual scans provide equivalent CLI options. 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 — and can only submit scan, hook, and Sessions data and download managed AI Watch updates for your tenant. It cannot read data from your tenant, change organization settings or policies, or act as a user; other API routes reject it. 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 and download the managed AI Watch update for your tenant, but it cannot read data from your tenant, change organization settings or policies, or act as a user; other API routes reject it. 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). In Runlayer it is stored only as a one-way 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 bootstrap Configuration Profile (macOS) or MSI properties (Windows) through Jamf Pro, Intune, Kandji, SimpleMDM, Mosyle, Workspace ONE, or the generic “Other MDM” flow. The package starts with no hooks; its recurring reconcile fetches Runlayer settings, installs the selected hooks for supported clients, and re-asserts them idempotently. 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? below.
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.
Deployment guides cover Jamf Pro, Intune, Iru/Kandji, JumpCloud, SimpleMDM, Mosyle, Workspace ONE, and a generic “Other MDM” path for macOS tools that support custom apps and custom configuration profiles. For an MDM without its own guide (such as Addigy), use the Other MDM flow, or contact your Runlayer account team for a validated 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 — no network shim, packet capture, or system proxy. 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 does not sit in the path of unrelated traffic. See Connecting AI Clients.
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. That happens automatically when the root CA is installed in the OS trust store; 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 macOS and Windows, change Mode, Sessions, process/container discovery, project depth, or project timeout from Settings → AI Watch → Manage settings. Connected devices fetch the complete settings snapshot on their settings sync, which runs every 15 minutes, with no MDM policy update.On macOS and Windows, use Manage settings → Browser extension to install or remove the managed Chrome, Edge, and Firefox extensions and configure their mode and Sessions behavior. This does not require editing or re-deploying the MDM profile. See Browser extension for the AI Watch version each browser and platform requires. Host, organization API key, identity overrides, 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 and Windows devices running a supported AI Watch version, admins can force-install the Runlayer extension in Chrome, Edge, 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 to sign in to the browser.
Detect covers the clients listed in the Detect support matrix. Some clients there are presence-only: Detect inventories them from installation signals, and artifact scanning (MCP configuration, skills, plugins) varies by client — see the Detect page for what each client supports. Because the installation signal is OS-specific, a presence-only client may be inventoried on one platform but not another. Enforce covers the smaller hook-client matrix listed in Enforce. Sessions covers enabled hook clients, the managed Chrome, Edge, 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. A fresh managed install starts in Monitor with Sessions off and no hooks. After Sessions is enabled in Runlayer settings, Monitor hooks forward Sessions and event telemetry without applying endpoint decisions. 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.
On a managed device, hook tampering doesn’t stick and doesn’t go unnoticed:
  • Managed hooks come back automatically. The scheduled MDM reconcile job re-writes the expected hook config on its next tick (every 15 minutes), without a package reinstall. See How Enforce works.
  • The gap is visible. A device whose hooks were tampered with reports an Error or Drifted badge for Enforce/Sessions in Shadow AI → Devices. See Shadow AI overview.
  • Detect still finds the shadow AI. Discovery runs as a scheduled root/SYSTEM scan, completely independent of user-level hooks — a user who disables their hooks but still has a shadow MCP configured surfaces on the Shadow AI → Details tab on the next scan. See What the scan reads.
  • Standard users cannot remove the scheduled jobs. On Windows, the Runlayer scheduled tasks are locked to SYSTEM/Administrators. See Tamper resistance.
What tampering does remove is that client’s real-time telemetry until the next reconcile — Sessions and hook-based blocking fire inside the AI client. 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 (last-seen stops advancing) 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