sealed-secrets

Seal, unlock, and verify agent credentials stored as encrypted bundles in a shared object store.

10|1|Updated May 21, 2026
One-click install
npx skills add https://github.com/ashfulcra/fulcra-tools --skill sealed-secrets-ashfulcra
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: sealed-secrets
Source: https://github.com/ashfulcra/fulcra-tools/tree/main/skills/sealed-secrets
Command: npx skills add https://github.com/ashfulcra/fulcra-tools --skill sealed-secrets-ashfulcra

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires cryptography.

What problem does it solve? Agents lose their machines — containers get reclaimed, hosts are rebuilt, sessions resume on fresh hardware — and their credentials cannot sit in a shared object store in the clear. This Skill defines how to seal credentials into encrypted bundles, recover them on a successor machine with one passphrase, and verify each secret actually authenticates before relying on it. ## Core Features & Use Cases - Sealed bundle format: A versioned JSON envelope using ChaCha20-Poly1305 with a random DEK per version, scrypt-derived KEK wraps, and length-prefixed AAD binding the ciphertext to its role and version. - Re-entrancy probes: An ordered five-probe sequence (pointer, object, envelope, unlock, verify) that tells a successor session exactly where to enter the recovery workflow. - Per-secret verification: Each secret carries its own verifier inside the sealed payload, reporting VERIFIED, FAILED, or UNKNOWN — where UNKNOWN is never treated as success. - Use Case: A successor agent resumes on a rebuilt host, reads its role charter for the bundle pointer, runs the unlock command with the operator passphrase, and learns that 2 of 3 credentials still authenticate and one must be rotated before use. ## Quick Start Ask the agent to run the secrets unlock command for your role, enter the operator passphrase at the prompt, and review the per-secret verification table before relying on any credential.

Frequently Asked Questions about sealed-secrets

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I store agent credentials in a shared object store securely?

Seal them into an encrypted bundle: a random DEK encrypts the payload with ChaCha20-Poly1305, and the DEK is wrapped by a KEK derived from an operator passphrase via scrypt. The store carries only ciphertext; the role's charter carries a pointer to the bundle.

How do I verify a decrypted credential still works?

Each secret carries its own verifier inside the sealed payload, typically an HTTP call to the service's identity endpoint. Results are VERIFIED, FAILED, or UNKNOWN — a successful decrypt alone proves nothing, since a revoked token decrypts perfectly.

Why does hashlib.scrypt raise memory limit exceeded?

scrypt at n=2^17, r=8 needs about 128 MiB, above OpenSSL's default ceiling. Pass maxmem explicitly (128*N*R plus headroom). This error means the host cannot afford the KDF, not that the passphrase is wrong.

Can rotating to a new bundle revoke an exposed passphrase?

No. A retained old bundle still decrypts with the old passphrase; new keys do not reach backwards. The remedies are hard-deleting old bundles, wrapping to an external revocable key like a KMS key, or rotating the credentials at each service.

What does sealed-secrets not protect against?

It does not protect against a compromised machine at unlock time, a compromised session after unlock, or traffic analysis by the store operator. Mitigations are credential scope and rotation, not additional cryptography.