Secrets tools comparison

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, and 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_id that agents use to authenticate are held in T3. 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 model above; several tools are transitional and are folding into T2. Two rows are on their way out. Infisical was briefly the static-app-secrets backbone; that role collapses into T2 (runtime credentials) and T3 (cloud-shared keys), so it is being migrated out and decommissioned. aws-vault and the automated use of macOS Keychain are interactive-convenience tools whose machine paths move to T2’s AWS secrets engine and token-file reads — the human at a laptop keeps them, headless agents do not.

​

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 — and durability comes from periodic Raft snapshots shipped off-box, restorable onto a fresh node and unsealed from the same secret-zero the routine bootstrap uses.

​

The runtime manager is also the lock authority

T2 does one more job the other tiers cannot: it is the global flow-lease authority. A single lease in its KV store (compare-and-set, so two writers cannot both win) gates every mutating flow — a tofu apply, an ansible run, an agent that changes infrastructure. The rule is credential-gating: no lease, no credentials. An agent that cannot take the lease cannot get the short-lived creds it would need to do the mutation, so serialization is enforced at the point where secrets are issued, not merely by convention. This pairs with the OpenTofu state lock described in the deployment state contract.

​

See also

For dryvist-internal specifics (host topology, policy paths, lease TTLs), see docs.dryvist.com.