Which roles hold discovery rights, what each permission key allows, and the separation of duties Discovery enforces in code.

Discovery rights are granted through TENSOR's role catalog. Three platform roles hold discovery permissions by default. Every other role, including the tenant administrator, holds none, which keeps the people who run discovery separate from the people who configure the tenant.

Roles

Role	What the role can do in Discovery
`platform_owner`	Everything: read and manage sources, decide deviations, topology links and tombstones, seal the attestation, manage the verification window, activate and run production apply.
`cmdb_admin`	Same as the platform owner. This role owns the estate and produces the attestation.
`auditor`	Read only: sources and runs, attestation, deviation queue, per-CI verification, absence queue. No export, no decisions, no policy changes.
`tenant_admin`	No discovery permission by default. Enables the feature flag, connects integrations and grants roles.
All other roles	No access. The Discovery menu entries stay hidden.

Some rights in this list belong to capabilities that do not yet have a screen: the verification window (policy) and bounded production apply are available through the service and API only, and the per-CI verification panel on the CI page is planned. See Availability.

Permission keys

Permission	Allows
`discovery.source.read`	View sources, runs, the review inbox and topology links.
`discovery.source.manage`	Commission, pause and retry sources; verify Intune consent; ingest topology observations.
`discovery.deviation.read`	View the deviation queue.
`discovery.deviation.manage`	Acknowledge, resolve or dismiss deviations.
`discovery.verification.read`	View per-CI verification status.
`discovery.report.read`	View the attestation and the verification-window history.
`discovery.report.export`	Seal the attestation as an immutable artifact.
`discovery.verification_policy.manage`	Record a new verification window.
`discovery.apply.activate`	Activate or withdraw bounded production apply for a source.
`discovery.apply.execute`	Preview, commit and compensate production-apply batches.
`discovery.tombstone.read`	View absence streaks and tombstone candidates.
`discovery.tombstone.decide`	Retire or keep a tombstone candidate.
`discovery.topology.decide`	Accept or reject an observed topology link.
`integration.config.manage`	Add, configure, test and enable integrations (the data connections behind sources).

Settling an ambiguous identity is not a discovery permission: it happens in the CMDB Reconciliation queue and needs CMDB reconciliation rights (for example cmdb_admin). See Reconciliation and import.

Separation of duties enforced in code

Auditors attest, they do not control. The auditor role is never granted export, verification-policy or deviation-decision rights: an auditor who could seal the artifact, move its window or close the deviations it counts would be attesting to a number they control.
Verification window changes need two people. A new verification policy must be approved by someone other than the person who records it. The database refuses a policy where approver and recorder are the same.
Activation is not operation. Activating production apply (discovery.apply.activate) and running batches (discovery.apply.execute) are separate permissions.
Two independent origins before production apply. Activation is refused unless another origin system has independently confirmed at least one CI.
Governance fields stay human. Owner, technical owner, criticality tier and supports critical function are refused for every source, both in the precedence engine and again at apply time.
Sticky flag. Switching discovery_sources off after the first sealed attestation needs a dual-approval request; the requester cannot approve it.

Action buttons are permission-checked on the server. An auditor who sees a decision button and selects it is refused: the role can read but not decide.

For the platform-wide rules on role assignment and dual approval, see Segregation of duties.

How administrators grant access

A tenant administrator assigns the cmdb_admin or auditor role to a user under Settings → Roles or on the user's record under Users. Custom roles can include individual discovery permission keys.

Menu entries follow the permissions: each Discovery page only appears when the user holds that page's read permission and the feature is on.

Page	Read permission
Discovery sources (with Run ledger)	`discovery.source.read`
Review inbox (with Observed topology links)	`discovery.source.read`
Deviations	`discovery.deviation.read`
Absent CIs	`discovery.tombstone.read`
Attestation	`discovery.report.read`

The step-by-step procedure is in Guides for administrators.

Keep auditors read-only

Do not give the auditor role any discovery write permission. Auditors must not control the figures they attest to.

Roles and permissions

Roles

Permission keys

Separation of duties enforced in code

How administrators grant access

On this page