Skip to main content
The GitHub integration gives you the same judgment you ran by hand, on every pull request — and the outcome afterwards, joined back to it. One workflow file, one Change record per pull request. The repository proves who it is with a short-lived identity token GitHub issues to the workflow, so there is no ChangeGuard key to create, no secret to paste, and nothing to rotate. You never open GitHub’s Settings. The guided setup lives in two places, and they are the same card: at the bottom of Preflight, and under Settings → Integrations as GitHub Actions — every pull request.
1

Connect GitHub

Press Connect GitHub. GitHub asks you to authorize the ChangeGuard app for your organization or account and to choose which repositories it may see. This is the one place a human has to click — GitHub requires it. Nothing is copied.
2

Which repository?

Pick the repository from the list. Everything below points here.
3

Which environment does this repository deploy to?

Choose the environment you connected in step 4 (or I’ll connect one later). The choice is saved on the repository’s connection in ChangeGuard AI. It is never written into your repository, so a workflow cannot point judgments somewhere else.
4

What should ChangeGuard record?

A verdict on every pull request is always on. Turn on …and what happened after each deploy to have the workflow run your deploy after a non-blocking verdict and report the outcome back (step 7). Nothing in the file changes either way.
5

Add the workflow file

Add it as .github/workflows/changeguard.yml — use Copy this file, or Open it on GitHub, already filled in and press Commit changes. ChangeGuard AI never commits to your repository itself. The file is short and does not change as ChangeGuard AI improves, because the logic lives in the ChangeGuard-AI/action repository:
The two permissions lines are what let GitHub issue the identity token: id-token: write only permits asking for that token; it grants no access to your code.
6

Open a pull request

The verdict appears in the pull request’s checks and in the run summary — SHIP, HOLD or BLOCK with the reasons. BLOCK fails the check; HOLD never does. To start in advisory mode while you build confidence, add enforce_block: false under with: — the verdict is still recorded either way.
7

Verify

ChangeGuard AI cannot see inside your repository, so it cannot tell whether the file was committed. Once a pull request has run, press Verify integration: it confirms that a real verdict from the workflow reached ChangeGuard AI. A workflow file that exists but never ran is not an integration.
Don’t want to wait for a pull request? Run your first Preflight on the same card judges the connected repository against its environment right now — same engine, same Change record.

​
How the repository is trusted

The workflow sends GitHub’s identity token to ChangeGuard AI. ChangeGuard AI verifies the token with GitHub and looks the repository up among the connections you created; nothing in the request can name a tenant. If the repository is not connected, or is connected by more than one account, the judgment is refused rather than guessed. The environment is bound to the connection, so the judgment names the environment you chose — never one the workflow could invent.

​
Other pipelines

GitLab, Jenkins, Argo, a script: any pipeline can call the same judgment with an API key you create under Settings → API Keys (scope cicd). See Use the verdict in CI. GitHub is the only integration that needs no key. Next: 6. Judge a real proposed change.