# Vault writer fleet audit

## 2026-09-15 — both Main writers use the reviewed epoch-aware source

The read-only audit of AWS account `747143892217`, region `us-east-1`, found one ECS cluster and 13 running service tasks. Staging Main revision172 and production Main revision122 both run `1058ef4e8aa57054ebeb86572cfaf7d8ff22f046`, with `DREAMLAKE_VAULT_KMS_MIGRATION_ENABLED=false`. Their actual container digests and the complete service/source inventory are in the [audit receipt](https://github.com/dreamlake-ai/dreamlake-workspace/blob/docs/241-vault-writer-fleet/design/reconciliation/241-vault-writer-fleet.json).

Vault entry writes, OTP/replay records, scoped-key writes, host credential operations and policy operations run in Main. Key GC, entry GC and password-rotation collection are embedded in that same process. Queue mount credentials use its Vault service. Private delivery/progress and run reconciliation also belong to Main; private runs are enabled in staging and disabled in production. These are not separate GC or queue deployments needing an independent image rollout.

The other 11 deployed services were traced to their exact image-tag commits and runtime build roots. Auth uses OAuth/account models; hub uses workspace/environment models; BSS uses File/Embedding; dashboard and its cleanup worker use Node/PhysicalFile/Experiment/track models; viz has no Vault database path; RTC uses document/journal/session models. Their Prisma schemas, raw command collection targets and runtime imports contain no identified Vault writer. A database setting alone was not used as proof of inclusion or exclusion.

Known retired staging171 has positive execution-stop evidence at 13:22:55.454 UTC. Archived production121 task `8c801bd0d2e147d5928c32e617557519` has Main STOPPED and execution-stop evidence at 13:53:47.280 UTC; its later absence from ECS history is not the basis of that conclusion. [Production rollout receipt](https://github.com/dreamlake-ai/dreamlake-workspace/pull/586#issuecomment-5681374346).

This covers the enumerated ECS fleet, not arbitrary database clients, manual processes, other regions or other accounts. Source classification does not assert that credentials technically prohibit arbitrary writes. Within the inspected fleet, only the two reviewed Main runtimes are identified Vault writers, and no additional process rollout is indicated. The operator must bind any migration approval to this actual hosted database and known writer inventory; unknown external access is not silently declared absent.

Migration remains disabled. The [proposed isolated staging procedure](https://github.com/dreamlake-ai/dreamlake-workspace/blob/docs/241-vault-writer-fleet/design/acceptance/vault-hosted-kms-plan.md) is review-only. No flag, key, grant, namespace, entry or deployment was changed by the audit.

The review candidate now includes a phased owned staging runner and a read-only flag planner. Reverse migration uses the already supported `managed` target with a distinct persisted ID; it restores the configured default key while retaining an explicit managed boundary and checkpoint metadata. Seven offline safety/orchestration tests passed. The new runner then passed its actual local HTTP/Mongo lifecycle with both enabled and disabled route registrations: forward and managed reverse, exact values/replay, scoped retirement, final disabled checks, and partial-baseline cleanup while disabled. The independently verified public npm CLI 0.21.2 binary and Python 0.17.0 wheel are bound by hash; installed SDK source bytes are checked against that wheel. These are local fixture and release checks, not hosted migration proof. See the [runner validation receipt](https://github.com/dreamlake-ai/dreamlake-workspace/blob/docs/241-vault-writer-fleet/design/reconciliation/241-hosted-kms-runner-validation.json).