Architecture: How should credential management be architected for Computer...

Documentation for Sessions

🏗️ Architecture: How should credential management be architected for Computer...

Date: 2026-03-30
Time: 18:33:20 UTC
Session: gspace1-290.11
Agent: backend
Confidence: 95%
Status: ✅ Documented


📋 Decision Context

Question:

How should credential management be architected for Computer Use? UserCredentialsService (in-memory) vs SecretVaultService (MongoDB) vs new dedicated system?

Task: Not specified


🎯 Decision Made

Chosen:

New dedicated vault-accounts MongoDB collection with VaultAccountService, building on SecretVaultService's encryption pattern via shared @libs-api/vault-crypto. Dual vault: user scope + space scope. AccountPickerComponent as shared UI. UserCredentialsService deprecated.

Options Considered:

  1. Patch UserCredentialsService to use MongoDB (quick but wrong layer)
  2. Piggyback on encrypted-secrets collection with JSON metadata (hack)
  3. New vault-accounts collection + shared crypto + dedicated service (chosen)

💭 Reasoning

5 scattered credential systems existed: UserCredentialsService (in-memory, dies on restart), SecretVaultService (MongoDB, robust), OAuthService (tokens), CredentialBridgeService (resolution), VmCredentialInjector (SSH keys). UserCredentialsService was the critical gap — Computer Use's only storage was in-memory. Rather than patching it to use MongoDB, created a purpose-built vault-accounts collection with proper indexes for vault-specific queries (profileId+scope+preferred). Reused encryption from SecretVaultService via extracted @libs-api/vault-crypto. New collection avoids polluting encrypted-secrets with vault-specific fields. Dual vault (user/space) maps to existing role hierarchy. AccountPicker eliminates credential re-entry — the #1 UX complaint.


📁 Files Involved


🔗 Related


Auto-generated by MCP Smart Consolidation