Scanning external platforms
Discovery and Mapping explains the scanning model. This page is the platform-by-platform detail: what a connection to Databricks, Snowflake, Fabric, a cloud account or a vSphere estate actually reads.
One rule holds across all of them, and it is worth stating before the specifics:
The credential is resolved inside the service that owns the data path, and never crosses back.
A scan descriptor carries a reference. A guard walks that descriptor at any depth and raises if it finds anything credential-shaped: a password, a secret, a token, an API key, an access key, a private key or a client secret. The resolved value opens a client and stays in that process.
Databricks
Connect with a personal access token, or an OAuth machine-to-machine service principal whose client credentials are exchanged for a token at connect time. Credentials are redacted from every representation of the connection.
Reads the Unity Catalog REST surface: catalogs, schemas, tables, and table detail including columns, storage format and location. Where a workspace has no Unity Catalog, it falls back to information-schema queries over the SQL Statement API rather than reporting an empty estate.
Queries in place. Databricks advertises full SQL pushdown, so a query against a Databricks-backed asset can ship the whole statement to the warehouse instead of pulling rows back to filter. Results return to the caller in memory and are not persisted.
A connection without a SQL warehouse refuses with a named error rather than posting a statement that cannot succeed. Long-running statements poll with backoff and are cancelled cleanly if the caller goes away.
No vendor SDK is in the data path. The integration is plain HTTP, which is a sovereignty constraint rather than a preference.
Discovery moves metadata only: schemas, tables and columns land in the catalog. The table data stays in Databricks.
Snowflake
Snowflake is the deepest platform integration in the product, because it is the only one that also extracts a security posture.
Connect with account, user, password, warehouse, database and role.
Reads, for discovery, the information schema: schemas with table counts, tables with row counts and byte sizes, and columns with types, nullability and comments.
Reads, for data-security posture, nine sources: grants to roles, grants to users, users, policy references, masking policies, row-access policies, tag references, network policies, and authentication policies.
Three properties make that extraction trustworthy:
- Soft-deleted rows are excluded in the query and again in the mapper.
- The one source with no account-usage view is read in real time, and the result is stamped with its freshness so a caller can tell which figures lag.
- A single failing source returns empty rather than sinking the whole extract, so one permission gap does not cost you the other eight.
What comes back is an access graph: principals, grants and policies, credential-free by construction. It feeds rules covering over-broad roles, classification gaps, separation of duties and stale access.
Queries in place with full SQL pushdown, and predicate values are bound as parameters rather than interpolated into the statement.
Everything above is read-only. There is one exception, and it is heavily gated: remediation can apply corrective statements into a client's Snowflake, revoking over-broad grants.
It is off by default and requires all of: an in-scope grant record, a value gate pass, a self-exclusion check, compute-side credential resolution, a clean dry run, human approval, and a reversible snapshot captured before the change.
Microsoft Fabric and OneLake
Connect with an access token, a workspace identifier and a tenant.
Reads the Fabric REST surface: lakehouses and warehouses presented as schemas, and the tables within a lakehouse. Column detail comes from the information schema over the SQL analytics endpoint.
Two refusals worth knowing, both deliberate:
- Column resolution fails rather than returning an empty column list, because an empty schema reads as a valid table with zero columns and would sync a wrong schema silently.
- A lakehouse named in a request that does not exist raises rather than returning nothing, so a typo is an error instead of an apparently empty result.
Token exchange is not implemented. Unlike Databricks, there is no OAuth flow here, so an access token must be supplied rather than minted from a client secret.
SQL pushdown outruns its transport. Fabric's real SQL endpoint speaks a database wire protocol that is not implemented; the query path expects an operator-supplied REST endpoint. Treat Fabric as strong for discovery and plan the query path deliberately.
Power BI is a separate connection with its own provider, alongside SharePoint and OneDrive.
Cloud accounts
Cloud scanning reads a posture inventory, not data.
| Provider | What is read |
|---|---|
| AWS | Buckets with their access-control and encryption settings, security groups, and locally-managed identity policies with their contents |
| Azure | Network security groups with their full rule sets, and storage accounts with public-access and transport-security settings |
| Google Cloud | Firewall rules with direction, source ranges and allowed protocols and ports, and buckets with their identity bindings |
All four cloud client libraries are wired, and sovereign partitions are first-class: government partitions for each major cloud, plus two higher-assurance partitions above them.
Partition selection is fail-closed. A sovereign engagement at a given impact level refuses a lower-partition enumerator rather than falling back, and a provider with no equivalent partition refuses outright rather than substituting a commercial region.
Credential shapes are explicit. AWS accepts either static keys or a role to assume with an external identifier; a bare string is rejected rather than guessed at. Azure takes a service principal. Google takes a service-account key.
Least privilege is documented per call. Every API call the enumerators make is mapped to the exact permission it requires, alongside the acceptable managed read-only role for each cloud, so a customer can grant precisely what a scan needs.
One implementation detail that shows the sovereign posture: the AWS library is imported lazily, on first use. Loading it at startup cost time on every cell, including every air-gapped one that can never reach an AWS endpoint.
What the findings cover
Cloud posture rules cover public and unencrypted buckets, security groups exposing remote access or all ports to the world, unencrypted volumes, publicly reachable databases, wildcard administrative policies, and the Azure and Google equivalents of each. Findings can carry control mappings so a result lands against the framework it matters for.
Entitlement analysis (privilege escalation paths, least-privilege ratios) and cost analysis (rightsizing, commitments) read inventory shapes the enumerators do not yet produce. They run today on supplied inventory rather than on a live scan. Scope an evaluation accordingly.
VMware and vSphere
Connect with host, user and password against vCenter. The required privilege is the built-in read-only role on the inventory root, propagating. There is no provisioning path.
Reads virtual machines, hosts, datastores and networks through container views, releasing each view after use.
Per object:
| Object | What is read |
|---|---|
| Virtual machine | Encryption state, snapshot count and oldest snapshot age, tools status |
| Host | Version, lockdown mode, whether time synchronisation is configured |
| Datastore | Free-space percentage |
| Network | Name and identifier |
Eight hardening rules
| Rule | Severity |
|---|---|
| Virtual machine not encrypted | High |
| Datastore below its free-space floor | High |
| Network in promiscuous mode | High |
| Old snapshot retained | Medium |
| Host lockdown disabled | Medium |
| Host time synchronisation missing | Medium |
| Datastore not encrypted | Medium |
| Guest tools outdated | Low |
Findings sort deterministically, so two runs over an unchanged estate produce an identical report.
On top of those, consolidation analysis identifies powered-off, oversized, stale-snapshot and orphaned-disk waste and reports a reclaimable proportion, and migration readiness scores each machine and bands it as ready, needing remediation, or blocked.
Consolidation analysis needs performance counters the scan does not collect. It runs on supplied sizing data. A live scan gives you the eight hardening rules and migration readiness.
Datastore encryption defaults to reported-encrypted and promiscuous mode defaults to off where the interface does not expose them reliably, which avoids false positives at the cost of false negatives on those two rules.
The lens description says thirteen rules. Eight is the hardening rule count; thirteen counts the four consolidation categories and the readiness band as well. Ask which figure a claim refers to.
How a live scan runs
- A scan is submitted against a stored connection for an engagement, which is checked against that engagement's authorized scope. An out-of-scope provider is denied.
- The run is recorded as pending a live scan rather than carrying an inventory.
- A worker claims it and calls into the service that owns the credential.
- That service resolves the secret, builds the client, enumerates, and returns the inventory only.
- The inventory is written back so the report can be reconstructed afterwards, and the lens engine produces findings.
The credential exists only in step four, in one process.
What is available today
| Integration | Status |
|---|---|
| Databricks discovery, federation and SQL pushdown | Available |
| Snowflake discovery, federation, and the nine-source security extraction | Available |
| Fabric and OneLake discovery | Available. Token exchange and a native query transport are owed |
| AWS, Azure, Google and vSphere enumeration, including sovereign partitions | Available |
| Cloud posture, vSphere hardening, migration, storage, exposure and AI-governance lenses | Available |
| Snowflake remediation write-back | Available, off by default behind six gates |
| Entitlement and cost lenses | Supplied inventory today; live enumeration owed |
| vSphere consolidation analysis | Supplied sizing today; performance collection owed |
| Security posture extraction beyond Snowflake | Owed |
| Scanning of business-intelligence tools and metadata catalogs | Available. Published-content inventory with lineage edges back to the underlying sources, and read-only catalog walks for migration onto this catalog |
| Scanning of transformation tools | Connector interfaces defined, with backends pending. A scan refuses by name rather than reporting an empty estate |
Related topics
- The scanning model itself: Discovery and Mapping.
- Ingesting rather than scanning: connectors and ingestion.
- Reading a source in place: catalog interoperability.
- The engagement surface these run under: consulting.