---
title: "Autonomous discovery"
---
<!-- licenses: community, platform -->

((Autonomous discovery)) is a scan mode that reviews the results of every completed scan and automatically queues bounded follow-up scans to expand coverage. Instead of asking you to enumerate every subnet or subdomain up front, runZero starts from a small seed scope, looks at the evidence each scan produces — routing tables, ARP caches, traceroute hops, TLS certificates, DNS answers — and decides what to scan next. The loop repeats until there is nothing new left to find.

Autonomous discovery works out of the box using deterministic rules and requires no AI. Accounts that have [AI enabled](ai-threads.md#ai-requirements) can optionally let their own AI provider drive the analysis instead; both paths are described in [AI-assisted discovery](autonomous-discovery.md#autonomous-ai).

![The autonomous discovery loop: a seed scan feeds a review wave, candidates pass guardrail validation, follow-up scans are queued, and each completed follow-up repeats the review until the loop converges](img/autonomous-discovery-loop.svg)

## Requirements {#autonomous-requirements}

* The account must have the autonomous discovery entitlement, which is included with all runZero license tiers, including Community Edition.
* Internal discovery requires at least one active [Explorer](installing-an-explorer.md) with access to the private networks you want to explore.
* External discovery targets public IP space and typically runs through a [Hosted External Explorer](discovering-assets.md#discovering-hosted-external-explorer).
* AI is **not** required. AI-assisted analysis is optional and only used when the account has the AI entitlement and a working [AI configuration](https://console.runzero.com/account/ai).

## How it works {#how-autonomous-discovery-works}

1. You launch a scan with an autonomous discovery mode selected. This seed scan runs like any other scan.
2. After the console processes the results, a **review wave** analyzes the new evidence and proposes follow-up candidates: private subnets, related hostnames and domains, or deeper scans of confirmed-live networks.
3. Every candidate is validated against the guardrails below, deduplicated against everything the lineage has already scanned, and dropped if its confidence score is below 0.30.
4. Surviving candidates are queued as child scan tasks, capped at 5 to 12 follow-ups per wave depending on how confident the wave is (8 is typical). Adjacent `/24` candidates are batched into a single task, and discovered hostnames land as one multi-target scan.
5. Each follow-up keeps the autonomous mode, so the loop repeats when it completes — up to 12 waves and 150 distinct scopes per lineage.

The loop **converges** — stops queueing new work — when a wave produces no actionable candidates, novelty drops off, asset growth or vendor diversity plateaus for consecutive waves, or the iteration and scope limits are reached. Convergence is reported on the task, not treated as an error.

### Guardrails

* Follow-up scans never leave the lane they started in: internal discovery only proposes private address space, and external discovery only proposes names under your seed domains.
* Site exclusions, existing scope, and everything already scanned by the lineage are always respected.
* Overly wide targets are rejected — internal candidates are never broader than a `/16` (IPv4) or `/48` (IPv6).
* Follow-up scans do not inherit credentials from the seed scan. Credential IDs and sensitive scan options are stripped before each child task is created.

## Internal discovery {#autonomous-internal}

Internal mode grows coverage of private networks from topology evidence: SNMP routing tables, interface addresses and ARP caches, RIP routes, traceroute hops, CDP and LLDP management addresses, and default gateway attributes. Public routes and default routes are ignored.

Internal discovery uses a depth progression rather than deep-scanning everything immediately:

* **discovery** – a light probe of a newly inferred subnet to confirm live hosts.
* **sweep** – a coarse liveness scan of a wider private block when clustered evidence justifies it.
* **deepen** – a full default scan of a `/24` (or IPv6 `/48`) that discovery confirmed as live. A subnet is only deepened once, and a subnet that looks like a firewall responding on every address is never treated as live.

Coverage is also tracked per scope and per dimension (liveness, ports, screenshots, and so on), so later waves can re-deepen scopes whose deep coverage has gone stale instead of only chasing new space.

## External discovery {#autonomous-external}

External mode starts from the public IPs and `domain:` targets in your seed scope and expands through names: TLS certificate subjects and SANs, forward DNS answers, parent domains, and observed hostname patterns such as region or environment series.

Expansion is strictly bounded by ownership. A candidate hostname or domain must share a registrable domain with your seed scope — an unrelated domain that appears in a shared certificate is dropped, and observed ASNs are never turned into IP sweeps. On the first wave, if public IPs are present, runZero may also queue a one-time passive [Shodan](shodan.md) import to enrich the seed assets before active expansion.

When scanning reveals infrastructure that cannot be enumerated over the network — cloud accounts or virtualization hosts, for example — the review records an **integration hint** suggesting the relevant [integration](integrations-inbound.md) instead of queueing a scan.

## Starting an autonomous scan {#starting-autonomous}

From the [Scan page](https://console.runzero.com/data-sources/scan) in the Data sources section of the navigation menu, the **External** and **Internal** buttons open the scan form pre-configured for the matching mode, with a recognizable task name and a recommended starting scope. You can also configure any standard scan by hand: in the scan form, the **Autonomous discovery** control offers **Off**, **Internal**, and **External**, and the **Use recommended targets** button fills the scope with the site's default scope (internal) or your organization's domain and public egress IP (external).

* Internal discovery works best with a **Continuous** schedule and a seed scope drawn from the Explorer's local networks. Internal scopes must contain private IP addresses only — no hostnames or public ranges.
* External discovery works best with a recurring schedule — the form defaults to every 5 minutes, since hosted scans do not support the Continuous frequency — and a seed scope of public IPs, ASNs, and `domain:` targets. External scopes must not contain private addresses.
* On Community Edition licenses, autonomous scans default to an hourly schedule.

[Scan templates](managing-scan-templates.md) can set a default autonomous discovery mode, so recurring scans created from a template participate automatically.

## Working with follow-up scans {#autonomous-follow-ups}

Queued follow-ups appear on the [tasks page](https://console.runzero.com/tasks) named `Autonomous follow-up: <target>`, tagged `autonomous=true`, with a description recording the wave number, confidence, and the evidence that motivated them. Each runs on the same site and Explorer (or hosted zone) as its parent.

Every autonomous task's detail page includes an **Autonomous discovery** card showing the loop status — mode, state, wave number, assets discovered, novelty, and vendor diversity — plus the latest review wave: which brain ran, every candidate it considered, its confidence, and the outcome (queued, skipped for low confidence, deferred by the wave cap, duplicate, or stop signal). When AI was used, the card also reports the token usage for the wave.

To stop the loop, stop or dismiss any task in the lineage. This cancels the entire lineage — active siblings and descendants are stopped, and no further follow-ups are queued.

## AI-assisted discovery {#autonomous-ai}

Autonomous discovery runs one of two analysis engines, and the task details card tells you which one reviewed each wave.

![Brain selection: when the account has no working AI configuration the deterministic rule-based brain runs; when AI is entitled, configured, and within budget the AI-assisted brain runs using your own provider; both feed the same validation and guardrails](img/autonomous-discovery-brains.svg)

### Without AI: the rule-based brain

By default, review waves use the **rule-based** brain — deterministic topology and certificate analysis that runs entirely inside the runZero platform. Nothing is sent to any AI provider, there is no per-wave cost, and results are fully reproducible. This is the complete, supported experience: the rule-based brain implements all of the internal and external expansion logic described above.

### With AI: bring your own key

runZero AI support uses a BYOK (bring your own key) approach — you connect a model from your own AI provider account rather than runZero supplying one. When AI is available, review waves use the **AI-assisted** brain: your configured model examines the same scan snapshot through a set of read-only tools and proposes candidates with reasoning. This can produce smarter expansion — recognizing naming conventions, prioritizing interesting segments, and stopping earlier when evidence is weak. To use it:

1. Your account must have the AI entitlement.
2. A superuser enables AI under [Account settings → AI configuration](https://console.runzero.com/account/ai) by selecting or creating an AI provider credential. Supported providers include Anthropic, OpenAI, Google Gemini, Google Vertex AI, AWS Bedrock, Azure OpenAI, and OpenAI-compatible or Anthropic-compatible endpoints (OpenRouter, Ollama, internal proxies). **Verify & save** performs a live check against the provider before the configuration is activated.
3. Individual organizations can override the account provider with their own credential, or opt out of AI entirely, from the organization's AI settings.

The AI-assisted brain is subject to the same [token budgets](ai-threads.md#ai-requirements) as other AI features. Daily input and output token caps can be set per account and per organization, and each wave's usage is recorded against the `autoscan` feature in the AI usage report on the AI configuration page, as well as on the task itself.

A few properties worth knowing:

* **Same guardrails.** AI proposals are advisory. Every candidate passes exactly the same validation, scope, ownership, and deduplication checks as rule-based output before anything is queued.
* **Bounded data sharing.** The AI-assisted brain only sees a compact summary of the completed scan's results — it cannot browse your wider inventory. As with all BYOK features, data sent to your provider is governed by your agreement with that provider.
* **Automatic fallback.** If AI is unavailable for any reason — missing entitlement, a deleted credential, an exhausted budget, or a provider error mid-wave — the wave falls back to the rule-based brain and the loop continues. Autonomous discovery never stalls waiting for AI.

## Limits {#autonomous-limits}

* A lineage runs at most 12 review waves and 150 distinct scopes.
* Each wave queues at most 5 to 12 follow-up scans; the rest are deferred to the next wave.
* Candidates below a confidence score of 0.30 are recorded but never scanned.
* Internal candidates are capped at `/16` (IPv4) and `/48` (IPv6) widths; external candidates must stay under a seed registrable domain.

## Troubleshooting {#autonomous-troubleshooting}

If autonomous discovery is not behaving the way you expect, the questions and answers below may assist in your troubleshooting.

### Why didn't my autonomous scan queue any follow-up scans?
1. Check the **Autonomous discovery** card on the task details page. If the state is **Converged**, the review wave found no actionable evidence — this is the loop working as intended, not a failure.
2. Review the candidates table on the same card. Candidates may have been proposed but skipped for low confidence, deduplicated against earlier waves, or deferred by the wave cap.
3. Verify the task was not stopped or dismissed while results were processing; a canceled lineage never queues follow-ups.

### Why does the task show the rule-based brain when AI is enabled?
1. Confirm the account has the AI entitlement and that the [AI configuration](https://console.runzero.com/account/ai) shows an active provider. A credential that has been deleted disables AI-assisted waves rather than borrowing another provider.
2. Check whether the organization has opted out of AI or has exhausted its daily token caps — budget-exhausted waves fall back to rules until the budget resets.
3. A provider error during a wave also falls back to rules for that wave; check the AI usage report for partial usage.

### Why do follow-up scans run without my scan credentials?
This is by design. Inferred targets do not inherit trust from the seed scan, so credentials and sensitive scan options are stripped from every follow-up. Run a credentialed scan of the discovered scope manually if deeper authenticated data is needed.

### Why did external discovery skip a hostname it found in a certificate?
External expansion only follows names whose registrable domain matches your seed scope. A hostname on a shared certificate that belongs to another organization's domain is intentionally dropped. Add the domain to a new seed scan's scope if you own it and want it explored.