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.

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 published

Why 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 rk1 for vk1; 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 →