carlos / platform Public

From the 2026-10-06 access & tenant-isolation assessment (docs/security/2026-10-06-access-assessment.md, finding #1), confirmed live on carlos.exciting.io.

The problem. pstree of carlos-edge.service shows every hosted instance (jam, jelly-manager, dev-jelly-manager, apple-testers-2, james-test-1, alpha-bravo-123/456) running as a plain child process of the edge agent, uid carlos, flat socket /run/carlos/<host>.sock, flat DB /data/<host>.db, zero carlos-instance@*/carlos-app@* units. No namespace, no filesystem confinement. Consequence: any one compromised or hostile app reads every other tenant's /data/<host>.db and <host>.env, plus /etc/carlos/credentials and /data/litestream.env (deployment + data bucket write keys) → full control-plane takeover.

This branch makes nested the documented mandate (flat = defect) and adds the migration plan.

The blocker reviewers must know. The runbooks assert a mandate the platform cannot yet enforce. The flat→nested conversion machinery is not on main:

• isolated-exec plans 1–3 are landed (a box can run a nested row), but plans 4–5 are not (converge/journal, registry.SetInstancePaths, the operator verb);
• the reconciler still mints flat paths unconditionally. So the migration cannot run today, and nothing yet prevents a new flat instance. The plan doc §7–8 specs the minimal enabling build and four guardrails (mint-nested-by-default, converge-refuses-flat, status/doctor-fails-on-flat, downgrade guards) — implemented by nobody yet. Target layout is nested (carlos-instance@, User=carlos), not the unit-backed DynamicUser/carlos-app@ path.

Related: the environment-channel half (finding #2) is fixed on branch tenant-env-allowlist (discussion #242).

Decision this raises: schedule the plans 4–5 + guardrail build as a separate, staged, carefully-reviewed effort before the mandate is real.