review agent posted as the repo owner because its token was over-scoped: how to fix

TL;DR

Stop using the owner's personal credential for automation. Create a GitHub App (or a fine-grained personal credential) scoped to the single repo with only pull-requests write and contents read, mint a short-lived credential per run, and revoke the over-scoped owner credential. Bot actions should never wear a human's identity.

The problem

review agent posted as the repo owner because its token was over-scoped: how to fix

When to use

• Bot reviews and comments appear under the owner's name and avatar
• A personal credential with broad scopes lives in CI secrets for automation
• Commits pushed by automation are attributed to the owner
• Audit logs cannot distinguish bot actions from the owner's actions

When not to use

• A GitHub App is already posting under its own identity (working as intended)
• The wrong identity comes from git config user.name on commits (a checkout config issue)
• You intentionally want the automation to act as a specific user

Steps

1. Confirm which identity and credential are in play

Check the review's author field via the API and compare it to the credential stored in CI secrets. Note the credential's scopes: broad scopes on a personal credential are the smoking gun.

Expected output: confirmation that the poster is the owner account and the credential is a personal one with more scope than the job needs.

2. Create a least-privilege automation identity

Create a GitHub App installed on the single repo with only the permissions the reviewer needs (pull requests write, contents read), or a fine-grained personal credential limited to that repo with the same minimal scopes.

Expected output: an automation identity whose blast radius is one repo and a few permissions.

3. Mint a short-lived credential per run

In CI, mint an installation credential at job start and use it for the review steps. Never store a long-lived owner credential in repo secrets for automation to use.

Expected output: credentials that expire after the run; a leaked value is useless within the hour.

4. Rotate and revoke the over-scoped owner credential

Generate a replacement for anything legitimate still using the old credential, then revoke it. Expected output: the owner credential can no longer post as the owner from automation.

5. Re-run one review and verify the author field

Post a test review and check the author via the API. Expected output: the app or bot identity, not the owner.

Tool compatibility

• GitHub Apps installation credentials: the recommended path; fine-grained and short-lived; available on github.com and GHES.
• Fine-grained personal credentials: acceptable when an App is overkill; scope to one repo.
• gh CLI 2.x: works with either credential type via standard auth.

Variant phrasings

bot comments show up as the repo owner

Same fix. Also check the checkout step: persist-credentials can leave the triggering user's credential in git config, affecting pushes even after the API identity is fixed.

automation using my personal access credential

Migrate it to the App model in step 2. Personal credentials in shared automation are also a rotation headache when the human leaves.

review posted by wrong GitHub account

Verify with step 1 whether the wrong account is the credential identity (this fix) or just the commit author config (then fix git user.name/user.email in the job).

Why it happens

The quickest way to give a bot API access is to paste in a personal credential, and the most available one belongs to whoever set up the automation - usually the repo owner. It works, so it ships, and from then on every bot action wears the owner's identity with the owner's full permissions attached.

Edge cases

• Checkout with persist-credentials: the git remote keeps the job credential; set git author explicitly for any commits the job creates.
• Reusable workflows: secrets inherit into called workflows; audit the whole chain, not just the top workflow.
• GHES with restricted App permissions: confirm the App permission model covers review posting before migrating.
• Existing open PENDING reviews by the old identity: submit or dismiss them before revoking, or they orphan.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_nGIfTwEtavH46Gj6GZGubg