> ## Documentation Index
> Fetch the complete documentation index at: https://docs.visiqlabs.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Discovery
> Discover every custom AI agent, MCP server, AI framework, and tool in your environment — plus local models, coding agents, and shadow AI — before you decide what to govern.
Discovery is evolving — the sensor and findings model are still changing, and surfaces may change between releases.
You can't govern what you can't see. Discovery answers the first question of any AI governance program — *what agentic AI is actually running in my environment?* — with a lightweight endpoint sensor that scans each host and reports what it finds to your Discover dashboard.
***
## What the sensor finds
Each scan runs seven scanners and emits one structured report:
| Scanner | What it detects |
| --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Agent frameworks** | npm and pip installs classified against a curated agentic taxonomy — orchestrators (LangGraph, CrewAI, AutoGen, Haystack, DSPy, smolagents), agent SDKs (OpenAI Agents SDK, Mastra, Pydantic AI, Claude Agent SDK, LlamaIndex Agents), agent runtimes, memory backends, and tool routers. |
| **MCP servers** | Servers declared in client configs (Claude Desktop, Cursor, Windsurf, VS Code, Zed) and visible in the process list, with their tool surface read by static introspection. |
| **Local model runtimes** | The Ollama daemon and binary, plus HTTP probes for LM Studio, vLLM, llama.cpp, GPT4All, and text-generation-webui. |
| **Coding & CLI agents** | Claude Code, Cursor, Windsurf, Aider, and OpenClaw installed on the host. |
| **Shadow AI** | Stray provider API keys in environment files (OpenAI, Anthropic, Google, Groq, Hugging Face), AI browser extensions, and AI IDE extensions and plugins. |
| **Data-store reachability** | Which vector stores (Chroma, Pinecone, Weaviate, Qdrant, Milvus, LanceDB, FAISS), SQL and NoSQL databases, caches, and object stores the host's code can reach — from SDK dependencies, config files, and connection-string environment variables. |
| **Code projects** | Which individual code projects on the host build agents, and which of those already have the VisIQ harness installed — so governance coverage is measured per project, not just per machine. This is the one scanner that looks inside developer directories; see [Code-project scanning](#code-project-scanning) below for exactly what it reads and reports. |
The framework taxonomy separates signal from noise: a bare LLM SDK or a local model runtime only counts as agentic when it's linked to a genuine agent anchor on the same host, so a plain RAG dependency doesn't light up your fleet as autonomous agents.
Static scanning of model artifacts and pickle opcodes is **not** part of any scan. It is deferred roadmap work, and the scanner is unwired from the sensor — it never runs.
***
## Code-project scanning
The **Code projects** scanner is the only one that traverses developer directories, so it is worth being precise about what it does. It is **on by default** and can be turned off per organization (**Settings → Discovery → Project-level governance detection**) or at deploy time.
**Where it looks.** Under each scanned user's home directory: the conventional code roots `code`, `git`, `work`, `projects`, `src`, `dev`, `repos`, `Developer`, and `www` (to a depth of 6), plus the home directory itself (to a depth of 4). The traversal is bounded — at most 12,000 directories per scan and a 20-second deadline — and stops early rather than running long. If it runs out of budget, the report records the truncation instead of silently claiming full coverage.
**What it reads.** Dependency manifests only — `package.json`, `requirements.txt`, `pyproject.toml`, `go.mod`, `Gemfile`, `Cargo.toml`, `pom.xml`, Gradle files — and the installed package metadata beside them. **Your source code is never read, parsed, or transmitted.**
**What it reports.** A project is included only if it has at least one anchor-class agent framework or the VisIQ harness. A project that merely imports an LLM SDK is not reported at all. For each included project the sensor sends:
* the project directory path and the paths of the manifests it matched,
* the ecosystems in use (npm, pip, maven, gradle, go, gem, cargo),
* **only** the dependency names that match the agentic-framework taxonomy, and **only** the VisIQ harness package names — no other dependency name is ever serialized,
* whether the VisIQ harness is declared and whether it is actually installed,
* the owning local account (uid/SID and username) and install scope.
**Turning it off.** Toggle **Project-level governance detection** off in Discovery settings, or set `VISIQ_PROJECT_SCANNING=false` in the sensor's environment at deploy time — the environment variable is a hard opt-out that wins over the tenant setting. One caveat worth knowing: because this scanner is read-only detection, the sensor resolves an unreachable or unanswered settings lookup as **enabled**, the opposite of the harness auto-install gate, which fails closed. If you need the setting to hold on an endpoint regardless of connectivity, use the environment variable rather than the tenant toggle.
***
## Read-only by design
The sensor observes; it never runs what it finds.
* **Discovered MCP servers are never executed.** Their tool surface is read by static analysis of the on-disk package. When a server's tools can't be read statically (HTTP transport, dynamic registration, minified code), it's reported as an *unreadable tool surface* — a visibility finding — rather than launched to find out.
* **Package managers are never invoked.** Framework detection is a static walk of `node_modules` and Python `site-packages` directories — no `npm` or `pip` subprocesses.
* **Secrets never leave the host.** A detected API key is reported as a SHA-256 fingerprint of its value, never the key itself.
* **Coverage is honest.** The report records per-scanner coverage, so "zero findings" is distinguishable from "couldn't look." A degraded scan surfaces as *Needs coverage* — it never silently reads as safe.
***
## Two ways to deploy
The sensor ships as a single self-contained binary per platform — Linux (x64, arm64), macOS (Intel, Apple silicon), and Windows (x64) — with zero runtime dependencies. No Node, Python, or agent framework is required on the endpoint.
**Recommended.** The sensor installed persistently as a managed app through your device-management platform. It scans on the schedule you set in Discovery settings and can update itself in place with `visiq-discovery update`. **[Install it →](/discovery/deployed-sensor)**
The same binary run once through your existing endpoint tooling. Nothing stays installed on the host, and the scan schedule is whatever your own tooling defines.
Both approaches deliver the identical payload and produce the identical report. To get started, open **Integration → Connectors** in the dashboard and pick the **VisIQ Discovery Sensor** card — it's included with every plan and offers a fleet-rollout walkthrough, a single-host CLI install, or a copy-paste prompt your coding agent can run for you. The generated commands resolve a short-lived, authenticated download URL for your platform and verify the binary's published SHA-256 digest before it ever runs.
The sensor authenticates to your tenant with a harness key: with `VISIQ_API_KEY` and `VISIQ_ENDPOINT` set it reports each scan to your dashboard; without them (or with `--no-report`) it runs local-only and prints the JSON report.
***
## Where results land
Scan results power the **Discover** section in the dashboard sidebar:
* **Reach Map** — every agentic surface in your fleet, arranged by how far VisIQ governance can reach it today.
* **Inventory** — one row per scanned host, with the custom AI agents, MCP servers, AI frameworks, and tools found on each.
* **Findings** — one row per detected risk factor per host, with severity, evidence, and remediation status.
***
## How risk is scored
Every host gets a 0–100 risk score from an **additive point budget**: each exposure signal the sensor looks for is a catalog factor with a fixed weight, the weights sum to exactly 100, and a host's score is simply the sum of the factors detected on it. No opaque formula — the score always reconciles against the factor grid you see in the dashboard.
| Factor | Dimension | Points |
| ------------------------------------------------------ | -------------- | ------ |
| Live tool surface (MCP tools the agent can invoke) | Action surface | 30 |
| Agentic host (an agent framework installed and active) | Autonomy | 18 |
| Coding / CLI agent | Action surface | 14 |
| Running agent (live right now, not latent) | Autonomy | 14 |
| Framework concentration (3+ frameworks stacked) | Reach | 10 |
| Unreadable tool surface | Visibility | 8 |
| Incomplete coverage | Visibility | 6 |
Scores band as **Low** (0–39), **Medium** (40–64), **High** (65–84), and **Critical** (85–100). A host the sensor couldn't fully assess lands in a fifth lane, **Needs coverage**, which sorts above Low — degraded visibility is itself a finding, never a clean bill of health.
Findings map 1:1 to these factors, and remediation is derived automatically from scan history: when a factor stops appearing in a host's latest scan, its finding flips to *remediated* on its own. Nobody has to close tickets by hand.
***
## Settings
Discovery is configured per organization under **Settings → Discovery**:
* **Auto-install harness plugin** — off by default. When enabled, deployed sensors may automatically install the VisIQ harness plugin into supported agent tools they detect (such as OpenClaw), wiring up runtime governance with no manual step. VisIQ never modifies your agents unless you opt in.
* **Project-level governance detection** — **on by default.** Enables the Code projects scanner described in [Code-project scanning](#code-project-scanning): a bounded walk of conventional developer directories that reads dependency manifests (never source code) to report which projects build agents and which already have the VisIQ harness. Turn it off here, or set `VISIQ_PROJECT_SCANNING=false` at deploy time for an opt-out that does not depend on the endpoint reaching the control plane.
* **Scan frequency** — how often the Deployed Sensor scans each endpoint: hourly, every 6 hours, every 12 hours, daily (the default), or weekly. This governs only the Deployed Sensor; an On-Demand Scan runs on your own tooling's schedule.
* **Harness status** — how many discovery-installed harnesses are registered for your tenant and when one last reported.
***
## Next steps
Put the agents Discovery found under governance with one `visiq()` call.
How tool-call authorization works once an agent is harnessed.