Four tiers, one rule each. A tool earns its tier by who can read it and how, not by what it happens to store today.Seven tools show up across this section, and on their own they read like a grab-bag. The organizing idea is a four-tier model: every secret lives in exactly one tier. The tier, not the tool’s feature list, decides whether an AI agent, a machine, or only a human can reach it. This page is the map; the per-tool pages are the detail.
The four tiers
Two properties make the model hold:
- The primary path is T2. An always-on agent authenticates to the self-hosted runtime manager as itself (AppRole) and gets scoped, expiring credentials with zero interactive prompts. That is the default read path for automation, not the cloud tier, not the keychain.
- Secret-zero lives one tier up. T2 cannot bootstrap itself from nothing: its static seal key
and the AppRole
secret_idthat agents use to authenticate are held in T3. That, plus the handful of values an external service reads on its own, is the whole of T3. Everything else lives in T2 or is minted by an engine on demand. T3 is therefore small, tightly scoped, and only AI-reachable under human approval. T4 holds the human-only recovery material that can rebuild everything if both T2 and T3 are lost.
The tool matrix
Every tool this section documents, scored on the axes that decide its tier. “AI tier” is where the tool sits in the preceding model; several tools are transitional and are folding into T2.
aws-vault and the automated use of macOS Keychain are retired from the machine path. T2’s
AWS secrets engine and token-file reads replaced them. A human at a laptop may still keep a local
session, but headless agents have none.
How the tiers bootstrap — root of trust to runtime creds
T2 is the primary interface, but it cannot start sealed-and-empty on its own. The automated path unseals it from secret-zero in T3; the human recovery shares in T4 are the break-glass fallback, never the routine path.An AI agent’s read path, by tier
The same agent reaches different tiers by different means. T2 is the default and needs no human. T3 is reachable only when a human approves that specific keys-to-the-kingdom operation. T4 is structurally unreachable. There is no programmatic bridge to it at all.Rotation and disaster recovery
T2’s value is only as good as its recoverability. Rotation is native: leases expire and re-issue on their own. Durability comes from periodic Raft snapshots shipped off-box. The snapshots restore onto a fresh node and unseal from the same secret-zero the routine bootstrap uses.The runtime manager is also the lock authority
For OpenTofu, T2 integrates directly with Terrakube. Each workspace receives a least-privilege OpenBao identity and short-lived provider credentials. Terrakube owns the run queue and state lock per workspace; OpenBao does not implement a second, estate-wide mutex.See also
OpenBao
The T2 runtime manager — AppRole auth, SSH CA, and the lease authority.
Doppler
The T3 strict cloud tier and secret-zero holder.
Bitwarden vault
The T4 never-AI human tier.
SOPS
The T1 repo-local encrypted-config layer.
Agent secrets
The headless read path — zero interactive prompts for always-on agents.
Security overview
Where the four-tier model sits in the whole secrets story.
docs.dryvist.com.