Before connecting a private repository, establish which repositories and operations the tool can access, what content it will actually copy, where that content goes, and how access ends. Approve the smallest installation and a bounded pilot only after a repository owner, security reviewer and vendor can answer those questions with evidence. A GitHub App installation, for example, asks for specific repository and organization permissions and can be limited to selected repositories; its installation tokens can be narrowed further. Those platform controls help, but they do not describe the vendor's internal copies or downstream model calls (GitHub installation guidance, installation-token guidance).
This checklist is for a security leader approving a real connection. Use your Git provider's current settings and the tool's documented behavior. The GitHub details below are one concrete example, not rules that automatically apply to GitLab, Bitbucket or a self-hosted provider.
Start with the task the tool must perform
Write the intended workflow in one paragraph. Does the tool need a one-time assessment of a pinned revision, continuous pull-request review, scheduled scans, issue comments, status checks or remediation pull requests? Each additional workflow may require different permissions and produce more persistent material. “Read-only scanner” is not a complete scope: the tool may read CI files, configuration, deployment manifests, test fixtures and historical branches, and may send excerpts to a model or support log.
Illustrative case; the organization and configuration are invented. Meridian Works wants to assess one payments-api repository before considering a broader rollout. The initial job only needs to read a fixed revision and return a private report to two security reviewers. It does not need to write code, create pull requests, comment on issues or access every repository in the organization. Meridian creates a separate repository, payments-pilot-fixture, containing only authored synthetic source and history. A synthetic branch inside payments-api would not restrict repository-wide Contents read authority. The team records who can approve connecting the private application repository later.
The initial access record is deliberately small:
| Field | Meridian's proposed answer | Evidence or check |
|---|---|---|
| Purpose | One manual review of a pinned payments-pilot-fixture revision |
Purchase/pilot scope and submitted job settings |
| Git installation | Selected repository only | Installation configuration viewed by an organization owner |
| Repository permission | Contents read only; metadata needed for identification | GitHub App requested-permission screen and vendor endpoint list |
| Write operations | None approved | No write permission requested; pilot observes no write API calls |
| Trigger | Manual start; no continuous webhooks needed for this phase | App event subscription list and vendor job record |
| Downstream data | Selected source bytes, summaries, findings and possible model input | Vendor data-flow and retention schedule |
| End of access | Remove repository from installation and retire vendor-held copies by agreed schedule | Git configuration readback plus vendor deletion evidence |
This is a proposed control record, not proof that a named security product behaves this way. A real approval should attach dated screenshots or API outputs and the vendor's responses.
The questions and the evidence to request
| Ask the vendor and repository owner | Useful evidence | Decision if the answer is missing |
|---|---|---|
| Which identity and installation are used? Is access through a GitHub App, OAuth user grant, personal token, deploy key or service account? | App identity, installation ID, credential owner, expiration and rotation method | Hold connection until the principal and owner are known |
| Which repositories are accessible now, and can the set expand automatically? | Installed-app repository selection and change procedure | Select pilot repositories and require change approval |
| What exact permissions and subscribed events are required for this workflow? | Requested-permission list, documented API calls and webhook events | Remove unneeded privileges or explain why they are necessary |
| Does the tool create narrower credentials for each job? | Token issuance design, permission/repository constraints, lifetime and storage path | Treat installation-wide authority as an explicit risk |
| What revision and files are acquired? Are submodules, archives, history and generated files included? | Scan manifest, file inventory, exclusions and provider error handling | Do not call an incomplete or unknown scope a full review |
| Where do source, prompts, output, reports and logs go? | Data-flow diagram with region, processor, retention and backup entries | Use synthetic data until the flow is resolved |
| Who can read source and findings after ingestion? | Application roles, support procedure, export paths and audit events | Restrict report audience before processing sensitive source |
| What stops new reads when access is revoked? | Revocation steps, token behavior, queued-job cancellation and validation record | Schedule an offboarding exercise in the pilot |
| What is deleted, when and from which copies? | Source/derived-data inventory, backup and log retention, deletion receipts | Limit scope or hold if the promise cannot be made specific |
The table is a decision aid. A vendor can reasonably need more permissions for a later feature, but that feature should be approved as a separate change. GitHub documents how owners can review permissions and switch an installed app between all repositories and selected repositories (reviewing installed apps). It also describes a separate approval flow when an app requests additional permissions (updated permissions). Record the baseline and who will review a future request.
Check effective privilege, not a label
Ask for the mapping from each requested permission to the planned operation. GitHub's permission guide explains that apps should request the minimum permissions needed. For a source-only pilot, challenge repository administration, contents write, workflow write or organization-wide privileges unless the vendor can name an indispensable action. Even a legitimate “write checks” feature need not be enabled before the basic read assessment is understood.
Selected repositories limit the installation's repository set, but a vendor may mint an installation token with all permissions and repositories granted to that installation unless it narrows the request. GitHub states that an installation access token expires after one hour, and the issuing request can specify repository IDs and a subset of permissions (authenticating as an installation). Ask whether the tool uses those narrower options, where the token exists in memory, and how it handles an already running task after permissions change. Short life is useful, but it is not an immediate revocation or a guarantee that downloaded source disappears.
Consider webhooks separately. A tool that only needs a manual one-time review may not need push or pull-request events. If events are enabled, list event types, payload fields, signature verification, delivery retries and retention. A webhook may carry sensitive metadata even if the tool never clones the repository. Ask whether the vendor stores failed deliveries or logs raw payloads. Treat that answer as part of the source and metadata flow, not as a side note to app permissions.
Reconcile the install screen with the first job
Meridian's organization owner sees only payments-pilot-fixture selected and contents read permission. The vendor's connection wizard nevertheless asks the reviewer to authorize a separate user grant. The vendor explains that its optional PR workflow uses it. Meridian's pilot has no PR workflow, so the connection record excludes that grant. The installer cannot assume that the selected-repository screen bounds a second credential.
The vendor also asks for checks write permission “for the future.” Meridian declines it for the current phase. The resulting approval is concrete: one installation, one repository, contents read, manual job, private report, no additional user authorization or write-back feature. If the tool cannot operate with that scope, the decision becomes a product-fit question; the team does not silently approve a broader workflow.
The first synthetic job then provides a second kind of evidence. The permission screen defines maximum Git access, but the acquisition manifest identifies the actual revision and files. In this invented case the manifest includes a branch different from the approved pin. The tool had authority to read the repository, but did not perform the authorized assessment as specified. Meridian asks for a corrected pinned job and retains the failed manifest as evidence of the configuration mistake.
| Checkpoint | Fictional evidence | Connection decision |
|---|---|---|
| Before installation | Selected repository and contents read screen match approved workflow | Approve that installation only; separate user authorization declined. |
| First acquisition | Manifest identifies moving default branch rather than the agreed revision | Do not use that report as evidence for the approved commit; correct job binding. |
| Corrected job | Manifest matches pin, includes failed-read disposition and named report audience | Accept acquisition identity; coverage and findings still need their own review. |
| Boundary challenge | New job for unselected private repository refused | Supports selected-repository behavior for this path; does not audit all credentials. |
| Offboarding | New source read refused; an already fetched task copy remains pending cleanup | Git access removal complete for the check; vendor-copy deletion still open. |
These outcomes are an illustrative acceptance script, not observed behavior of any vendor. Do not ask the vendor to expose tokens or private keys to prove it. Redacted issuance metadata, installation readback and safe denied requests are sufficient to make the claim reviewable.
The stop exercise has two clocks
At 16:00 in the fictional exercise, the owner removes the repository. At 16:02, a queued acquisition is refused. A task that fetched source at 15:55 still has a local copy. Git revocation cannot recall those bytes. Meridian's approved job policy says disconnection cancels pending and active pilot work, so the vendor must separately show cancellation, prevention of new downstream processing, and the cleanup state of that existing copy.
The final connection receipt says “Git read refused after removal; job stopped; local source cleanup pending under the agreed maximum lifetime; retained report remains available only to the two approved reviewers.” If cleanup later completes, add its record and time. Do not replace the entire receipt with “access revoked and all data deleted.” A permission decision, a job-stop decision and a retention decision are three different facts.
Meridian can now decide whether to connect private production source using a record that shows what changed, what failed and what remains. The detailed mechanics of narrowing installation tokens belong in the Git permission implementation guide; this connection review checks that the integration actually honors the approved workflow.
Put each unresolved answer in the connection record
Before Meridian moves from the fixture to private source, the security leader should reconcile the vendor answers with the actual enabled features. A satisfactory answer about manual reads does not cover newly enabled PR feedback. A deletion demonstration for the fixture does not establish a different report-export schedule. Keep these differences as named conditions rather than reducing the review to one approved-vendor flag.
The record should also identify the installation owner who can act during an incident. If the only person who can change repository selection is unavailable, the nominal stop procedure may be unusable when it matters. Arrange that ownership through the organization's normal administration process and retain the tested steps without including live credentials.
The resulting handoff tells the operator what is approved, what evidence justified it, and which requested change requires another decision. That makes the checklist usable after the initial buying meeting.
Decide what may expand
Approve a broader rollout only after the pilot answers the material questions and the repository owners accept the resulting data flow. Use a change gate for new repositories, write permissions, event subscriptions, models, support exports and retention settings. Recheck the app configuration periodically because an installation can be modified after the initial review.
If a vendor says a requested permission is “standard,” ask which endpoint requires it and what happens if it is absent. If the answer is uncertain, keep the pilot narrow. A tool can still be valuable with partial access, provided both sides label the unreviewed scope honestly.
Next action: copy the question table into the connection request for one repository and attach the Git installation readback. Continue with how to assess where an AI vendor processes source and how to design a security-tool pilot without sharing all repositories.