Comment GnamiAI est construit.

Authentification

• Mots de passe hachés avec scrypt (N=2¹⁷, r=8, p=1, sortie de 32 octets) et un sel aléatoire de 16 octets par compte. La vérification est en temps constant. Une fuite de base de données ne révélerait pas les mots de passe.
• Jetons de session de 32 octets aléatoires. Le serveur ne stocke que le haché SHA-256; le jeton brut ne vit que dans le témoin de votre navigateur. Une fuite de base de données ne révélerait pas des sessions actives.
• Témoins de session HttpOnly, Secure, SameSite=Lax, et signés HMAC. Un témoin falsifié échoue à la bordure avant toute requête en base.
• Durée de session — 30 jours maximum absolu, 7 jours de plafond coulissant. Au-delà, la ligne est supprimée et vous vous reconnectez.

Matériel cryptographique au repos

Chaque clé API de fournisseur que vous connectez (OpenAI, Anthropic, OpenRouter, Ollama, Mem0) est chiffrée dans la base avec AES-256-GCM à l'aide d'une clé de chiffrement de 32 octets détenue comme variable d'environnement serveur. Chaque clé reçoit un IV de 12 octets neuf et une étiquette d'authentification de 16 octets. Changer la clé de chiffrement sans accès à la précédente rend chaque clé stockée un cryptogramme irrécupérable — l'opérateur en fait une sauvegarde.

La clé HMAC par requête qui signe vos témoins de session est aussi une variable d'environnement de 32 octets, distincte de la clé de chiffrement. La faire tourner invalide chaque session active par conception.

Isolement par locataire

Chaque table à portée locataire porte une colonne tenant_id. Chaque gestionnaire d'API non-admin commence par requireTenant(), qui revérifie votre session contre la base et retourne l'enregistrement du locataire. Chaque requête subséquente filtre par cet identifiant. Les points d'accès admin sont en plus protégés par requireAdmin() qui relit le drapeau is_admin depuis votre ligne de base à chaque appel — jamais depuis le témoin de session.

Un client trafiqué qui soumet l'identifiant d'un autre locataire ne peut ni lire ni modifier les données de ce locataire. Les gestionnaires serveur ignorent les identifiants fournis par l'appelant là où ça compte; le filtre est toujours le locataire de la session.

Garde-fous multi-locataires

• Limitation de débit — 20 tours de clavardage par minute par locataire. Le compte est lu depuis vos propres lignes de budget des 60 dernières secondes; un locataire ne peut pas consommer le quota d'un autre.
• Plafond d'entrée — 8000 caractères par tour, 250 Ko par récupération d'installation de SKILL.md.
• Plafonds de pièces jointes — max 5 fichiers par message, 2 Mo par fichier, 3,5 Mo au total.
• Plafonds de ressources par locataire — 50 compétences, 20 sous-agents, 10 planifications.

Protection SSRF

Deux fonctionnalités acceptent des URLs que vous fournissez : l'intégration Ollama (URL de base) et l'installation de compétence depuis une URL. Les deux passent l'URL dans une garde qui rejette :

• les schémas non-http(s) (file://, javascript:, etc.)
• les IP privées (10/8, 127/8, 172.16/12, 192.168/16)
• les adresses de lien-local et de point de terminaison de métadonnées (169.254/16)
• bouclage, CGNAT, et plages IPv6 unique-local / lien-local
• les noms d'hôtes réservés comme localhost et tout ce qui finit en .internal
• les URLs avec identifiants intégrés (user:pass@hôte)

Le réattachement DNS est un risque résiduel; nous le documentons plutôt que prétendre autrement. Pour le déploiement le plus sécurisé, les opérateurs font passer les récupérations par un proxy de sortie qui résout et épingle les IP.

Ce que GnamiAI ne peut explicitement pas faire

• Aucune exécution shell. GnamiAI hébergé n'a jamais et n'enregistrera jamais d'outil shell. C'est une décision au moment de la construction, pas un commutateur.
• Aucun accès au système de fichiers. L'agent n'a aucun accès en lecture/écriture au disque du serveur.