Inject GitHub auth at the MITM proxy so agents never hold tokens; tighten shared token cache perms

[clubanderson]

Current state

Agents authenticate to GitHub three different ways, each with a weakness:

1. git → credential helper (git-credential-hive.sh): good — UID-verified, mode-gated — but only covers git.
2. gh CLI → per-agent scoped token file after 🔒 fix: teach agents gh auth via their per-agent scoped token #1860 (previously agents improvised with the shared cache).
3. Shared gh-app-token.cache → 0640 group node, readable by every agent UID. Any agent can cat it and skip the helper's UID/mode gate entirely, holding an unscoped app token. The MITM proxy's mode enforcement then stands alone.

Proposal

The proxy already MITMs api.github.com and inspects every request per agent mode. Complete the design:

1. Proxy-side auth injection: for requests the mode check allows, the proxy strips whatever Authorization header the agent sent and injects a token minted server-side for that agent's tier. Agents then need no token material at all — gh works with a dummy GH_TOKEN=hive (gh requires the variable to be non-empty), and token theft between agents becomes structurally impossible. This also finishes the story started by the ${GH_AUTH} text ("authentication is handled in transit"), which today is only true for the CA layer.
2. Tighten the shared cache to 0600 once nothing but the hive runtime (UID 0/dev) needs it — the credential helper runs as the agent but can be given a setuid-free path via a tiny local token broker (unix socket) if needed.
3. git via injection too: once injection exists, the credential helper can hand out a dummy credential and rely on the proxy, keeping the mode gate as a fast local pre-check.

Why now

Field debugging (2026-07-13/14) showed an agent independently discovering the shared-cache read within one session when its push failed — the gap gets found under pressure. Two layers were designed; today only one holds once a token leaks sideways.

Related: #1860 (interim: per-agent scoped tokens for gh), #1849/#1850/#1856/#1858 (this week's config/enforcement hardening).

[Om-Beast]

Hi @clubanderson, thanks for the detailed proposal.

I'd like to work on this feature. I'll start by reviewing the current authentication flow, the MITM proxy implementation, and the related issues (#1860, #1849, #1850, #1856, and #1858) to understand the existing design before proposing changes.

My plan is to first identify the integration points for proxy-side authentication injection, verify the impact on both git and gh workflows, and share an implementation approach before opening a PR to ensure it aligns with the project's architecture.

Please let me know if this issue is already being worked on. Otherwise, I'd be happy to take it.

[clubanderson]

Triage — verdict: keep open, but re-scope: item 2 is DONE, item 1 is the only architectural work left — and it should wait

Re-read against origin/v4 @ 7cd059b7. This is an architectural change, not a patch; no implementation attempted. Deliverable here is scope + current blockers.

What has changed since July — item by item

Item 2 (tighten the shared cache to 0600) — ✅ ALREADY DONE. This was the concrete, non-architectural half of the issue and it has shipped. bin/gh-app-token.sh:60 does chmod 600 "$CACHE_FILE", and per-agent caches are written 0o600 (v2/pkg/agent/manager.go:599,651). Landed via 69256ecf (#2747, audit H3). The premise in the issue body — "0640 group node, readable by every agent UID" — is no longer true.

Item 1's urgency is also materially reduced. The "Why now" motivation was an agent discovering the shared-cache read when its push failed. That path is now explicitly severed: bin/gh-wrapper.sh:59-81 refuses to fall back to the shared cache or to HIVE_GITHUB_TOKEN, and fails loud instead — with a comment naming exactly this escalation (audit H3, CWE-522/732). Per-agent scoped tokens from #1860 are fully wired (HIVE_AGENT_TOKEN_CACHE, manager.go:6157).

⚠️ One live inconsistency worth fixing on its own, cheaply: bin/kick-agents.sh:834 still instructs every agent verbatim to run GH_TOKEN=$(cat /var/run/hive-metrics/gh-app-token.cache) gh .... That is the exact anti-pattern H3 removed from the wrapper — the prompt still teaches agents to reach for the shared full-privilege cache. 0600 means it now fails for non-root agents rather than escalating, but agents are being told to do the wrong thing. Related: bin/contributor-relay.sh:47 still falls back to that cache (this is #2172's N14).

What item 1 would actually take now

The proposal's premise — "the proxy already MITMs api.github.com and inspects every request" — is true for inspection, but the injection scaffolding does not exist. Searching v2/pkg/proxy/github_proxy.go, the only Authorization-family handling is reading Proxy-Authorization for agent identity (:1103-1125). The proxy never reads, strips, or rewrites the request's Authorization header today. So item 1 is genuinely from-scratch:

1. Strip inbound Authorization on the MITM path and inject a server-minted, tier-scoped token.
2. A minting/caching layer in the proxy keyed by identified agent + tier, with refresh.
3. Make identity trustworthy enough to mint against — this is the hard dependency.
4. Switch agents to a dummy GH_TOKEN=hive, and update every prompt/script that hands out real tokens (including kick-agents.sh:834).
5. Item 3 (git via injection) follows.

Blockers — one is new and load-bearing

Blocker A — identity is not yet authoritative (this is #2172's N7). Injection mints a token for whoever the proxy thinks is calling. identifyAgentFromReq (:655) tries unforgeable UID lookup first but falls back to the forgeable Proxy-Authorization header when UID lookup fails. Building injection on top of that converts a name-spoofing bug into a token-minting bug: spoof the name, get that tier's token minted for you. N7 must close before item 1 starts — that ordering is not stated in the issue and is the single most important thing to record here.

Blocker B — the deferral rationale still holds, for a new reason. The original defer was startup-path risk. That still applies, and there is now a scheduling conflict: the master-delivery work is in flight (#3833, and the 2026-08-14 options doc — Option D, wrap the new master to a per-spoke public key). That work introduces a spoke-side keypair lifecycle and a trust-on-first-use / attestation story for the public half.

These two interact, and the interaction is favourable — if sequenced. Option D's per-spoke keypair + attestation is the same primitive proxy-side minting needs to answer "which agent/spoke am I minting for, and can I prove it?" Doing item 1 first means inventing a second, weaker identity story that Option D would then supersede. Doing it after means item 1 can consume an attested key instead of a /proc/net/tcp lookup with a forgeable fallback — which also resolves Blocker A structurally.

Recommendation

Keep open, re-title to item 1 only, and leave deferred — but for recorded reasons rather than "not now".

• ✂️ Drop item 2 from scope — shipped (69256ecf).
• 🔗 Add explicit dependency on N7 (Security: harden default deployment & autonomy model (external review) #2172). Item 1 is unsafe to build before it.
• ⏳ Sequence after the master-delivery Option D keypair lands (📄 design: wrapped master delivery to pull-only spokes (Option D) — DESIGN REVIEW, do not merge #3833), and reuse its attestation rather than inventing a parallel one.
• 🔨 Split out one small independent fix now: correct kick-agents.sh:834 (and check contributor-relay.sh:47) to stop instructing agents to cat the shared cache. Safe, self-contained, no design needed — I have not bundled it into 🔒 fix(gh-wrapper): re-land the contributor-mode marker gate on v4 (#3249) #3837 since it is a separate concern.

Net: the issue is less urgent than in July (its exploit path is severed and its concrete half is done) but not obsolete — the structural goal, agents holding no token material, still stands.

🤖 triaged with Claude Code

[Danathar]

Status update on the actionable (non-deferred) slice of this issue, per the triage above:

• Blocker A (N7, forgeable identity fallback): fix open at fix(proxy): stop trusting self-asserted agent identity as a fallback (N7, #3841) #3888 (green, mergeable).
• kick-agents.sh:834 split-out fix: open at fix(agents): stop instructing native-install agents to cat the shared App token (N14, #3842) #3889 (green, mergeable).
• contributor-relay.sh:47 (the triage's other flagged reference, [sec] re-verify the contributor-relay shared token-cache fallback (N14 — citation moved) #3842/N14): re-verified today — on v4 it is a write destination for the hub-minted scoped token, not a read-fallback, but the default path collided with the hub's full-privilege gh-app-token.cache filename (clobber as root / uncaught-EACCES relay crash otherwise). Fix open at fix(contributor): stop the relay defaulting its token write to the hub's full-privilege cache path #3926; full verification writeup in #3842, including confirmation that the hub-side C4 fix deleted the unscoped-token fallback entirely.

Item 1 (proxy-side injection) remains deferred as recorded: after N7 closes and the #3833 Option D keypair/attestation lands, so injection can mint against attested identity rather than a spoofable name.