Vault credentials: what each one can do, and what its prefix declares, sgit.ai
Two capabilities, a vault key that reads and writes and a read key derived from it one way, plus the five prefixes that declare which you are holding and whether it was meant to be published. Why sgit_public_read_ is the form for an open vault, why publishing one under sgit_private_read_ is a mislabel that an agent will correctly refuse, and why the word matters when the bytes are identical.
Source: https://sgit.ai/docs/credentials.html↗ · site v0.6.8 · this file is generated from the same content as the page, so the two cannot drift. Every page on this site has a .md twin; internal links below point at them.
Home↗ / Docs↗ / Vault credentials
Vault credentials: what each one can do, and what its prefix declares
A vault credential is the whole thing you need: the address, the capability and the decryption key, in one string. There are two capabilities, write and read, and five prefixes in circulation that declare which one you are holding and whether it was meant to be published. The prefix is a declaration, not cryptography: strip it and the bytes are identical. It still matters, and this page is why.
Why this page exists, with the date on it. On 20 September 2026 an agent was asked to open two vaults published on this site and refused, because their read keys were labelled sgit_private_read_. It was right to refuse and our label was wrong: those keys are deliberately public, and the prefix that says so is sgit_public_read_. The keys were relabelled the same day, the build now refuses a private-prefixed credential in any tracked file, and this page is the explanation that was missing.
Two capabilities, and one is derived from the other
A vault key carries read and write. A read key carries read only, and is derived from the vault key by a one-way function, so a read key can never be turned back into write access. That derivation is the whole publishing model on this site: thirty vaults↗ hand out read keys on purpose, and not one of them can be used to change anything.
[diagram]
The five prefixes
Three are current and emitted by the CLI today. Two are legacy, released briefly in v0.15.5, accepted on input forever and never emitted again.
| Prefix | Declares | Capability | Publish it? |
|---|---|---|---|
sgit_private_vault_ | A vault key, kept secret | Read and write | Never. Not in a page, a repository, a commit message, an issue or a release log |
sgit_private_read_ | A read key, kept secret | Read only | No. Publishing it leaks no write capability, but the label says the opposite of what you are doing. Re-derive the string with the public prefix first |
sgit_public_read_ | A read key, deliberately published | Read only | Yes. This is the form every open vault on this site should carry |
sgit_vk1_legacy | A vault key | Read and write | Never |
sgit_rk1_legacy | A read key, intent unstated | Read only | Safe, and says nothing about intent. Most pages on this site still carry this form; the bytes are the same |
A credential with no prefix at all is the oldest form and still circulates. It is read as unknown and resolved by context, which is exactly the ambiguity the prefixes were introduced to end.
Classification is by declaration, never by shape
This is the rule the CLI states in its own source, and it was learned the hard way: "guessing from shape is what once misrouted a 64-hex passphrase to a read-only clone." A surface that accepts read credentials must refuse a vault key because the string says it is one, not because it looks long enough to be a passphrase.
Shape is still the backstop for the years of keys created before prefixes existed: a read key is 64 hexadecimal characters, and anything else before the colon is a passphrase, which means write. The publishing method↗ runs both checks on every credential submitted to this site, and the front stop is one command:
$ python3 admin/build/check_credential.py '<credential>'
form : read key (public, prefixed)
publish? : YES — read-only, declared public
why : the sgit_public_read_ prefix marks a key meant to be publishedWhy the word matters when the bytes do not
Relabelling a key changes nothing an attacker can use. It changes three things that people and machines rely on.
- One scanner rule covers every secret credential.
sgit_private_matches the vault key, the private read key, and any private credential type invented later. Publishing keys under a private prefix trains that alarm into noise, which is the failure mode where a real leak goes unnoticed because the alert fires every day. - Public and private differ by a word, not a character. That is deliberate. A tired reviewer can misread
rk1forvk1; nobody misreads public for private. - An agent reads the label and acts on it. The refusal that produced this page was correct behaviour on a wrong label. An agent that ignores a private marker because the content happened to be on a public page is an agent that will ignore the next one too.
What a read key can and cannot do
| Can | Clone the vault, read every file, read every commit in its history, and run the vault's app in a browser with no account and nothing installed |
|---|---|
| Cannot | Commit, push, delete, rotate the key, or reach any other vault. There is no privilege inside it to escalate |
| Costs | Nothing to issue, and nothing to the server, which stores ciphertext either way |
| Does not do | Revocation is not retroactive. Anyone who has fetched the objects keeps them; rotating protects future commits only. Publish a read key the way you would publish the content itself, because that is what you are doing |
What this site publishes
Every vault in the gallery↗ carries a read key published on purpose, and no vault key appears anywhere: the release refuses to push if a write credential reaches a tracked file, and since 20 September it refuses a sgit_private_ credential of any kind. New pages use sgit_public_read_. Older pages carry the legacy sgit_rk1_ form or a bare key, which are the same bytes and open the same way, in the CLI and in the browser.
Checked against sgit-ai v0.16.2 and the SG/Vault web loader on 20 September 2026: all five prefixes plus the bare form strip to the same value and clone the same vault, verified with an all-zeros negative control that produces nothing.
← Keys and signatures↗Publishing a vault →↗