1. Overview
The GitHub integration uses a GitHub App installation to read selected repositories and their delivery history without asking a customer to paste a personal access token.
Repository selection is part of the provider authorization. Seedling reads only repositories available to the installation and uses stable GitHub account, installation, repository, and object identifiers.
2. Connection and scope
Seedling verifies the provider account before storing the workspace connection. A current Seedling workspace administrator controls installation and disconnect; account identity is never inferred from an email address or display name.
- GitHub App installation
- An authorized GitHub account or organization owner installs the app and selects all or specific repositories. GitHub issues a short-lived installation access token.
- Workspace connection
- The verified GitHub account and installation are attached to the selected Seedling workspace; installation identity and repository selection are retained for lifecycle control.
3. GitHub 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.
- Repositories and contents
- Repository metadata, selected files, default branches, commits, contributors, and releases available to the installation.
- Issues
- Issues, labels, assignees, state, comments, timing, and repository context.
- Pull requests
- Pull requests, reviews, review comments, merge state, branches, authorship, and related commits.
4. Read-only permission contract
The GitHub App requests read access only. The installation token is also bounded by the repositories selected during installation.
- metadata:read — identify selected repositories and basic repository context.
- contents:read — read repository files, commits, branches, and releases used by the adapter.
- issues:read — read issues and issue comments.
- pull_requests:read — read pull requests, reviews, and review comments.
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.
- GitHub installation tokens are short-lived and generated for the exact app installation; repository selection can be narrowed in GitHub without creating a new Seedling workspace.
- The provider does not expose enough object-level audience evidence for Seedling to reproduce every native permission safely. Workspace content therefore follows the connection's restricted-by-default policy; administrators and stewards receive no raw-content bypass.
- Generated output cannot bypass Seedling's human review, verification, and approval gates.
6. Retention and deletion
- Connected data
- Synchronized GitHub records remain while the connection is active and are removed through a durable integration purge after disconnect.
- Credentials
- Stored GitHub 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.