Detect

​

How It Works

1. Client and Artifact Discovery: The Runlayer CLI checks known installation signals, MCP configuration files, skill artifacts, client-native agent definitions, and installed plugin artifacts
2. Runtime Process Discovery (optional): Detect polls the process table and listening sockets, then correlates running AI clients, MCP servers, and agents with configured artifacts
3. Secure Submission: Client presence, configuration, skill, agent-definition, plugin, and redacted runtime metadata is securely submitted to Runlayer
4. Classification: Runlayer classifies each discovery:
   • AI Clients are classified as:
     • Managed: Approved through your organization’s client allowlist
     • Shadow: Detected but not approved (flagged for review)
     • Risk: Client presence uses a Low baseline risk; review its device, user, version, and detection evidence for context
   • MCP Servers are classified as:
     • Managed: Running through Runlayer (approved and monitored)
     • Shadow: Configured outside Runlayer (flagged for review)
   • Skills are classified as:
     • Managed: Published and managed through Runlayer
     • Shadow: Installed outside organizational control (flagged for review)
     • Outdated: Previously managed but now out of date
   • Skill Risk Levels: Each discovered skill is assigned a risk level:
     • High: Skill contains risky instructions (prompt injection, data exfiltration patterns)
     • Medium: Skill has potentially risky characteristics that warrant review
     • Low: Skill has minor concerns but is unlikely to pose a threat
     • Minimal: Skill appears safe with no concerning patterns detected
5. Review: Newly discovered shadow clients, servers, skills, agents, and plugins are flagged for review on the Shadow AI page

​

Security Team Workflow

​

AI Client Detection

• Installed (app, cli, registry, npm_global, pip_global): an application bundle, executable, operating-system installation record, or validated allowlisted npm/Python package
• Configuration (config): an exact known client configuration file
• Weak trace (trace): a known parent or state directory exists, but no exact configuration file was found. Runlayer-created hook files are excluded so installing AI Watch hooks cannot create client presence by itself.

• macOS: app bundles in /Applications or ~/Applications
• Windows: uninstall-registry entries, per-user Microsoft Store/MSIX package registrations, or known installation paths
• Linux: binaries in known executable paths or desktop files
• All platforms: known configuration or state paths
• VS Code extensions: per-user installs plus built-in extensions from standard Visual Studio Code and Insiders installations and remote-server bundles. This includes GitHub Copilot as shipped with VS Code 1.116 and later; first-party VS Code platform extensions are excluded.
• Global npm installs: known client packages installed globally through npm — including under custom or renamed npm prefixes and node_modules directories found by bounded project and hidden-space sweeps. Detect reads package metadata only — it never runs npm, Node, package scripts, or shims.
• Python tool installs: known client packages installed as Python tools, identified by exact distribution metadata in active, pipx, uv tool, user-site, conventional system-site, and sweep-discovered virtual environments. Renaming the console script or relocating the environment does not change this identity. Detect never imports packages or runs Python tools.
• Containers: client artifacts discovered inside running Docker, Podman, nerdctl, or k3s containers. Known MCP images remain identifiable even if they are renamed locally.
• Artifact evidence: a discovered MCP server, skill, agent definition, plugin, or extension also confirms that its client is present

​

Capabilities

​

Runtime process discovery

• Running: a configured artifact was observed running during the selected date range
• Configured only: configuration exists, but no running process was observed during the selected date range
• Runtime only: a high-confidence running process has no matching configuration

​

Supported Clients

​

macOS

​

Windows

​

Linux

​

Presence-only clients

​

AI browsers

​

What — means

• No skills convention (Gemini CLI, Antigravity): these clients do not define a SKILL.md directory layout. MCP servers and, where applicable, plugins/extensions are still scanned.
• No plugin marketplace (Claude Desktop, Goose, Zed, Cline, Antigravity, Warp, Pi Coding Agent, Kilo Code): these clients do not have a separate plugin/extension format that bundles MCP servers, so there is no plugin layer beyond the MCP server config itself. For Goose and Zed, extensions are the MCP server and are surfaced through the MCP Servers column. Pi packages can ship extensions and skills but cannot declare MCP servers. Kilo Code marketplace entries are written straight into the MCP config files Detect already reads, so they surface through the MCP Servers column.
• Gemini CLI stopped serving free, Google AI Pro, and Google AI Ultra users on June 18, 2026, when Google replaced it with the Antigravity CLI. Gemini Code Assist Standard and Enterprise licenses and paid API keys still work, so a Gemini CLI finding today is either an enterprise-licensed install or a stale one. Antigravity is reported as its own client.
• Antigravity MCP servers are read from the current global file (~/.gemini/config/mcp_config.json), the pre-2.0 file (~/.gemini/antigravity/mcp_config.json), and the workspace file (.agents/mcp_config.json). Antigravity uses serverUrl for remote servers; Detect reports it like any other remote endpoint.
• Grok CLI (Grok Build) MCP servers are read from ~/.grok/config.toml, the enterprise managed_config.toml (user home or /etc/grok), and the project .grok/config.toml. Grok’s skills and plugin layers are not scanned yet.
• Personal agents (Nanobot, ZeroClaw, PicoClaw, NanoClaw, NemoClaw, OpenFang, IronClaw, NullClaw, QwenPaw, Paperclip, LobsterAI, ClawX): the always-on “claw” family bridges Telegram, WhatsApp, Slack, iMessage and WeChat to a shell and MCP tools, and several ship with the shell on and sandboxing off. Detect reports each from its state directory, config or service file, binary or app bundle. Nanobot, PicoClaw and NullClaw MCP servers are read from their JSON configs; the others keep MCP in layouts not yet verified. LobsterAI and ClawX embed OpenClaw: ClawX shares ~/.openclaw, so its servers surface under OpenClaw and only the ClawX app bundle names it, while LobsterAI keeps its runtime under its own application-support folder. Gateway ports are not used as signals because the family shares and reuses them.
• Vendor coding agents (Mistral Vibe, Rovo Dev CLI, Cortex Code, Command Code, Letta Code, Blackbox CLI, pool, Rowboat, Eigent, Verdent, Cline Desktop, CodeRabbit CLI, Jules Tools, Docker Agent, Qodo CLI): agents that vendors ship into seats customers already pay for. Mistral Vibe keeps servers as a TOML array of tables in ~/.vibe/config.toml and the project .vibe/config.toml; Rovo Dev CLI reads ~/.rovodev/mcp.json; Cortex Code reads ~/.snowflake/cortex/mcp.json; Command Code reads ~/.commandcode/mcp.json plus the project .mcp.json; Letta Code keeps per-agent server lists in ~/.letta/settings.json; Blackbox CLI reads settings.json at user, project and system scope; pool reads ~/.config/poolside/settings.yaml and the project .poolside/settings*.yaml; Rowboat, Eigent and Verdent keep mcp.json under their own home directories. Entries a client marks disabled are not inventoried. Cline Desktop shares the Cline CLI’s settings file, so its servers surface under Cline CLI. CodeRabbit CLI, Jules Tools and the current Qodo CLI have no on-device MCP configuration. Docker Agent declares MCP servers inside agent YAML files, which Detect does not read yet, and it is present on every Docker Desktop 4.63+ install.
• Vendor coding agents, wave 2 (CodeBuddy Code, iFlow CLI, Comate Zulu, MiniMax Code, MiMo Code, ZCode, DeepCode CLI, Kimi Desktop, Chatbox, DeepSeek Harness, NextChat): Claude-Code-shaped CLIs and desktop agents whose default endpoints are in China. CodeBuddy Code reads ~/.codebuddy/.mcp.json (plus the deprecated mcp.json and legacy ~/.codebuddy.json); iFlow CLI reads mcpServers from settings.json at user, project and system scope; Comate Zulu reads ~/.comate/mcp.json and the project .comate/mcp(.local).json, which the Comate IDE plugins share; MiniMax Code reads ~/.minimax/mcp.json; MiMo Code keeps OpenCode’s mcp key in ~/.config/mimocode/mimocode.jsonc; ZCode reads mcp.servers from ~/.zcode/cli/config.json and the workspace .zcode/config.json; DeepCode CLI reads ~/.deepcode/settings.json; Kimi Desktop reads the mcp.json of its embedded Kimi Code runtime under the app’s data directory; Chatbox reads settings.mcp.servers from its config.json. ZCode and Chatbox entries switched off in their own config are not inventoried; the standard-shaped clients report switched-off servers like every other standard client. CodeBuddy Code and MiniMax Code share Claude Code’s project .mcp.json, so those servers are attributed to them only when the client is installed. DeepSeek Harness keeps MCP servers as plugin entries in YAML cordis.patch.yml files, which Detect does not read yet, and NextChat’s desktop build has no on-device MCP configuration.
• Open-source coding harnesses and forks (Claw Code, Claurst, Free Code, Kode, jcode, Codebuff, Every Code, oh-my-pi, Oh My OpenAgent, ForgeCode, Nanocoder, Neovate Code, Groq Code CLI, Open Interpreter, Codewhale, Reasonix, Deep Agents Code, Prime Agent, gptme, Ante, Orca (echoVic), mini-SWE-agent): community agents, several of them forks or re-wraps of Claude Code, Codex and Pi that reuse the host’s configuration. Detect applies one attribution rule to all of them: the host keeps every server and skill in the files it owns, and the fork is reported only from its own binary, package or state directory. Free Code, which reads and writes only Claude Code’s files, is therefore presence-only; Kode, jcode, oh-my-pi, Oh My OpenAgent, Every Code, Reasonix, ForgeCode, Nanocoder and Deep Agents Code have their own MCP files inventoried while the Claude Code, Codex, OpenCode, Cursor, Windsurf and VS Code files they also read stay with those clients, and the shared project .mcp.json is reported under Claude Code only. Claw Code reads mcpServers from ~/.claw.json, ~/.claw/settings.json and the project .claw.json and .claw/settings*.json; Claurst reads the config.mcp_servers array in settings.json under ~/.config/claurst (or a pre-existing ~/.claurst) and the project .claurst/settings.json(c); Kode reads ~/.kode.json and the project .mcprc; jcode reads ~/.jcode/mcp.json and the project .jcode/mcp.json; Codebuff reads ~/.agents/mcp.json and the project .agents/mcp.json; Every Code and Open Interpreter read Codex-shaped config.toml files under ~/.code and ~/.openinterpreter; oh-my-pi reads ~/.omp/agent/mcp.json and the project .omp/mcp.json; Oh My OpenAgent reads ~/.omo/agent/mcp.json and the project .omo/mcp.json; ForgeCode reads ~/.forge/.mcp.json; Nanocoder reads .mcp.json under its config directory; Neovate Code reads ~/.neovate/config.json and the project .neovate/config*.json; Codewhale reads ~/.codewhale/mcp.json (legacy ~/.deepseek/mcp.json) and the project .codewhale/mcp.json; Reasonix reads [[plugins]] tables in ~/.reasonix/config.toml; Deep Agents Code reads ~/.deepagents/.mcp.json and the project .deepagents/.mcp.json; Prime Agent reads ~/.prime/agent/settings.json and the project .prime/agent/settings.json; gptme reads [[mcp.servers]] tables in its config.toml; Ante reads ~/.ante/settings.json; Orca (echoVic, not Stably’s Orca) reads [[mcp_servers]] tables in ~/.orca/config.toml. jcode, oh-my-pi, Oh My OpenAgent, Nanocoder, Prime Agent, gptme and Orca drop servers switched off in their own config; the other standard-shaped clients report switched-off servers like every other standard client. The skills directories these harnesses keep are not scanned yet. Free Code, Groq Code CLI and mini-SWE-agent have no on-device MCP configuration to read.
• Known plugin gaps (Kimi Code, Devin CLI): Detect scans these clients’ MCP configuration and skills, but not their plugins or extensions.
• Warp MCP servers are discovered from both Warp’s configuration file and servers added through Warp’s in-app gallery. Both feed the MCP Servers column; a server found through more than one source is counted once.
• Kilo Code MCP servers are scanned from every config location Kilo reads at runtime — the current global (~/.config/kilo/) and project (kilo.json / kilo.jsonc / .kilo/) files, plus the older VS Code extension-store settings file, which Kilo still loads. All feed the MCP Servers column.
• Pi Coding Agent has no built-in MCP support. Its mcp.json files are read by the community pi-mcp-adapter extension, so they only exist once a user installs it. Detect scans them wherever they appear.
• Devin CLI and Devin Desktop are two surfaces. The CLI keeps servers in ~/.config/devin/mcp_config.json. Devin Desktop (the renamed Windsurf) hosts two agents: Cascade, whose servers live in ~/.codeium/windsurf/mcp_config.json and are reported under Windsurf, and Devin Local, which shares the CLI’s harness and configuration and is reported under Devin CLI. Installing Devin Desktop alone is therefore enough for a device to show Devin CLI as present, and one device can legitimately show both rows.

​

Shadow Skills Discovery

​

Disguised skills in caches

runlayer scan --org-api-key detect --host https://your-instance.runlayer.com --detect-disguised-skills

​

Skill Classification

​

Risk Levels

​

Shadow Plugins Discovery

​

Agent Discovery

• Custom agent — a client-native agent definition file. Detect inventories these for Claude Code, Cursor, Codex, Gemini CLI, GitHub Copilot, OpenCode, and Goose. The same definition found in several places appears once, with each device, path, client, and container location visible as a separate sighting. Definition contents are parsed locally; Runlayer receives only bounded metadata, never the raw file.
• Agent — an agent framework observed on the device, for example through runtime process discovery. Use the Type filter on the Details tab to review these alongside clients, MCP servers, skills, and plugins.

​

Run Detect

​

Manual installation

curl -LsSf https://astral.sh/uv/install.sh | sh
uv tool install runlayer

powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
uv tool install runlayer

runlayer --help

runlayer login --host https://your-instance.runlayer.com

runlayer org-api-key add detect --host https://your-instance.runlayer.com

# With interactive login credentials
runlayer scan --host https://your-instance.runlayer.com

# With a stored organization API key
runlayer scan --org-api-key detect --host https://your-instance.runlayer.com

# Include running-process and listening-socket discovery (off by default)
runlayer scan --org-api-key detect --host https://your-instance.runlayer.com --detect-processes

# Include container/image inventory and Windows WSL discovery (off by default)
runlayer scan --org-api-key detect --host https://your-instance.runlayer.com --detect-containers

# Probe bounded hidden/cache spaces for disguised skills (off by default)
runlayer scan --org-api-key detect --host https://your-instance.runlayer.com --detect-disguised-skills

# Dry run - see what would be submitted without sending
runlayer scan --host https://your-instance.runlayer.com --dry-run

# Verbose output
runlayer scan --host https://your-instance.runlayer.com --verbose

​

Custom scan scheduling

uv tool install runlayer

crontab -e

# Run daily at 9 AM
0 9 * * * runlayer scan --org-api-key detect --host https://your-instance.runlayer.com

$action = New-ScheduledTaskAction -Execute "runlayer" -Argument "scan --org-api-key detect --host https://your-instance.runlayer.com"
$trigger = New-ScheduledTaskTrigger -Daily -At 9am
Register-ScheduledTask -TaskName "Detect Scan" -Action $action -Trigger $trigger

​

What the scan reads (and what it doesn’t)

• The crawl is confined to the signed-in user’s home directory ($HOME on macOS/Linux, %USERPROFILE% on Windows). It does not walk system directories or other users’ homes.
• Project-level discovery walks home to a bounded depth — default --project-depth 7, with a --project-timeout ceiling of 60 seconds. Pass --no-projects to skip project-level scanning entirely and only read the known global client config paths.
• The scan caps its own CPU and memory footprint. Defaults are generous, so a normal scan is unaffected; the caps are tunable per deployment — see the tuning table for the MDM keys.
• High-noise and cache directories are skipped: .git, venv / .venv, __pycache__, dist, build, target, vendor, Library/Caches, Library/Application Support, AppData, .Trash, tmp, .cache, .npm, .yarn, and plugin-install caches. Detect records bounded node_modules directory locations for npm package validation but does not descend into their dependency trees. The default-off disguised-skill phase is a narrow exception for its explicit allowlisted cache subtrees only.
• Symlinks are not followed out of the home tree. On Windows, the SYSTEM all-users scan additionally drops reparse points and verifies each hit’s real path stays inside the profile.
• Browser profiles are opened for their extension registry only: Chromium’s Secure Preferences and Preferences (extensions.settings), Firefox’s extensions.json, and a store-installed extension’s own locale file when its name is localized. History, cookies, sessions and site storage are never read, and a sideloaded extension’s directory is reported by path but not opened.
• Office add-in caches are read for manifests only: Detect looks at a file’s first bytes and reads it whole only when it is an add-in manifest, skips the WebView2 browser profile Office keeps under the Windows cache entirely, and never fetches or reads the add-in’s web content.

• Detect reads process-table and local listening-socket metadata for classification and correlation. It does not read process memory or environment variables, capture packets, inspect network payloads, or proxy traffic.
• Command arguments are scrubbed of credentials, secret-looking tokens, and usernames before submission, and bounded in length. The complete unredacted command line is retained only as a one-way hash used for correlation.
• The process working directory is reduced to its scrubbed final project-directory name. For agent correlation, Detect may also submit a sanitized agent root path that preserves path shape while redacting home-directory usernames, URL credentials, and secret-looking segments. Raw command arguments and unredacted working directories are never submitted to Runlayer.

• AI clients: the normalized client identifier, display name, version when available, detection methods, and matched configuration or state paths
• MCP servers: parsed configuration metadata only — the server command / args / url, the client name, and any project path where the config was found. Raw config files are not uploaded.
• Skills and plugins: metadata plus bounded artifact text so Runlayer can risk-classify the skill or plugin. Text collection is capped at 1 MB per file and 5 MB per artifact; oversized files are skipped. Artifacts are deduplicated by fingerprint — once an artifact’s fingerprint is already known, later devices submit only the per-device installation record, not the file text again.
• Browser extensions: extension id, name, version, store, install scope, enabled state, install and update times, and the profile or sideload path. No extension code or page data is uploaded.
• Office add-ins: manifest id, name, publisher, version, host application, store listing presence, install scope, and the cached manifest path. Manifest content is not uploaded.
• Agent definitions: parsed name and description, client, scope, redacted path, project path, and content hash. Raw definition content is not uploaded.
• Runtime processes (when enabled): process kind, redacted executable and arguments, correlation hashes, listening ports and bind scope, confidence and detection source, a scrubbed project-directory name, and for agents a sanitized root path when available

​

Viewing Results

1. Navigate to Shadow AI
2. Open the Details tab and use the Type filter to narrow to Clients, MCP servers, Skills, Plugins, Agents, or Custom agents. Each row identifies the artifact, user, and device. Open a row to review versions and detection evidence, or add a client to your organization’s allowlist.
3. The Overview tab shows discovery trends, including the shadow vs. managed breakdown over time
4. The Activity tab shows a filterable log of AI Watch activity, such as hook events and observed MCP tool calls
5. The Connectors tab shows the most common shadow servers, who runs them, and which MCP clients are in use
6. The Skills tab shows shadow skills by risk level, classification breakdown (Shadow, Managed, Outdated), and discovery trends over time
7. The Devices tab shows AI Watch fleet mode and health, Sessions health, OS versions, and tool versions across enrolled devices

​

User Attribution

​

Related Resources