🏗️ Architecture: How to solve VM credential isolation for the Jarvis vision (...

Date: 2026-02-28
Time: 20:03:20 UTC
Session: gspace1-156.2
Agent: backend
Confidence: 92%
Status: ✅ Documented

📋 Decision Context

Question:

How to solve VM credential isolation for the Jarvis vision (VMs can't push to GitHub)

Task: Session 152: VM Credential Bridge architecture

🎯 Decision Made

Chosen:

3-fallback Credential Bridge: 1) Local Bridge (user's SSH keys) → 2) Secret Vault (HTTPS tokens, AES-256-GCM) → 3) Handoff to code agent. CredentialBridgeService resolves credentials at tool execution time, never persists in VM state. delegated_git tool implements the strategy with userId parameter for credential lookup.

Options Considered:

1. 3-fallback Credential Bridge (chosen)
2. Give VMs direct credential access via env injection
3. Always require Local Bridge (no fallback)
4. Use OAuth2 device flow for each VM session

💭 Reasoning

VMs are intentionally isolated — this is a security feature, not a bug. The Cowork screenshot showed the same limitation. Giving VMs raw credentials would break snapshot safety (credentials in memory dumps), violate least-privilege, and create audit blind spots. The 3-fallback strategy preserves isolation while enabling autonomous operations: Local Bridge is best (zero credential storage, uses existing SSH keys), vault is good (encrypted at rest, audit logged, user-controlled), handoff is the safety net. The CredentialBridgeService uses ModuleRef to lazily resolve LocalBridgeGateway, avoiding circular dependency between ToolsModule and EngineModule.

📁 Files Involved

• APIs/backend-vitto-api/src/app/tools/credential-bridge.service.ts
• APIs/backend-vitto-api/src/app/tools/handlers/delegated-git.tool.ts
• APIs/backend-vitto-api/src/app/tools/tools.module.ts

🔗 Related

• Decision ID: dev_1772308996528_daioxdk
• Session: 156
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation