Keys

Web UI → Keys (System section) is the home of the secrets vault: every provider API key, bot token, and secret setting an install runs with, stored encrypted at rest and fully manageable from this page — add, replace, test, disable, delete, snooze, export, import. There is no plaintext .env file anymore; the vault replaced it.

Where secrets actually live

• secrets.db in the AIOS home — every value encrypted per row (XChaCha20-Poly1305), never stored or served in plaintext.
• The vault key (KEK) — kept outside the store: an owner-read-only .kek file in the install root, the same on every platform. Stealing secrets.db alone yields nothing readable.
• Two scopes — install (shared by everything on the box) and agent:<name> (one agent profile’s own keys). Agents resolve their own scope first, then fall back to install.
• On first start after upgrading, any legacy plaintext .env / license.json files are imported one-way into the vault and renamed *.migrated — see Backups & Migration.

The keys table

A table with one row per stored key, across both scopes (agent rows included), columns:

Column	What it shows
NAME	The key name, e.g. ANTHROPIC_API_KEY
STATUS	SET / MISSING, or DISABLED for a disabled row
VALUE	A masked fingerprint — the full value is never sent to the browser
TYPE	SECRET or CONFIG badge
AGE	How long since the value was last rotated, with due/overdue coloring
VALIDATED	When the key last passed a live provider check
SCOPE	install or agent:<name>

Row actions, per key:

• REPLACE — opens an inline strip on the row to paste a new value (sent once, stored server-side, shown masked after).
• TEST (secrets with a known provider) — live-checks the key against its provider with a free metadata request, never a completion, and stamps the VALIDATED column.
• DISABLE / ENABLE (secrets) — keeps the value stored but stops every read from resolving it; re-enabling needs no re-paste.
• DELETE — removes the row (audited), via an inline confirm strip.

Adding a key: the NAME + VALUE + SAVE KEY form under the table. Provider key names are suggested as you type. Every service reads the vault on its next request — no restart needed after any change here.

Header panels

Four panels open from the page header:

• Rotation reminders — the install-wide warn/critical age thresholds, plus per-key overrides and reset. A due key can also be snoozed for a number of days from its row.
• Export — download a bundle: names-only plain JSON, or (with secrets included) wrapped under a passphrase of 12+ characters via Argon2id, bound to this licensee.
• Import — upload an export bundle: same-value rows are skipped, differing values replaced and re-stamped as rotated.
• History — the vault’s audit trail, newest first. Every set, delete, disable, test, export, and migration is audited; a value never appears in the history.

The CLI twin

Everything above is scriptable — aios secrets mirrors the page verb for verb:

aios secrets status                # vault health: store, KEK source, rows, strays
aios secrets list [SCOPE]          # every stored key, masked
aios secrets set NAME [--scope agent:<name>] [--from-stdin]
aios secrets rm|disable|enable|test NAME
aios secrets export FILE [--with-secrets]
aios secrets import FILE
aios secrets audit [--since RFC3339] [--limit N]
aios secrets age [NAME] [--warn D --crit D | --reset]
aios secrets snooze NAME --days D  # --days 0 clears a snooze
aios secrets migrate               # one-way plaintext import (also automatic)
aios secrets kek-backup FILE       # the vault key, passphrase-wrapped — store offline
aios secrets kek-restore FILE      # put it back after a lost KEK
aios secrets rotate-kek            # re-encrypt every row under a fresh vault key
aios secrets reset --confirm RESET # wipe the vault (keys + vault key)

Secret values are read from a no-echo prompt or --from-stdin — never from argv. rotate-kek invalidates the previous kek-backup; take a new one after. Vault-key recovery and the System page’s VAULT card are covered in System and Backups & Migration.

Credential pools are not shown here

The Agents chapter describes a credential pool feature — multiple keys per provider, automatic rotation, cooldowns on rate limits — managed entirely through aios credentials add|list|revive on the CLI, backed by a real API (/api/credentials/pool) that has no dashboard page wired to it.