Your First Vault and Secret
Use the CLI to create a vault, store a secret, and read it back, with the dashboard as an alternative.
Now that the CLI is authenticated, storing and reading a secret is three commands. This is the everyday human workflow, and it is worth noticing what the vault gives you that the local one from two lessons ago could not: the secret now exists somewhere other than your laptop, with an access decision and an audit record attached to every read.
- 1
Confirm you're logged in (from the install lesson).
bash1claw whoami - 2
Create a vault. The command prints the new vault's id.
bash1claw vault create "My Vault" - 3
Export the vault ID from the create output so subsequent commands target this vault. If you already created a vault in Lesson 2, you can reuse it: run 1claw vault list and export that vault's UUID instead of creating a new one.
bashexport ONECLAW_VAULT_ID="paste-vault-id-from-above" - 4
Store a secret at a path. Give it a type so 1Claw knows what it is. The CLI uses ONECLAW_VAULT_ID to pick the vault.
bash1claw secret set api-keys/openai --value "sk-proj-demo" --type api_key --vault "$ONECLAW_VAULT_ID" - 5
Read the value back.
bash1claw secret get api-keys/openai --vault "$ONECLAW_VAULT_ID" - 6
List the secrets in the vault (metadata only, never values).
bash1claw secret list --vault "$ONECLAW_VAULT_ID"
Give some thought to the path. Policies are globs over paths, so the scheme you pick now decides what you can grant later. Grouping by provider, as in api-keys/openai and api-keys/stripe, means api-keys/** is a meaningful grant. Grouping by application instead means the same glob hands an agent everything that application uses. Neither is wrong; they simply make different grants easy.
Avoid putting the environment at the end of a path, as in stripe/key/prod. Anything scoped to stripe/** then reaches production, and the only way to carve it out is a deny rule someone has to remember to write. Put the distinguishing part where a glob can stop at it.
Prefer clicking? In the dashboard at 1claw.co, go to Vaults then Create vault, then Secrets then Add secret at a path like api-keys/openai. It hits the same endpoints as the CLI.
You have a vault with a stored secret you can read on demand, and every one of those reads is now attributable. The next lesson syncs your local vault into this one; after that the course turns to the thing only a hosted vault can do, which is give something other than you a scoped, revocable way in.
Check your understanding
3 questionsWhich CLI command stores a secret at a path?
What does 1claw secret list return?
The dashboard is best described as what?