Integration
Connect GitHub to Polaris
Fine-grained tokens let you hand over three repositories instead of an account, which is the whole reason to use them here.
What connecting buys
Connecting GitHub gives a Polaris worker the repositories, issues and pull requests inside a fine-grained access token's scope. Polaris verifies the token against GitHub before storing it and shows the account login it came back with. Scope the token to the repositories workers need and choose read-only permissions where writing is not part of the job.
- Credential
- Fine-grained access token
- Verified live
- GitHub returns the account login
- Scope control
- Per repository, at GitHub
Scope the token, not the trust
GitHub's fine-grained tokens are the reason this connection is comfortable to grant. You pick the repositories, you pick the permissions, and the token cannot reach anything you left out. A worker that only writes documentation does not need write access to production infrastructure, and a token is where that decision gets enforced.
Polaris checks the token by asking GitHub whose it is, then shows you that login in the connect panel. If the login surprises you, that is the check working.
What the connection gives a worker
Everything below is bounded by the token you created. Narrow the token and this list narrows with it.
The repositories you named
Not the organisation, not every repo the creator can see. A fine-grained token lists its repositories explicitly and that list is the worker's world.
Issues and pull requests
The raw material for triage write-ups, release notes and the summary of what changed this week that nobody has time to assemble.
Whatever the permissions allow
Read-only stays read-only inside Polaris. There is no privilege escalation path in the product, because the credential is used as given.
Context to write from
A technical writer working from real code and real pull-request discussion produces documentation that matches the repository rather than the intention.
Scoping decisions worth making before you paste
Polaris cannot make these for you. GitHub is where they are enforced.
| Decision | Safe default | When to widen it |
|---|---|---|
| Which repositories | The specific repos workers are briefed on | Never widen speculatively; add repos when a task needs one |
| Read or write | Read-only | Only if you intend workers to open issues or pull requests |
| Which account | A machine account or a member with matching access | Avoid keys made on an admin account entirely |
| Expiry | The shortest expiry your workflow tolerates | Longer only where re-authorizing is genuinely disruptive |
Workers and work this connection feeds
Hire an AI technical writer
The documentation debt on your team is not a writing problem, it is a nobody-has-two-free-hours problem, and this is the worker for those two hours.
Hire an AI QA engineer
Fourteen vague reports go in, fourteen tickets with steps, expected behaviour and a severity come out, with the three duplicates already merged.
Hire an AI project coordinator
The unglamorous half of running projects, done every week without anyone having to be the person who nags.
Six open pull requests and nobody knows whose turn it is
The review queue, ordered by age and named by who is blocking it, posted every morning.
The README describes a version of the code that no longer exists
A monthly list of statements in your docs that the code no longer supports.
The incident ended and the writeup never started
The timeline assembled from the channel and the deploy history, with the gaps left honest.
Questions people ask
+Does Polaris need admin access to my GitHub organisation?
No. A fine-grained personal access token scoped to specific repositories is what the catalog asks for, and it is the right answer. There is no GitHub App install, no organisation-wide permission request and no reason to hand over more than the repositories in play.
+Can an AI worker push code or merge a pull request?
Only if the token you created allows it. Permissions are set at GitHub, and Polaris uses the credential exactly as issued. A read-only token stays read-only no matter what a worker is asked to do.
+How does Polaris verify a GitHub token?
It calls GitHub's user endpoint with the token before storing anything. A rejected token produces GitHub's status code as an error and nothing is written. A valid one comes back with the account login, which the connect panel shows you.
+Is GitHub a good connection for a non-engineering worker?
Sometimes. A technical writer or a project coordinator reading issues and pull requests is doing legitimate work with it. In those cases give read-only access to the specific repositories they write about, and nothing else.
Related
Every tool a Polaris worker can be given
One catalog, one credential per tool per organisation, authorized by an owner and used by every worker who carries it.
Hire an AI technical writer
The documentation debt on your team is not a writing problem, it is a nobody-has-two-free-hours problem, and this is the worker for those two hours.
Hire an AI QA engineer
Fourteen vague reports go in, fourteen tickets with steps, expected behaviour and a severity come out, with the three duplicates already merged.
Six open pull requests and nobody knows whose turn it is
The review queue, ordered by age and named by who is blocking it, posted every morning.
Replacing Linear, Notion and GitHub
Three tools a technical team chose on purpose, and none of them has to move anywhere.
How an AI worker gets tool access
The interesting part of tool access is not the list. It is where the credential lives and who can read it.
Connect Linear to Polaris
A Linear API key carries one person's visibility, so the account you make it on decides what every worker can see.