carlos / platform Public

Migrated from github.com/carlosframework/platform issue #179, opened 2026-08-12. GitHub issues are closed for this repo; see AGENTS.md, "Work is tracked on amadan, not GitHub".

Still outstanding: CARLOSSECRETSKEY is deployment-wide, so any host can decrypt every app's secrets; per-app or per-box sealing is undesigned.

---

Surfaced by the trust-classes research (spec: docs/superpowers/specs/2026-08-12-app-trust-classes-design.md §8, branch trust-placement).

Today \CARLOS_SECRETS_KEY\ is a single deployment-wide key present in every host's \host.env\ (2026-08-02-app-config-secrets-design.md §"the sensitive half"), and the adopt pass writes decrypted app env files to \/etc/carlos/apps/<host>.env\ (root-owned 0600) on whichever box serves the route.

Consequence: every box in the deployment holds the key that decrypts every app's secrets, regardless of the app's trust class. An E2EE (host-blind) app still hands its box plaintext SES/Stripe/signing credentials. This is fine while all boxes are tier 0 (operator-controlled) — it becomes the hard blocker for:

• Tier 2 (open contribution mesh): not viable at any app class until secrets are re-keyed per box or per app. A stranger's box must never receive the deployment-wide key.
• Tier 1 (partner fleets): today a partner box placed one app still receives the key to all apps' secrets — the blast radius exceeds the DPA's scope.

Direction to design (not settled here): per-app or per-box secret sealing — e.g. secrets sealed to the serving box's own keypair at placement time, or per-app KEKs so a box receives only the keys for apps actually placed on it. Wire-shape change must be additive (existing sealed values keep parsing).

Not urgent for stage 2 (private instances are tier 0), but it shapes any intervening secrets work and gates stage 3.