How Discover handles your data
NobleCloak Discover reads your identity provider to enumerate which third-party and AI applications your people have authorized, and turns that inventory into a risk report. Because that makes us a holder of metadata about your organization's exposure, this page states exactly what the service holds once a scan runs, for how long, and what it is built to never do.
Two things this page is not: it is not a compliance certification, and it is not the client-side story for the offline export scripts — that lives in the agentless assessment privacy statement, which covers what runs on your machine and what a Discover Export Format file does and does not contain. This page picks up where that one ends: what happens to data once it reaches us, by either path.
What Discover holds
Three classes of data, all derived from your identity provider's records:
| Data class | What it is |
|---|---|
| Grant inventory | One row per (user, application) authorization: the application, the scopes it was granted, consent type, first-seen and last-used dates |
| Report | The composed assessment — findings, risk scores, framework crosswalk, and the rendered report artifacts |
| Entitlement map | A per-user summary of which applications each user has authorized, derived from the grant inventory |
What Discover never holds
The service's inputs are identity-provider metadata only. Discover does not read, hold, route, or process the content behind any of it — no email or message bodies, no files, no calendars, no member records, and none of your organization's regulated data. You can verify this claim against the scope lists below: no requested scope grants content access, and a connector that would need content access to work is out of scope for the product by construction.
The scopes we request
Every scope appears on the consent screen your administrator approves, so this list contains nothing you would not see there — it is published so you can review it before consenting rather than during.
Google Workspace:
| Scope | Used for |
|---|---|
admin.directory.user.readonly | Listing users |
admin.directory.group.readonly | Listing groups |
admin.directory.orgunit.readonly | Listing organizational units |
admin.directory.user.security | Enumerating third-party OAuth grants (tokens.list) — the core shadow-AI signal. We make no write calls |
admin.reports.audit.readonly | Reading audit reports for per-app usage recency |
appsmarketplace.license | Reading Workspace Marketplace app installations and licenses |
Microsoft Entra ID:
| Scope | Used for |
|---|---|
Directory.Read.All | Service principals, permission grants, app role assignments, user resolution |
Application.Read.All | Application and service-principal object reads |
AuditLog.Read.All | Sign-in logs, for per-app usage recency |
The Entra consent additionally includes offline_access, the standard
OAuth mechanism scope that lets the connection refresh without asking your
administrator to re-consent; it grants no data access of its own.
The scan makes read calls only — it enumerates and never modifies, revokes, or provisions anything in your environment.
Knowing is not connecting
A discovered authorization is knowledge, never access. The grants Discover enumerates belong to the vendors your users authorized — they are not credentials we can use, and nothing Discover holds can operate any discovered application on your behalf. If your organization later chooses to connect a tool through the NobleCloak platform, that is a separate, explicit consent with its own scopes, granted by you at that time — never inherited from the assessment. The two grants are separate records with separate consents in our systems, so one cannot quietly become the other.
Credential custody
Discover does not store your identity-provider credentials. The connection your administrator consents to is held by our platform credential service; the Discover service itself holds only an opaque reference to it. At scan time it obtains a short-lived, read-only access token, runs the enumeration, and the token expires — Discover has no ability to refresh or extend its own access.
Retention
Scan data is stored as an append-only series of dated snapshots. A re-scan adds a new snapshot and never overwrites a prior one — which is what makes month-over-month drift ("three new vendors, one went dormant") a factual comparison rather than a reconstruction.
Snapshots are retained for a bounded window — 18 months by default, with longer windows available by subscription tier. At the end of the window a snapshot is either deleted or, where a longer-retention tier applies, moved to encrypted cold storage for the remainder of its term and then deleted. Retention is never indefinite.
The audit log described below is retained at least as long as the data window it covers — it records the deletions themselves, so it cannot be deleted ahead of them.
This section describes how the system behaves today. Contractual retention and deletion commitments for your engagement are set in your agreement, not by this page.
Isolation and the shared intelligence boundary
Scan data — the grant inventory, reports, and entitlement maps — is isolated per organization and encrypted at rest. The isolation tiers available to a deployment are the same ones documented on the Security overview.
One boundary deserves explicit statement. Discover enriches findings against our vendor-intelligence library — the shared, curated store of vendor risk facts that makes the report's citations possible. The only thing that crosses from your scan into that shared layer is the application's identifier (a client ID or app name), so it can be matched to a known vendor. Your users' identities, their grants, and your organization's context never do. The vendor facts that come back are pinned into your snapshot with their citations and verification dates, so your report stays reproducible even as the shared library evolves.
The audit of the audit
Every scan, every operator action, every report export, and every retention deletion or archive transition writes to an append-only audit log. A tool that exists to produce evidence keeps evidence about itself.
Requesting more detail
Detailed control descriptions — including per-scope enforcement, security questionnaire responses, and architecture detail beyond what a public page should carry — are available to customers and prospects on request at security@noblecloak.com.
Last updated: 2026-08-18