Skip to main content
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: 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.

Deployed Sensor

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 →

On-Demand Scan

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. 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: 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

Quickstart

Put the agents Discovery found under governance with one visiq() call.

Action Governance

How tool-call authorization works once an agent is harnessed.