Sécurité et isolation des fonctions

01Isolation par compte

Chaque compte reçoit son propre namespace Kubernetes. C'est la frontière d'isolation, et tout y est posé à la création :

• Un quota de ressources qui plafonne CPU, mémoire et nombre de pods : un compte ne peut pas affamer les autres.
• Une NetworkPolicy en refus par défaut, en entrée comme en sortie : l'accès direct à un pod et le trafic entre comptes sont bloqués.
• Un accès internet sortant qui exclut explicitement les plages internes et le point de terminaison de métadonnées cloud (169.254.169.254), pour qu'une SSRF ne puisse pas voler d'identifiants d'infrastructure.
• Un compte de service et des droits RBAC propres au namespace, sans visibilité sur le reste du cluster.

02Comment votre code s'exécute

Votre code tourne dans un conteneur volontairement démuni. Rien de ce qui suit n'est laissé à votre charge ni modifiable : c'est la plateforme qui rend le manifeste, à l'identique pour tout le monde.

• Aucun privilège root : le conteneur s'exécute sous un utilisateur non privilégié, et l'élévation de privilèges est refusée par le noyau.
• Toutes les capacités Linux sont retirées. Un processus compromis n'a aucun droit noyau à récupérer, même en cas de faille dans votre dépendance.
• Système de fichiers racine en lecture seule. Seuls un /tmp éphémère et le répertoire de votre code sont montés, et ils disparaissent avec l'instance.
• Profil seccomp par défaut du moteur de conteneurs, qui restreint les appels système atteignables.
• Mémoire et processeur plafonnés par fonction : un dépassement tue l'instance fautive, sans effet sur les vôtres ni sur celles des autres.

Il n'existe pas de construction d'image par fonction. Votre code est injecté comme donnée dans une image d'exécution préconstruite et partagée, donc il n'y a aucune chaîne de compilation dans laquelle glisser quelque chose entre votre éditeur et l'exécution.

03Authentification en bordure

L'authentification est vérifiée en bordure, avant le routage vers votre fonction : clé API, propriétaire, statut du compte, crédit disponible et limitation de débit. Un appel non authentifié n'atteint jamais votre code, et ne réveille même pas un pod endormi, donc il ne vous coûte rien.

Conséquence directe sur la facturation : quand le crédit est épuisé, les invocations sont refusées à ce même point de contrôle, et les fonctions maintenues chaudes redescendent à zéro instance.

04Accès au compte

L'accès au compte est traité comme une surface d'attaque à part entière, pas comme un formulaire.

• Mots de passe hachés avec argon2 ; ils ne sont ni stockés ni journalisés en clair.
• Aucune fuite sur l'existence d'un compte : la connexion et la demande de réinitialisation répondent la même chose que l'adresse existe ou non. L'inscription ne connecte pas automatiquement, parce que ce raccourci commode était en réalité un oracle sur les adresses déjà inscrites.
• Réinitialisation par jeton à usage unique, haché en base et de courte durée. L'utiliser invalide du même coup les autres demandes ouvertes.
• Changer de mot de passe éjecte les sessions web en cours ET les accès MCP déjà émis, pas seulement leur renouvellement. Autrement, un agent garderait la main jusqu'à l'expiration de son jeton.
• Clés API affichées une seule fois, à la création, puis stockées hachées en SHA-256. Une clé égarée se révoque ; elle ne se retrouve pas, y compris par nous.

05Secrets et clés

Les valeurs sensibles sont traitées en écriture seule de bout en bout. La conséquence est inhabituelle et assumée : personne ne peut relire un secret, ni un agent, ni vous, ni nous.

• La valeur d'un secret n'existe que dans l'objet du cluster : la base de données ne conserve que le nom de la clé et des métadonnées, jamais la valeur.
• Aucune API, aucun outil MCP et aucune page ne peut relire un secret, pas même son propriétaire.
• Les clés API ne sont affichées qu'une fois à la création puis stockées hachées en SHA-256 ; les mots de passe sont hachés avec argon2.
• Le plan de contrôle lui-même n'a pas le droit de lire un secret dans le cluster : ses autorisations couvrent la création, la modification et la suppression, pas la lecture. Ce n'est pas une règle interne qu'on s'impose, c'est une permission qui n'existe pas.

06Votre base de données

Une base privée n'est jamais exposée sur Internet : elle n'a qu'une adresse interne au cluster, injectée dans vos fonctions. L'accès exige un jeton signé, dérivé de l'identifiant de cette base précise ; le jeton d'une autre base est refusé, et nous le vérifions sur un vrai cluster à chaque livraison.

Ce jeton n'est renvoyé par aucune API, aucune page de l'interface et aucun outil destiné aux agents. Il est monté depuis un secret en écriture seule, uniquement dans les fonctions que vous attachez. Quant aux identifiants du stockage objet, ils ne quittent jamais le serveur de base : vos propres fonctions ne les voient pas.

Le détail des bases de données »

07Ce qu'un agent IA peut faire

Un agent connecté en MCP n'obtient pas de privilèges supplémentaires : il agit avec exactement les droits de votre compte.

• Autorisation OAuth 2.1 avec PKCE et jeton lié à son audience ; changer votre mot de passe révoque immédiatement les autorisations en cours.
• Les outils destructifs sont annoncés comme tels dans le protocole, ce qui permet aux clients MCP de demander une confirmation avant d'agir.
• Les ressources d'un autre compte répondent 404 et non 403 : un agent ne peut même pas déduire leur existence.

Le détail du serveur MCP »

08Données, disponibilité, signalement

Les données de compte, l'historique de facturation et le code déployé sont hébergés en France. La collecte, les finalités et les durées de conservation sont détaillées dans la politique de confidentialité.

L'état des services en temps réel est publié sur status.zerolith.io.

Vous pensez avoir trouvé une faille ? Écrivez à contact@zerolith.io avec de quoi la reproduire. Nous répondons, et nous ne poursuivons pas une recherche menée de bonne foi.

09Questions fréquentes