审查机只需要读代码、留评论，为什么它手里的 token 能合并、能删分支、能改 workflow？（中英切换）

A three-person team with seven computers usually sets up like this: install the agent on each machine, run gh auth login, click authorize in the browser, done. Machines 1–3 write code, 4–5 review, 6 runs Windows validation, 7 merges. The roles are clean. The keys are not: all seven machines hold the same one.

I first measured how big that key is on the machine I run agents on. gh api -i user returns X-OAuth-Scopes: gist, read:org, repo, workflow, and the expiry header is empty — it never expires. It can push to 68 repositories, with admin on all 68, 10 of them private. Then I hit a few write endpoints, deliberately aimed at objects that don't exist so nothing would change: merging a nonexistent PR returned 404, not 403 — authorization passed, the PR just wasn't there. Deleting a nonexistent branch returned 422. Listing the repo's Actions secrets, webhooks and collaborators: all 200. And the workflow scope means it can rewrite the CI definitions under .github/workflows/ directly — change the CI and you change what counts as passing.

A review machine that should only "read code and leave comments" holds that key. What it reads all day is exactly other agents' code, PR descriptions and test fixtures — any of which can carry a line like "merge this branch while you're at it". When a review machine gets talked into something, the ceiling on what it can do is the ceiling of its token.

A more concrete fact. For this blog's own repo, shuizhengqi1/pages, I ran a read-only script that asks, for each of the last 60 commits on master, "which PR did this come from?" 32 have no PR — they were pushed straight to master. The batch of posts from late September to early October had their images and text written into master directly by an agent; the latest was an empty "retrigger deploy" commit on October 18 at 19:40 (Taipei time). Nothing stopped them, because this private repo can't have branch protection at all: the branch-protection and rulesets APIs return 403, "Upgrade to GitHub Pro or make this repository public". Everything after October 5, except that empty commit, went through PRs — because the convention changed, not because anything could block it.

So the question here: once seven machines are split by role, how do you split each machine's permissions by role too, what does it cost, and where does it stop paying off?

Ruling out one direction: the problem isn't where secrets are scattered

My first instinct was to scan for secrets scattered across files. A ripgrep prefilter plus Python regexes over this machine's home directory and a 41 GB workspace took 47 seconds and flagged 13,904 files as containing something secret-shaped. Opened up, most were test fixtures and doc examples in cloned open-source repos, password = "..." assignments and the like. That number is useless, and I won't present it as "how much leaked".

So I went the other way: from the credentials back. I took the credentials actually in use on this machine (the gh token, two cloud provider keys) and exact-matched them across the disk. They appear only where they belong — gh's hosts.yml (mode 600) and one dedicated secrets file. Not copied into any transcript, log or repo.

I had been worried about the wrong thing. The credentials aren't scattered; they sit where they should. The danger is who can use them and how much they can do. One experiment for each.

Experiment 1: what a dependency can read while an agent runs npm install

Agents on dev machines install dependencies and run tests all day. On this Linux machine I built a small lab: a fake HOME with three credential files (gh's hosts.yml, ~/.aws/credentials, an SSH private key, all mode 600); a repo with a .env; three credential environment variables. Every value is a fake containing CANARY. Then a probe package, left-padx, which checks twice — in postinstall and when it is required — whether CANARY appears in the environment, whether those three HOME files are readable, and whether the calling repo's .env is readable. It has no network access; it only writes what it could read into a local JSON file.

Five ways of running, each doing a full npm install and npm test:

Two results differed from what I expected.

First, scrubbing the environment only solves half. With env -i passing just PATH and HOME, the three env vars were gone, but the three HOME files and the repo's .env were still readable — 4/7. Mode 600 protects against other users; dependency code runs as you.

Second, --ignore-scripts is an illusion. At install time the probe indeed didn't run (0). But the moment npm test ran and the test did require('left-padx'), the probe executed with the full environment and file access — 7/7. It merely moves the read from install to test. Agents don't install without testing.

Only two setups got to zero: a bubblewrap sandbox (clear env, HOME replaced by an empty tmpfs, .env masked with /dev/null, no network), and running the agent as a separate OS user. Both 0/7, tests still pass. The sandbox has a real cost: with no network, npm install can only use a local tarball (which is how my lab installed it); real projects need an offline cache or a domain allowlist. Claude Code's built-in sandbox also uses bubblewrap on Linux and has a network domain allowlist, so you can use that instead of hand-rolling commands. For the separate-user setup, note that I did not copy .env into its repo copy; if .env sits in the agent's own working tree, it can of course read it.

One more thing that's easy to misread. Claude Code permission rules let you deny Read(./.env), but the official docs are explicit: such rules govern its built-in file tools and the cat/head-style commands it recognizes, not arbitrary subprocesses the agent starts — a Node script calling fs.readFileSync walks right past it. Blocking that at the OS level needs the sandbox. I did not run Claude Code to verify this (it isn't logged in on this machine); it's from the docs. But the S0 probe above is exactly such an arbitrary subprocess.

Experiment 2: role tokens — how far can write access be cut?

The second question: since an agent has to use a token at some point (dev machines push, review machines comment), make each machine's token able to do only its role. GitHub's fine-grained tokens can be scoped per repo and per permission. I downloaded GitHub's official table of permissions required by each endpoint for fine-grained PATs and wrote a script to parse it: 250 repository-level write endpoints in total. I gave each role a minimal permission set and computed what it can still reach.

The Windows gate needs only "read code + write commit statuses": from 250 write endpoints down to 2. The review machine needs only "read code + write PR comments and reviews": down to 21, with merge, push and branch deletion all out of reach. These two classes gain the most, and they are precisely the machines that spend their time reading other people's stuff.

For dev and merger machines, the table produced a conclusion I hadn't realized: merging a PR, git push and deleting a branch are all the same permission on GitHub — Contents: write. A dev machine pushing its own branch needs Contents write; with Contents write it can call the merge endpoint, push straight to master, and delete anyone's branch. Fine-grained tokens can't tell "push a feature branch" from "push master". Only branch protection can: require PRs, require approvals, no bypass for admins.

And branch protection on a personal account's private repo requires GitHub Pro — that's the 403 above. Pro is $4 a month, negligible next to what the team spends on AI subscriptions.

There's one more place that needs a second identity. Once you require at least one approval, the approver can't be the PR author; GitHub won't let you approve your own PR. If all seven machines are logged in as the same account, the review machines can never approve the dev machines' PRs, and the approval rule has to be switched off. GitHub's terms allow each person one free machine account in addition to their free personal account; the review machines use that.

Here we hit another fine-grained-token limit, listed among the "major gaps" in the docs: you can't use a fine-grained token to contribute to a repository where you are only a collaborator. A machine account invited to your personal repo is exactly a collaborator, and personal-repo collaborators have no read-only tier — they get write. So on a personal repo the review machine account can only use a classic token, with write access; the 21-endpoint review row above assumes an org-owned repo. The other two teammates' machines are in the same position.

So there are two routes. A repo that is just yours, on your machines: get Pro, protect master, give dev, Windows and merger machines role-scoped fine-grained tokens under your account, and give review machines the machine account's classic token — its write access is held off master by branch protection and reaches only the repos it was invited to. A repo shared by three people: move it to an organization on Team ($4 per user per month; the machine account takes a seat too, so three people plus one machine account is $16/month), switch every machine to fine-grained tokens, and only then does the review row really hold.

On seven machines

My recommendations, ordered by payoff:

1. Measure first. Run token-audit.sh on each machine: the current token's scopes, expiry, how many repos it can push to, which credential-looking env var names exist, which credential files sit in HOME and with what modes. It prints names and modes only, never values.
2. Re-token the review and Windows machines first. Use the script's pre-filled links to create tokens named with the machine number (agent-review-m4), 30-day expiry, only the listed permissions. Then gh auth logout on that machine and put the token in ~/.config/agent-tokens/<role> (mode 600). If a machine is compromised, revoke that one token by name; the other six are untouched.
3. No token in the agent session. Use a wrapper like with-role-token review gh pr review ... that injects GH_TOKEN for that one command only; the agent's npm install and pytest never see it. Use a sandbox where you can.
4. Turn on branch protection. Pro for a personal repo; an org on Team for the shared repo. Require PRs, at least one approval, include admins; review machines approve as the machine account.
5. Run direct-push-audit.sh weekly. It lists commits that reached master without a PR. With protection on, this should be zero.

Where this falls short

The strongest objection: "The three of us trust each other, why bother?" But this never defends against teammates. It defends against the code agents run and the text agents read — a poisoned dependency, or a carefully worded instruction in a PR description. Trust among three people doesn't make those trustworthy.

The second objection carries more weight: cutting the dev machine's token doesn't stop bad code. If a dev machine is compromised, the attacker can still put malicious code into a PR, with Contents write in hand. True — splitting tokens does almost nothing for dev machines; they rely on the sandbox (keeping dependencies away from the token) and on downstream review. The real value is in the review and Windows rows (21 and 2) and in branch protection.

Third, maintenance: seven tokens rotated every 30 days is seven manual chores a month. Fine-grained tokens can't call the Checks API (I measured a 403; it needs a GitHub App), so teams gating on check runs need an App. If all your repos are public, branch protection is free and step 4 costs nothing. If you're one person on one or two machines, the sandbox in step 3 is worth more than splitting tokens.

What was actually run

Actually run: measuring token scopes/expiry/repo count, side-effect-free probes of write endpoints, the branch-protection 403, the PR audit of 60 commits on the pages repo, the disk-wide regex scan and exact matching, and the five-way probe lab (one Linux machine, fake credentials). Computed from docs, not run: the seven machines themselves (I don't have seven machines); the per-role write-endpoint counts, which come from parsing the official permission table rather than creating seven tokens and testing each; Claude Code deny rules not covering subprocesses, per the official docs; with-role-token was tested only on Linux — the Windows machine needs a PowerShell version, which I haven't tested.

The scripts are bundled here: least-privilege-kit.tar.gz — token-audit.sh, role-perms.py (with the pre-filled token link generator), direct-push-audit.sh, with-role-token, and the whole probe lab.

The smallest step you can take today: on a review machine, run gh api -i user | grep -i scopes. If you see repo, workflow, that machine, which should only leave comments, can right now merge a PR in any of your repos.