In the connected shape you grant TigerGate a read-only role and scans run on our infrastructure. It is the only shape where TigerGate can start a scan for you, and the fastest route to a first inventory. If data must not leave your account, use the in-account shape instead. Findings are identical either way.

​
1. Connect the account

Data Security reuses the cloud accounts already connected under Cloud Security. If the account is connected there, it appears under Data Security → Scan Configuration with no further setup. To connect a new one, follow the provider guide:
  • AWS — role assumption with an external ID that TigerGate mints. A client-supplied external ID is rejected.
  • GCP — service account or workload identity.
  • Azure — app registration with a directory role.
Data Security scans AWS, GCP and Azure. Cloud Security connects more providers than this — an account of another kind stays visible in Scan Configuration but is marked as one Data Security does not scan, rather than reported as an account whose scan failed.
Tier 0 inventory begins on the next scheduler pass. It reads control-plane APIs only, so it is safe to point at production immediately.

​
2. Choose what to scan

Open the account under Scan Configuration. Inventory needs nothing further. To classify content, set Scan depth to Read object content in the scope below and choose a scope. Both are required — a grant alone does not start a content read, and neither does a scope without the grant below. See Scan configuration for scope, sampling profiles and frequency.

​
3. Grant object access

Reading object content requires a separate, verified grant per account. The posture role is deliberately not sufficient: inventory and content are different levels of access, and one should not silently imply the other. Until that grant exists, the scheduler says so plainly rather than appearing idle: 
[content] NO verified object grant exists, so no store can ever be claimed
          and nothing will be classified

​
4. Database access

Relational and NoSQL stores need a read-only database user. Set it under Database access in the same panel:
  • Create a read-only user in your database and grant it SELECT.
  • Enter that username.
  • Prefer the passwordless method your cloud offers — IAM database authentication on AWS, workload identity on GCP, Microsoft Entra on Azure.
TigerGate never accepts a database password. For engines that require one, the password stays in your own secret manager and TigerGate resolves the reference at connect time using the role you already granted.

​
What TigerGate stores

KindStored
Cloud credentialsEncrypted, per account. Role assumption is preferred so there is no long-lived key.
Database passwordsNever. Only a reference to a secret in your account.
Object contentsNever. Classification produces classifier IDs, counts, confidences and masked exemplars.
Row valuesNever. Same as above.
Masked exemplars are enforced by the scanner’s type system rather than by convention — raw matched values have no accessor that could place them in a finding.

​
Verifying it works

The console’s Coverage page is the authoritative answer: it reports stores discovered against stores read, and names every service excluded by configuration or refused by permissions. A first scan showing many stores and no classifications usually means content scanning is not yet enabled — check scan depth, scope and the object grant in that order.