"Connect your GitHub repo" sounds like a bigger ask than it usually is, and vendors rarely explain what the access actually covers. The honest answer depends entirely on scope: what the integration can read, what it can't touch, and whether you can revoke it without drama.
Here's what to actually check before approving the install, instead of relying on a vendor's reassurance alone.
Direct answer
Giving an AI support or documentation tool access to your GitHub repo is safe when the access is scoped through a GitHub App installation with only the permissions the tool's job requires (typically reading repository contents and pull request metadata), when the integration reads merged code changes rather than writing to your codebase, and when you can revoke the installation from GitHub's own settings at any time without depending on the vendor. It becomes a real risk when a tool asks for broader permissions than its stated job needs, can't explain what it does with webhook payloads, or doesn't support per-organization scoping in a multi-tenant product. Ask for the specific permission list before installing, not just a description of what the product does.
What "access to your repo" usually means in practice
- A GitHub App installation, not a personal access token. Modern integrations should install as a GitHub App scoped to specific repos, with permissions you can review and revoke from GitHub's own settings, not a broad token pasted into a vendor's dashboard.
- Read access to code and pull requests, for a docs-drafting tool, the job is reading merged diffs and PR metadata, not writing to your codebase or executing code in your CI pipeline.
- Webhook events on merges, the integration is typically notified when a PR merges and pulls the diff, rather than continuously scanning your entire repository.
- No write access to your source code. A legitimate docs or support tool has no reason to open commits, push branches, or modify files in your repository.
Questions worth asking before you install
| Question | Why it matters |
|---|---|
| What exact permissions does the GitHub App request? | GitHub shows this at install time, review it rather than clicking through |
| Does it request write access to code, and if so, why? | A docs or support tool reading diffs has no legitimate need to write to your repo |
| Is the webhook payload verified (signature-checked)? | Prevents a forged request from triggering the integration as if it came from GitHub |
| Can I revoke access myself, from GitHub, without contacting support? | Confirms you're not locked into a vendor relationship to remove access |
| Is repo access scoped per organization/tenant, or shared infrastructure? | Matters if you're on a multi-tenant SaaS platform where other customers' data lives in the same system |
How DocsKoala approaches repo access
DocsKoala connects via a GitHub App installation scoped to the repositories you choose, not a broad personal access token. It reads merged pull request diffs to classify and draft documentation updates; it does not write to your codebase, open commits, or execute code. Webhook payloads are verified against GitHub's signature before anything is processed, and installation access is claimed per organization, so one customer's install can't be squatted or read by another tenant.
Frequently asked questions
Does an AI docs tool need write access to my repository?
No, a tool whose job is drafting documentation from merged changes only needs to read pull request diffs and metadata. Any request for write access to your source code is broader than that job requires and worth questioning.
Can I limit which repositories an AI tool can see?
Yes, GitHub App installations let you scope access to specific repositories rather than your entire organization. Choose the narrowest scope that covers the customer-facing code you actually want reflected in documentation.
How do I revoke access if I stop using the tool?
Through your GitHub organization's installed-apps settings, you can uninstall the GitHub App directly, independent of the vendor. If a tool can only be disconnected by contacting their support, that's a sign the integration isn't scoped the way it should be.
Does read access mean the tool can see secrets in my code?
It can technically read whatever is in the repository content it's scoped to, which is why secrets and credentials should never be committed to source control in the first place, independent of which third-party tools you connect. Scoping access to specific repos limits exposure but doesn't replace basic secret hygiene.
Conclusion
- Safety comes down to scope: read-only, GitHub App-based, revocable, and limited to what the tool's job actually requires.
- A legitimate docs or support tool has no reason to request write access to your source code.
- Ask for the exact permission list before installing, and confirm you can revoke it yourself from GitHub.
- DocsKoala reads merged PR diffs only, verifies webhooks, scopes access per organization, and gates all output behind human approval before publish.