Modele de securite

Comment VaultTools MCP protege vos fichiers : sandboxing, isolation et traitement previsible.

Sandboxing par repertoire

Chaque operation sur les fichiers est validee par rapport a la liste --allowed-dir avant execution. Les chemins sont canonicalises sous forme absolue, empechant les attaques par traversee via ../ ou les liens symboliques. Si un chemin resolu sort de tous les repertoires autorises, l'operation est rejetee avec une erreur ACCESS_DENIED.

Vous pouvez specifier plusieurs repertoires autorises en repetant le flag : --allowed-dir ~/Documents --allowed-dir ~/Pictures. Le serveur refuse de demarrer sans au moins un repertoire autorise.

Isolation des sorties

Quand --output-dir est defini, tous les fichiers de sortie sont ecrits dans ce repertoire au lieu d'etre places a cote des fichiers d'entree. Cela separe les resultats traites des originaux.

Les fichiers de sortie n'ecrasent jamais les fichiers existants. Le serveur ajoute un suffixe numerique (-1, -2, etc.) pour eviter les collisions. Les appels repetes sont donc toujours surs. Ils creent de nouveaux fichiers plutot que de detruire les donnees existantes.

Assainissement des erreurs

Les messages d'erreur retournes au modele IA sont tronques a 500 caracteres. Cela empeche la fuite accidentelle de contenu de fichier via des messages d'erreur verbeux (par ex., une erreur d'analyse JSON incluant un extrait du fichier).

Les erreurs contiennent suffisamment d'information pour que l'IA puisse reessayer ou signaler le probleme, mais n'incluent jamais de donnees brutes du fichier.

Traitement sans etat

Chaque appel d'outil est totalement independant. Le serveur ne conserve aucun etat entre les appels : pas de cache, pas de donnees de session, pas de fichiers temporaires. Chaque invocation lit depuis le disque, traite en memoire, et ecrit sur le disque.

Les appels d'outils sont donc idempotents : appeler le meme outil avec les memes entrees produit toujours la meme sortie (a l'exception des suffixes d'evitement de collision sur les noms de fichiers de sortie).

Aucune telemetrie

Le serveur ne fait aucune requete reseau. Il n'y a pas d'analytics, pas de rapport de crash, pas de verification de mise a jour, et aucun comportement de type phone-home. La communication se fait exclusivement via stdio (stdin/stdout) avec le client MCP.

Les logs sont ecrits sur stderr (pas stdout, reserve au JSON-RPC MCP) et sont desactives par defaut. Activez-les avec --verbose pour le debogage.

Verification par hash

Les outils vaulttools_file_checksum et vaulttools_dev_hash permettent de verifier l'integrite des sorties. Apres toute transformation de fichier, calculez un checksum sur la sortie pour confirmer qu'elle correspond aux attentes.

Algorithmes disponibles : MD5, SHA-1, SHA-256, SHA-512. Les checksums sont calcules localement et retournes comme metadonnees. Le contenu du fichier n'est jamais inclus dans la reponse.

E/S basées sur les chemins

C'est le principe de conception fondamental. L'agent IA envoie des chemins de fichiers en entree. Le serveur lit les fichiers, les traite, ecrit la sortie, et ne retourne que des metadonnees (chemin de sortie, taille du fichier, dimensions, checksums, etc.).

Les octets des fichiers n'apparaissent jamais dans la reponse MCP. Vos fichiers n'entrent donc pas dans la fenetre de contexte du modele IA, ne sont envoyes a aucune API distante, et ne sont pas inclus dans l'historique de conversation.