sealed-secretslisted

# Sealed Secrets **A successor session on a fresh machine must be able to recover the role's credentials — and must never be told a revoked one is fine.** Agents lose their machines. Containers get reclaimed, hosts are rebuilt from snapshots, a session resumes tomorrow on hardware that has never seen your config. Everything else an agent needs can live in a shared object store. Its credentials cannot — not in the clear, because the store is readable by every agent on the team and by whoever operates it. So seal them. The store carries ciphertext; the operator carries one passphrase; the successor runs one command and learns, per secret, whether it **actually works**. > **A decrypt that succeeds is not a credential that authenticates.** That sentence is the whole design. A bundle that decrypts perfectly to a revoked token passes every cryptographic check and still leaves the successor dead. ## Where to start — the re-entrancy probes Run in order; enter at the **first probe that fails**. Every state below is safe to re-enter: sealing is a new bundle version, unlocking is read-only, and verifying makes no writes at all. | Probe (run in order) | Command | Passes when | If it fails, enter at | |---|---|---|---| | 1. Role has a bundle pointer | read the role's charter frontmatter | a `sealed_bundle:` key is present and non-empty | **§1 Seal** | | 2. Bundle object exists | read the path that key names | the read returns an object (not absent, not an error) | **§1 Seal** — th