## 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

```text
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