The Mail Slot

What you'll be able to do: let a machine act on your project without giving it the keys to everything — grant any agent a scoped, expiring, revocable channel into a protected repo, and prove both that the channel works and that the secret behind it never leaked.

Choose your door

Builder — open the fine-grained token form and just look at it — repos, permissions, expiry — before you create anything.
Architect — see the three separated parts first: the credential, the store, and the channel that reaches GitHub.
Translator — a fortress with no doors gets a mail slot, sized for envelopes and not people. Start at the Bridge below.
Validator — confirm branch protection, which repos the agent needs, and a secret store outside every file before you start.

Translator Bridge

A bank doesn't give the armored-car company a vault key. It gives them a badge that opens the loading dock — two doors, business hours, expires quarterly, revocable from the front desk. Deliveries flow; the vault stays bank-only. The token is the badge; the env var is the badge printer's safe; the MCP server is the loading dock itself.

Where the analogy ends: a badge names its holder; a token authenticates whoever possesses it. Steal the badge and a guard might notice the face; steal the token and GitHub cannot tell. That's why the secret's handling matters more than the badge's scope — and why it never goes in a file, a chat, or a command that gets logged, and why it expires.

Builder Track (DO FIRST)

Mint the badge (browser — deliberately human-only; GitHub offers no API for this). Fine-grained PAT: only the two repos; Contents + Pull requests read/write; Actions read-only; nothing else; 90 days. You should see: the token exactly once, on screen.
Store it in the safe, blind. A PowerShell secure prompt (Read-Host -AsSecureString) into a user-scope environment variable. You should see: nothing — that's the point. Verify with a substring: first 14 characters only.
Cut the slot. Register the official remote GitHub MCP server with the auth header written as the literal placeholder ${GITHUB_MESH_PAT} — single-quoted so the shell can't expand it. You should see: config on disk containing the placeholder text, not the token. Grep the file to prove it.
Prove the read path — and distrust good news. A one-shot agent subprocess, allowed exactly ONE tool: list PRs. Mine answered "zero open PRs" — which I verified against a second channel (gh) before believing it. An empty answer that flatters you is exactly the one to check.
Prove the write path with a real errand. Have the agent create a branch, commit a file change, and open a PR entirely through the new channel — no local git. Mine wrote its own log entry into the build's running state file: the proof documents itself. You should see: a PR authored by the channel, gated by CI, merged by a human.

Architect Track (MODEL FIRST)

Three parts, strictly separated: the CREDENTIAL (a fine-grained token = what the channel may do), the STORE (an environment variable = where the secret lives, outside every file), and the CHANNEL (an MCP server registration = how the agent reaches GitHub). The config references the store by NAME (a ${VAR} placeholder); the secret itself never enters any file, command line, or log.

Why three separations instead of one convenience: if the credential leaks, scope limits the blast (two repos, no admin, no merge); if the config leaks, there's nothing in it (a placeholder name); if the agent misbehaves, the channel is one revocation away from dead — without touching the fortress. Compare the failure modes of the shortcuts: a token in a config file is leaked by any backup, sync, or paste of that file; a token on a command line is leaked to shell history and logs; reusing a human's broad login (like gh's OAuth) means the agent inherits everything the human can do, including the things you specifically never want automated. The mail slot's entire value is what it CANNOT do. Note also the two-channel doctrine: the orchestrator keeps its own read/review channel, separate from the mesh's write channel — eyes and hands on different circuits, so blinding one never severs the other. And merge-to-main stays outside the credential entirely: the branch-protection lock doesn't care whose token asks.

Validator Gates

Pass each gate before moving on. These are permission to advance, not hazing.

Gate 1: The token exists in exactly one place (the env-var store) and appears in zero files — and I grepped the config to prove it.
Gate 2: The agent listed real data through the channel, and the result was cross-checked against a second source.
Gate 3: The agent opened a real PR through the channel, and the PR could NOT be merged by that same channel — only by me.
Gate 4: I know the two revocation moves cold: delete the token at GitHub (kills the badge) and remove the server registration (bricks the slot).
Gate 5 (own words): Why must the config hold the variable's NAME and not its VALUE?

Lesson complete — you can now give a machine hands that reach exactly two rooms and nothing else, and prove it. Next: Lesson 2 — The Depth Chart, which staffs the minds that will use those hands.