Vaults and keys
What must not be public (booked meetings, contacts, introductions, the week's access keys) lives in encrypted SGit vaults, never in this repository. This page says what exists, how a key reaches an agent, and who is ready. It holds no vault key, no private key and no contact detail. Kept by sgit@web-summit.dinis.
What exists today
- Six vaults on dev.send.sgraph.ai: public and private for the CRM, the messages (Email-FS) and the task board (Issues-FS). Each holds only a README (REALITY.md).
- Their vault keys are sealed to the DC Vault Registry key (
sha256:06c6ccddb7476629, on the keys page), handed over by Dinis as a QR code on 28 October. Only the agent holding that key can open them. - Agent keys are on the keys page: one entry per agent, the public half only, each pushed by the session that made it (the start page, step 6).
- Not yet: a team vault key sealed to any team member's agent (the tool is ready; the vault registry key's holder runs it), the private vault's folders for meetings and contacts, and encrypted material on the site (WS-38).
How a vault key reaches an agent
The push is the authorisation (the article, CLAUDE.md "Identity and names"). A key is trusted because it was pushed to this repository's keys page, which only an account with push access can do. It is not trusted because of the pki.sgit.ai register, and no registration there is needed.
- The agent makes its own key in its session (
node pki-agent.mjs keygen --session) and commits only the public half todata/keys.json. The private half never leaves the session. - The holder of a vault key seals it to that key, read from what was pushed:
node admin/tools/seal.mjs --to <key id> --from-vault <vault dir> --expires 2 --qr sealed.png. The tool takes the bundle from origin/dev:data/keys.json, names the commit that pushed it, checks that the live site serves the same key (/keys/sha256-<fp>.json), and seals with pki-agent.mjs's own code (refusing any copy whose sha256 is not the pinned one). Who pushed it (WS-106): every commit here is authored as "Claude", so git cannot say whose account pushed a key. The tool asks GitHub (the repository's activity API names the account behind each push) and seals only if that account is one the roster (data/team.json) lists for the person in the key's label, or if the sealer passes --fingerprint <fp> that the person read to them out of band (or showed as a QR code). It never prints the fingerprint in a refusal, so the out-of-band check cannot be copied from its own output. The vault key goes from sgit vault show-key into memory and is never printed. --check <key id> shows what the repository says about a key and seals nothing.
- The sealed link or QR code reaches the agent out of band (Dinis, or a person carrying the QR code). The agent opens it with
node pki-agent.mjs open <link or qr.png> --save <dir>and keeps the vault key in its session's key store, or in the gitignored.credentials/tier. - The agent clones the vault with
sgitand reads and writes it there.
Tried end to end on 2 November: a test secret was sealed to sgit-dinis from the keys page and opened by that session from the link and from the QR code (WS-102). Still open, as in the article: proof that a session holds the private half, which writer may replace which role's key, and retiring an old session's key.
The private vault: a proposed shape
For WS-23 (Nimay's booked meetings) and WS-24 (every contact and introduction followed up). This is a proposal. Nothing is in the vault yet.
| Folder | One file per | Fields |
|---|---|---|
meetings/ | booked meeting | who, when, where, owner, what we bring, public or not |
contacts/ | person or organisation | who, how we know them, owner, next step, by when |
introductions/ | introduction made to us | from, to, about, owner, next step |
Each person's agents read and write it once their keys hold its vault key. Only an agreed, public meeting may be copied to this site, and only after the decision in WS-23.
Who is ready for step 8
Step 8 needs agent keys on the keys page (the leaderboard reads them from there). On 3 November Dinis settled WS-106: the GitHub check is enough for now, and riskmandate-vicky and riskmandate-jose are Vicky's and Jose's accounts (now on the roster). riskmandate-agent is Dinis's own account. seal.mjs --check on 3 November:
| Key | Pushed by | Its person's account on the roster? | Can be sealed to |
|---|---|---|---|
sgit-dinis, conductor-dinis, mentor-dinis | DinisCruz | yes (dinis) | yes |
dev-angelo | riskmandate-angelo | yes (angelo) | yes |
sgit-silvio, procurement-silvio | riskmandate-silvio | yes (silvio) | yes |
conductor-vicky, dashboard-vicky | riskmandate-vicky | yes (vicky), from this release | yes |
conductor-jose | riskmandate-jose | yes (jose), from this release | yes |
The vault registry key holds the six team vault keys today, so its holder does the sealing. Everyone else: steps 4 to 6 first (the start page).
Everyone's own vaults
Everyone now makes their own vaults, with the access token Dinis shared on 3 November, through a vault agent: your vault agent, step by step. Almost every vault is public: its read key is listed here, from people/<id>/vaults.json, and opens the vault read-only, with no account. The build refuses anything but a sgit_public_read_ key in those files.
No published vaults yet.