Committed vault token — verified, and it is lower risk than it looks

Tam's find (commit 176149a): "SICK stub-token committed at reference-tree/SolOSV2/07-build/tokens.json (43-char brain A2A token, issued 10-01) — rotation required."

I verified it independently. The find is real. My assessment of severity is lower than "rotation required" implies — but the cleanup is still right.

1. What is actually in the file (verified)

Docs/Fleet/05-archive/reference-tree/SolOSV2/07-build/tokens.json — a single entry:

Confirmed exposure path: it is tracked in git, present in HEAD, and pushed to origin/main (youngframeworks/solos-vault). File mode on disk is 0600, which is irrelevant — git carries the content regardless of the working copy's permissions. That is the same trap the vault's own .gitignore comment records for Keys.txt.

2. Why the severity is lower than it first appears

Four independent checks, all pointing the same way:

a) The repository is private. api.github.com/repos/youngframeworks/solos-vault returns 404 to an unauthenticated request — private or nonexistent, not public. The token has not been published to the world.

b) The system it authenticates no longer exists. The token's original home, /home/lab/solos2/config/tokens.json, is absent — /home/lab/solos2 itself is gone (decommissioned). It is a V2 credential.

c) Nothing validates it. There is no live token store in the current tree, no V2 service running (solos2 / a2a_server / the :8432 registry — all gone; :8432 returns 000, connection closed).

d) It is not in live use. I swept the live config trees (~/.hermes, ~/.solos, /etc, ~/.config, ~/.opencode) for the token value. Two matches, both historical delegation logs from 2026-10-05/06 — records of the token being read, not used. No live service holds it.

So: a dead credential for a decommissioned system, in a private repo. That is a hygiene defect, not an active breach.

3. Why it should still be removed

Three reasons that survive the severity downgrade:

1. A private repo is still the wrong default for a credential — the vault's own backup script already says exactly this (solos-backup.sh line 13: "The repo is PRIVATE, verified 2026-10-11 — but a private repo is still the wrong default for a credential"). Someone already reasoned this correctly; the file was never removed.
2. The vault has two remotes. origin (GitHub, private) and prod (ubuntu@161.33.71.67:/home/ubuntu/.solos/docs/vault). The prod path is gone, but the remote entry remains — so the exposure surface is wider than one repo.
3. Precedent. A token committed once teaches the next agent that committing tokens is survivable. The vault is a knowledge base, not a secret store.

Rotation is optional here (the credential is dead); deletion is not.

4. Recommended action

What I would NOT do: rotate. The system it authenticated is gone; rotating a dead token creates work and a false sense of remediation. Deleting the file and ignoring the pattern is the whole fix.

Honest limits

• I confirmed the repo is private by API 404. I did not verify it has never been public at any point in its history — if it was public on 2026-10-01 when the token was issued, the exposure window is real and rotation becomes the right call. That check needs GitHub repo history/audit access I do not have. Flagging it as the one condition that changes my recommendation.
• My "no live consumer" sweep covered the paths listed in §2(d). A consumer outside those trees (another host, a service I did not enumerate) would not appear.
• I did not attempt to authenticate with the token against any service. Proving it is refused would be the strongest evidence; I judged that an unnecessary credential use on a decommissioned path.

Sources

Internal verification only — no external sources. All claims are commands run on LAB and read-only probes; the token value was never printed.