Laisser un agent IA appeler write ou rm sur un dépôt de prod transforme une hallucination en suppression de données, fuite de secrets ou config à moitié écrite. Un Virtual File System (VFS) enferme l’agent dans une vue jetable, auditable et réversible ; le disque réel n’est fusionné qu’après revue humaine ou CI.
1. Pourquoi pas d’écriture directe
Les agents codent à grande échelle avec confiance. Risques : échappement de chemin, rm -rf, écritures partielles, absence de diff auditable.
2. VFS : trois couches
- Base (lecture seule)
- Overlay (écriture)
- Publish (fusion)
3. Quatre modèles
Git worktree, OverlayFS/conteneur, sandbox distant, couche IDE. Les agents longue durée exigent une machine dédiée.
4. Permissions
- Écriture uniquement sous
$WORKSPACE/** .env*,secrets/refusés par défaut- Double porte API fichiers + shell
5. Écritures atomiques
Staging overlay → diff unifié → rename atomique → run_id pour rollback.
6. Secrets
Placeholders à l’exécution, masquage logs/diff, egress limité.
7. Exemple
def safe_resolve(path: str) -> Path:
p = (SANDBOX / path).resolve()
if not str(p).startswith(str(SANDBOX)):
raise PermissionError("path escape")
return p
8. Checklist
- ☐ Pas de shell illimité
- ☐ Liste blanche d’écriture
- ☐ Rollback par exécution
- ☐ Hôte dédié pour agents persistants
9. FAQ
Le VFS ralentit-il ?
Overhead ms–s, bien en dessous d’un aller-retour LLM.
Minimum pour petites équipes ?
Branche + PR, pas de push sur main.
Conflit Docker ?
Code en lecture seule, modifications dans la couche writable.
Multi-agents parallèles ?
Un worktree par agent, intégrateur pour fusionner.
Cursor = VFS ?
Outils contrôlés + règles workspace—même abstraction.
Mac cloud ?
Snapshots APFS et FS dédié pour agents longue durée.
Runners agent avec snapshots
Nuvcloud Mac mini M4—tarifs.