Security - Jacob P Evans

Seven secrets tools, one job each. The boundary between AI-readable and human-only is structural, not policy.

This site is the single public source of truth for the secrets-management story. Each repo’s README.md keeps only the literal commands its workflow needs; the narrative lives here.

The four-tier model

Every secret lives in exactly one of four tiers, and the tier — not the tool — decides who can read it and how. This is the organizing frame for everything below; the tools comparison has the full matrix and the bootstrap, read-path, and DR flows.

Tier	Role	Tool	Who reads it
T1 — Repo-local	Encrypted-at-rest config that travels with the code	SOPS + age	AI and machines, via a path-gated local age key
T2 — Runtime manager	Self-hosted source of truth for live machine credentials and Terrakube dynamic provider credentials	OpenBao	AI and machines, via scoped native auth / signed SSH cert — no human in the loop
T3 — Strict cloud	Cloud keys-to-the-kingdom; holds secret-zero that bootstraps T2	Doppler	Machines for a narrow set; AI only under explicit, per-use human approval
T4 — Never-AI human	Break-glass and crown jewels	Bitwarden	Humans only, at a keyboard, with a second factor

The default automation path is T2: an always-on agent authenticates as itself and gets scoped, expiring credentials with zero interactive prompts. aws-vault and automated macOS Keychain reads are interactive-convenience paths whose machine side folds into T2.

The boundary that matters

AI-readable (CI + dev)	Human-only
OpenBao (T2, primary), Doppler (T3, human-approved), `automation` keychain, AWS Vault session, SOPS in-repo, BWS via bridge	Bitwarden vault (T4), `elevate-access` keychain

Which tool for which secret

Tool	Use it for	Deep dive
Doppler	AI provider keys (`AI_TOKEN`, Copilot, HuggingFace, provider-specific fallbacks); GitHub Actions secrets distributed via `secrets-sync`; dryvist org-level Doppler integration	doppler
macOS Keychain	Service API keys no engine mints; BWS access token; Claude Code OAuth credential; human-only break-glass material	macos-keychain
AWS Vault	AWS credentials per OpenTofu root (one profile per root)	aws-vault
Mozilla SOPS	Encrypted OpenTofu / Ansible vars committed to git; initial-bootstrap passwords; internal topology	sops
Bitwarden vault	SSH keys, recovery codes, age-key escrow, account passwords — AI tools never reach this	bitwarden
BWS	Programmatic AI tokens that cannot use the shared `AI_TOKEN` convention, fetched via the Python bridge	bws
OpenBao	The T2 runtime manager: primary AI/machine credential interface, Terrakube dynamic credentials, and SSH CA for automation	openbao

What this section covers

Tools comparison

The four-tier model in full — the tool matrix and the bootstrap, read-path, and DR flows.

Golden laws

The fifteen non-negotiables. Every other page is just an implementation of one of these.

SSH access

The access ladder — certificate-first, why host-key checks are never disabled, and the shape of a break-glass path.

How it fits together

Multi-diagram tour of every secret flow — CI, local dev, AI sessions.

secrets-sync architecture

How Tier 1 secrets reach 20+ GitHub repos through one workflow.

Local AI isolation

Why AI tools structurally cannot view protected token values.

Scrubbed values

Canonical placeholders for IPs, domains, usernames, and tokens in every committed file.

For dryvist-internal specifics (workspace names, account IDs, internal topology), see docs.dryvist.com.

​The four-tier model

​The boundary that matters

​Which tool for which secret

​What this section covers