Repository access and credentials

Access belongs to a provider target

Guard connects to the exact GitHub installation or GitLab host and repository paths selected during setup. Repository access lets the product collect source and provider evidence; it does not transfer repository ownership or bypass provider permissions. If the provider no longer permits an operation, Guard must take a limited or no-write path.

GitHub access

GitHub repositories are connected through a GitHub App installation. The installing organization or user controls which repositories the app can access and can change or revoke that installation in GitHub. Guard uses installation-scoped access for the selected repositories rather than asking the user to paste a personal token into each job.

Depending on the published workflow and granted permissions, provider access can support repository reads, issue and pull-request lookup, review comments, and bounded improvement artifacts. A read-only audit itself still makes no repository write.

GitLab access

GitLab uses an explicitly configured host and credential. The current setup contract calls for api, read_repository, and write_repository scopes so Guard can read repository evidence and, for enabled write-capable workflows, create provider artifacts. Self-hosted instances also need a reachable, correctly configured base URL.

The credential belongs to the person or organization that issued it. Expiry, revocation, user removal, host changes, or reduced project membership can stop future runs. Guard should report the access failure rather than search for a different credential or repository.

Read and write are separate decisions

Having provider permission does not mean every run may write. Audit runbooks are read-only. Code review can post only its scoped provider reply. Improvement Jobs also require a supported write mode and runbook safety gates before creating an issue or review request. Auto-pentest needs separate active-target consent even when repository access is healthy.

Review and revoke access

Periodically compare connected repositories with the projects Guard should still monitor. Remove a repository from a Guard project when it is no longer in scope, and revoke or narrow provider credentials at GitHub or GitLab when the organization no longer authorizes access. Disconnecting Guard does not delete the provider repository; it can cancel in-flight work and turn off related recurring schedules.

Never paste provider tokens, private report content, or repository secrets into support requests. Share target identifiers and redacted error context instead.