Who runs what

Redline writes into repositories and walks an organisation. Anything that does that owes you an exact account of what it can reach. Every claim below names the file it comes from, so you can check it rather than believe it.

Tier 1 — you, on your own machine, in one repository

redline init, redline verify, redline review and redline remove. You run them from a checkout, in your own shell.

• Credential: your own git auth, and nothing else. cli/platforms/github/client.ts resolves GH_TOKEN ?? GITHUB_TOKEN from the environment and falls back to gh auth token. Redline never mints a credential, never stores one, and never writes one into the repository — .redline.json records the profile, the vendors, the menu choices and the pending-admin list, and no secret.
• Reach: the one repository you are standing in. Both init and remove land as a pull request, not a push.
• It cannot reach a second repository, and it cannot act on the organisation. Estate-wide work is sync and metrics, which are Tier 3 and refuse to be useful without a token you had to create yourself.
• Without repo-admin rights it still works. Whatever your token cannot reach is recorded rather than skipped — see Onboard a repository.

redline review needs no token at all

The default embedded engine calls no model: it emits the bounded prompt for the assistant that is already running the command. The api engine calls an endpoint — and its OpenAI-compatible default base URL is http://localhost:11434/v1, which is Ollama's. cli/review/engines/api.ts treats localhost, 127.0.0.1 and [::1] as local and skips the API key requirement entirely — the comment on that branch reads “a local endpoint legitimately needs no key”. Point it at a local model and your diff does not leave the machine.

$ redline review --engine api --model qwen2.5-coder:14b
  endpoint  http://localhost:11434/v1   (local — no API key required)
  local findings are excluded from rule-tuning telemetry

A remote endpoint is the opposite case and is treated as one: without a key the run fails rather than sending an unauthenticated request that would break confusingly at the far end. See Reviewing before you push.

Tier 2 — the onboarded repository's own CI

redline policy and redline exempt. You do not run these; the gate does, via workflows/redline-gate.yml — hosted in the org .github repository and called by the thin .github/workflows/redline.yml each onboarded repo carries. Both are invoked as npx --yes redlinegate@<pinned version>.

• Credential: the run's own repo-scoped GITHUB_TOKEN. The whole grant is the workflow's declared block, and it is three lines long.
• Reach: the pull request it was triggered by, in its own repository. A repo-scoped token cannot address another repository, so neither can the gate.
• No model call. redline policy evaluates only the deterministic rule tier and exits 1 on a finding at or above the rung's floor. The reviewing model, wherever it runs, is a separate concern from the gate.

permissions:
  contents: read
  pull-requests: write   # to post findings on this PR

Tier 3 — the platform team, on a schedule

Two credentials, and the distinction between them is the reason this page exists. Neither is created by redline init: a human on the platform team makes them and stores them as secrets on a central repository. Onboarding a repository grants Redline nothing.

Read-only: REDLINE_ORG_READ_TOKEN

The entire measurement plane runs on it — redline metrics collect | dashboard | digest | inbox | baseline | roi | correlate | context | score-seeds and redline registry, driven by redline-collect.yml, dashboard.yml, inbox.yml, weekly-digest.yml, verify-onboarding.yml and .github/workflows/registry.yml. It observes the estate and writes nothing to it. redline-collect.yml says so at the point of use: “Read-only: repo metadata + pull requests across the org. No write scope.”

Those workflows do declare contents: write or pages: write in places — redline-collect.yml commits the collected JSONL, registry.yml commits registry.json, the dashboard and inbox publish to Pages. Those permissions apply to the central repository the job runs in, never to the repositories being measured. The only credential that reaches out across the estate on those jobs is the read token.

Narrowly-scoped write: REDLINE_SYNC_TOKEN

One workflow, one command: workflows/redline-sync.yml running redline sync. Its required scope is documented inline where the secret is consumed — contents:write, pull_requests:write, workflows:write on target repos, the last because pushing .github/workflows/redline.yml is otherwise rejected.

• It opens pull requests. The header of that file is explicit: standards are distributed “never as direct pushes, and never as a merge”. What a repository does with its sync pull request is the repository's decision.
• Its targets are derived, not listed. They come from registry.json, discovered nightly from the .redline.json each onboarded repo carries. A repository that runs redline remove leaves the register and stops being a target without anyone editing a list.
• It refuses to distribute stale artifacts. The job runs render-self.mjs --check before it opens anything.

A third, deliberately separate one: REDLINE_CANARY_TOKEN

workflows/seed-canary.yml opens a throwaway pull request of known-bad code against a canary repo weekly to regression-test the reviewer itself. That needs write access, so it gets its own token, and the file says exactly how far it goes:

#   secrets.REDLINE_CANARY_TOKEN   contents:write + pull_requests:write on the canary
#                                  repos ONLY. Never an org-wide token.

Three write-capable credentials could have been one. They are three because a token that can do everything is a token nobody can reason about.

Tier 4 — Redline's own maintainers

scripts/validate.mjs, scripts/assign-rule-ids.mjs, scripts/render-self.mjs and scripts/check-pins.mjs, run by .github/workflows/ci.yml and release.yml in this repository. They act on this repository's own standards/ and pinned actions — Redline enforced on Redline. Nobody installs the CLI to run them, and they need no credential beyond the CI run's own.

check-pins.mjs is the only one that needs network: it re-resolves every SHA-pinned third-party action against the tag its trailing comment claims. It runs as its own CI job here, and only here — the gate references it in a comment explaining where its own pin is reviewed, but does not invoke it in your repository.

What this means for you

If you want the repository-level view instead — what init installs and what it asks an administrator for — see Onboard a repository, and Removing Redline for taking it back out.