Sources and commissioning

A discovery source is one external system that delivers observations. Before a source may stage anything, it climbs a safety ladder you control; every pull it makes is recorded as a run. This page covers the sources, the ladder, the run ledger and the on-premises collector. The procedures are in Guides for administrators.

Discovery sources

Each source is registered with its origin system. Verification only counts a confirmation when it comes from a different origin than the one that created the CI, so a scanner cannot confirm what the scanner itself discovered.

Connections and credentials

Sources ride on TENSOR's integrations platform: you add the scanner or Intune connection under Settings → Integrations (permission integration.config.manage), and the platform provides the adapter, the polling scheduler, encrypted credential storage, health events and the data-residency acknowledgement.

• Credentials are encrypted at rest and never logged; the configuration keeps only a reference. Partially available: credentials are stored encrypted, but the integrations screen does not yet offer a field to enter them.
• An integration whose vendor stores data outside the EU needs an explicit, audited data-residency acknowledgement before you can enable it. Scanner vendors default to their public SaaS region, which may be outside the EU.
• Adapters still marked Preview can only be enabled with the integrations_preview flag.
• The integration poll ticks every 5 minutes; each integration keeps its own cadence, 6 hours by default for scanners.

Vulnerability scanners

The Tenable, Qualys and Rapid7 connectors contribute asset inventory and open findings. A scanner confirms CIs you already have: it never creates CIs, so unmatched scanner assets remain visible as unmatched rather than filling your CMDB with guesses. Open findings are recorded as CVEs on the matched CI, duplicate-safe and subject to the minimum CVSS score you configure on the integration. CVE recording also needs the cve_detection_ui flag.

Scanner assets are linked to CIs by the hourly apply sweep — reconciliation, precedence and apply or review run for scanner sources today. Scanner runs do not yet pass through the run ledger and the commissioning gate described below.

Microsoft Intune

Intune is an independent second origin, because its data comes from an agent on the endpoint. It contributes managed devices, detected applications, and patch and update state. Onboarding needs an Entra app registration and admin consent for the Graph scopes DeviceManagementManagedDevices.Read.All, DeviceManagementConfiguration.Read.All and DeviceManagementApps.Read.All. The Microsoft Intune onboarding panel on the Discovery sources page lists the scopes, links to the Entra admin-consent page and offers Verify Graph access — the only reliable proof that consent is in place, because a token is issued even without consent and every read then fails.

Intune runs pull, stage evidence and appear in the run ledger. Intune observations are not yet linked to CIs by the apply sweep.

Commissioning and run control

The safety ladder

A new source starts disabled and moves through connection test and observe only before it can become active.

Allowed transitions between these states are listed in Lifecycle and processes.

Current limitation. Connection test, observe-only approval, pause and retry are available in the UI. Moving a source to active is supported by the service but has no button yet.

Approved scope

When you approve observe-only you record:

• the scope digest (16 to 128 characters),
• the manifest version,
• the allowed fields and allowed data classes,
• the maximum new records and maximum changed records per run (defaults 1000 and 5000).

For Intune, the onboarding panel shows the scope, manifest version, fields and data classes to copy into the approval form. Do not retype the scope digest by hand: one wrong character quarantines every run.

Automatic quarantine

A run that arrives with a different scope, manifest version, field or data class than approved is refused and the source moves to quarantine. The run ledger shows the reason: scope mismatch, manifest version mismatch, field not allowed or data class not allowed. To bring the source back you run a connection test and approve the correct scope again. Widening a scope is a governance decision — record the reason with your change process before you approve a larger scope.

Change caps

A run that would exceed the approved maximum new or changed records stops before the first write and ends as capped. Nothing is written. Start with low caps: a misconfigured source then cannot flood the CMDB. If the volume is expected, raise the cap deliberately.

The run ledger

Every pull is a run. The Run ledger, further down the Discovery sources page, shows each run with the columns Run, Outcome, Mode, Received / rejected and Started. Outcome is one of running, succeeded, partial, failed, quarantined, capped or paused, with the failure reason underneath. The meaning of each outcome, and whether it counts towards absence, is in Lifecycle and processes.

A completed run is immutable. A failed pull is closed rather than left running.

Bounded retry

A run with outcome failed, partial, quarantined, capped or paused can be retried with Retry run, up to three attempts in total. After that TENSOR refuses further retries. Runs that are running or succeeded cannot be retried.

Current limitation. The run ledger tables are not yet paginated or filterable.

Import health outside Discovery

Failed and partial discovery imports are also raised on Settings → System health, so operators see them without opening the Discovery pages. Integration-level problems appear under Recent health events on the integration in Settings → Integrations.

On-premises collector

The collector is an on-premises agent that runs discovery inside your network and reports to TENSOR. It is partially available: the enrollment and heartbeat endpoints exist behind the discovery_collectors flag. Minting enrollment tokens, the collector management UI and all scan tiers are planned — not yet available.

What exists today:

• Outbound-only. The collector is a single static Go binary that connects to TENSOR over HTTPS on port 443 and needs no inbound port.
• Enrollment. A collector enrols with a single-use token; only a SHA-256 hash of the token is stored. It then receives a scoped credential and appears as a source in the tenant.
• Heartbeats report liveness and version; a new version is audited.
• Revocation is terminal. The credential stops working and a replacement collector is a new identity.

Planned — not yet available:

• Minting enrollment tokens and a collector management page with scan scheduling.
• The scan tiers: network sweep, TLS certificates, Windows and Linux credentialed scans, vCenter, on-premises Citrix, Kubernetes and containers.
• Scan credentials kept in a vault on the collector and never transmitted; scans run only inside a declared, audited scope allowlist and designed to be lockout-safe against your own accounts.
• A dedicated works council and GDPR discovery package with enforced data-minimisation switches.