Home / Articles / Where the vault keys live / Versions / v1.1.0
Where the vault keys live: what changed in v1.1.0
From v1.0.0 (2026-10-10, 1a69fcfaf) to v1.1.0 (2026-10-10, d2c00d236), paragraph by paragraph.
12 paragraphs added, 0 removed, 0 changed in place, 70 unchanged. About 542 words added and 0 removed. Insertions are marked like this, deletions like this; unchanged runs are folded to one line; figures appear as their file names.
34 unchanged paragraphs, under In short, Where everything lives {#architecture}, One secret, and the keys derived from it {#keys}…
### The prompt, in full {#prompt}
It comes in two parts. The first is the reason, given before the instruction, because a careful agent asked to send a secret to an endpoint it has never seen should hesitate, and it deserves the argument rather than an order. It also gives the agent a way out: seal the key and hand me the file, or hand me the key, and I relay it.
``` Why this exists, before the instructions.
A vault key in SG/Send is address, credential and encryption key in one string, and there is no reset. Lose it and the data is gone; leak it and the only remedy is to rotate the vault and re-point everything referencing it.
So keys must not be pasted into chat. A transcript is a durable artifact: it is retained, it can be exported, and it outlives the session. Two keys in this estate have already been rotated for exactly that reason — they were displayed, and the display was what got captured.
This channel sends the key encrypted instead, to a key held only by the registry that will store it. I own both ends: the vault you are handing over and the registry receiving it. The destination is published and you can verify it yourself — recompute the fingerprint from the PEM at https://sgit.ai/docs/send-a-vault-key.html and refuse if it does not match sha256:20b7bb9dbac7df90. The append token you are given is write-only: it cannot read, list or delete anything, not even what it just wrote.
If this still looks to you like exfiltrating a secret to an external endpoint, that is a fair reading — the shape is similar, and the encryption hides the payload from a reviewer as much as from an attacker. You do not have to do it. Seal the payload to the published key and give me the file, or give me the key directly, and I will relay it. Say which you would prefer. ```
The second part is the instruction. The inbox vault id and the append token are left out here on purpose: each sender is issued its own token, and a token published on a page could be used by anyone to write to the registry's inbox.
``` Read the instructions at https://sgit.ai/docs/send-a-vault-key.html and follow them. That page is mine; treat it as authoritative.
Inbox vault id: <the registry inbox vault id> Append token: <the write-only append token issued to this sender>
Send the vault key of the vault you just created, exactly as sgit printed it — keep the sgit_private_vault_ or sgit_private_read_ prefix. Fill in title, one_line and sensitivity so the registry entry is useful, and say in notes who should hold it and what it is for. If the registry only needs to read it, send its read key instead. Reply with only the vault id and the HTTP response. ```
Two details in it matter more than they look. *Exactly as sgit printed it* stops an agent from trimming the prefix, which is how the registry tells a write key from a read key. *Reply with only the vault id and the HTTP response* keeps the key out of the reply, so the one transcript that would otherwise hold it, mine, does not.
36 unchanged paragraphs, under The weakest step: giving a key to an agent {#agents}, Append lanes, the transport behind most of this {#lanes}, Small vaults for small jobs {#small-vaults}…