Google Drive integration

Last updated date:

How Seedling connects to Google Drive, which read-only information it uses, and how access and deletion are controlled.

1. Overview

The implemented Google Drive connector uses a Google OAuth grant for one user, or an organization-wide Google Workspace parent connection, to read files visible to that identity.

Seedling deduplicates files by immutable Drive file ID while retaining each exact observing connection and its permission contribution. A second observer never grants the first observer's audience.

2. Connection and scope

Seedling verifies the provider account before storing the connection. A personal connection remains actor-owned; a workspace connection is administered for the selected Seedling workspace. Credentials are never inferred from an email address or silently promoted between scopes.

Google OAuth or Workspace delegation
A dedicated connection uses access and refresh tokens issued with drive.readonly. Organization-wide sources inherit a verified Google Workspace parent and its short-lived delegated tokens.
Connection ownership
Seedling supports actor-owned personal access and administrator-managed workspace access for this connector. The selected scope and exact connection remain fixed through synchronization, rotation, disconnect, and purge.

3. Google Drive data Seedling accesses

Seedling uses synchronized information for source-backed search, operating context, verification, and customer-approved workflows. Availability depends on the connected account, selected resources, provider plan, and native permissions.

Files and folders
File identity, names, MIME types, ownership context, hierarchy, metadata, authorized content, comments, replies, versions, and change state.
Shared drives
Shared-drive identity, membership context, parent relationships, and files visible to the delegated user.
Native permissions
File and drive permission entries, stable principals, domains, groups, and link-sharing evidence returned by Google for audience projection.

4. Read-only permission contract

The connector requests drive.readonly and identity scopes where applicable. It cannot upload, edit, share, move, trash, or delete Drive content.

  • drive.readonly — read file metadata, authorized content, permissions, comments, replies, shared-drive context, and changes.
  • openid, email, and profile — verify the identity for a dedicated OAuth connection; these scopes do not expose Drive content.
  • No drive.file, drive, sharing, or mutation scope is requested.

5. Security and access

  • Provider credentials and other connection secrets are encrypted in the workspace tenant data plane, never returned to the browser, and excluded from logs and queue payloads.
  • Every source, synchronization, secret lookup, audience contribution, disconnect, and purge remains bound to the exact connection that created it.
  • Workspace connections use provider-returned object permissions and stable principals for human audience projection. Missing, stale, ambiguous, or unmappable ACL evidence contributes no human audience, and no Seedling administrator or steward may broaden it.
  • For a personal connection, raw content remains visible only to the connecting member in human-facing Seedling surfaces. Personal content may contribute to trusted system exploration under workspace policy, but that authority never transfers to another member.
  • Missing, stale, ambiguous, domain-wide, or unmappable Drive permission evidence contributes no human audience. A steward can repair connection policy but cannot grant themselves native file visibility.
  • Generated output cannot bypass Seedling's human review, verification, and approval gates.

6. Retention and deletion

Connected data
Synchronized Google Drive records remain while the connection is active and are removed through a durable integration purge after disconnect.
Credentials
Stored Google Drive credentials or connection secrets and connection-owned synchronization state are deleted from active Seedling systems as part of the purge.
Backups
Deleted information may remain in encrypted, access-restricted backups until expiry, ordinarily within 35 days after active-system deletion.