Secrets
Everything this Machine keeps to itself (the Claude credential, the vendor-support key, the streaming keys, the assistant terminal's password, the network-storage logins, anything a job needs) lives in one sealed file on the boot media; the stick and every clone of it carry nothing in the clear.
Sealed to this Machine
The file opens in the chassis it was claimed in. In a different box the dashboard still comes up, but the boot report says vault is LOCKED beside chassis mismatch, and the services that need a secret wait.
To open it elsewhere you need the recovery phrase: eight groups of four characters, shown once at claim (or under Secrets the first time this Machine boots with the vault). Write it down. It is stored nowhere on the box, and there is no other way in.
The Secrets view
Admin only. Every secret is listed by name, never by value.
| Locked? | type the phrase. The vault re-seals to this chassis and the services start; the phrase keeps working |
| New phrase | the old one stops working the moment the new one shows |
| Reveal | a value, once, after re-typing your password |
| Add | anything else the box should keep. Named jobs.something it reaches jobs as SOMETHING |
| shared with | on a cluster, the members a text secret is copied to |
| Share requests | asks from another member for a secret this Machine holds; approve or deny |
The Claude credential, support key, stream keys, terminal password and SMB logins are set from their own cards; Secrets lists and deletes them, nothing more.
The agent's one door
The resident agent cannot read the vault or run any pipeos vault verb (the fence). Its one door is pipeos secrets request NAME [WHY]. The request asks every member whether it holds the name, survives a reboot on the requesting Machine, and shows on whichever dashboard you have open, under Secrets → Share requests and as an alert. You approve on a Machine that holds the secret; the holder sends its copy over mutual TLS, the requester accepts it only from a holder the request named, and every member closes the request. Deny closes it everywhere; requests expire after a day. A job with needs uses this door on its own: schedule and usage.
Sharing across a cluster
Secrets live in the vault of the box they were entered on; the one exception is a copy the owner makes. The shared with ticks, or pipeos vault share NAME MEMBER…, copy a text secret to each member, stored as cluster:<holder>. A copy never overwrites a secret the member set itself; a Machine's own secrets (terminal password, support key, SMB database, stream keys) are never shared. Unsharing only forgets.
What stays outside
Your admin password (a hash) and the dashboard's certificate are not in the vault: they are what lets you reach the page to type the phrase. The pipe sign-in keys stay where pipe keeps them.
Backups and clones
A backup or a second stick carries the sealed file as it is: it opens in the same chassis, or anywhere with the phrase. An identity backup's optional passphrase is a second seal on the bundle (files, storage and backup).
$ pipeos vault status $ pipeos vault list $ pipeos vault set jobs.deploy_key # value on stdin $ pipeos vault share jobs.deploy_key miura $ pipeos secrets phrase # the pending phrase, once $ pipeos secrets request jobs.deploy_key "the nightly build needs it"