Sécurité et confidentialité,
pour votre revue.

Gnista est une app Mac qui surveille vos agents de code et permet de leur répondre depuis l’encoche. Cette page s’adresse à celles et ceux qui l’examinent avant qu’elle n’arrive sur les Mac d’une entreprise : ce qu’elle lit, ce qu’elle envoie, et ce qui se passe quand quelque chose tourne mal.

Mis à jour le 27 oct. 2026

En bref

Tourne sur le Mac. Ni compte, ni télémétrie, ni statistiques.
Rien des sessions, du code ou des prompts de qui que ce soit ne quitte le Mac.
Uniquement les requêtes réseau listées ci-dessous, et rien d’autre.
Il n’approuve jamais rien tout seul. Dans le doute, l’agent demande dans sa propre invite.
Signé avec un Developer ID, notarisé par Apple, compilé avec le runtime renforcé (hardened runtime).

Ce que Gnista lit

Les événements des hooks des agents, envoyés par son petit utilitaire via un socket Unix dans le dossier de Gnista, dans Application Support. Uniquement en local : la seule écoute réseau, quand les conteneurs sont activés, est un port sur la boucle locale (loopback) du Mac qui demande un mot de passe. Les événements d’une machine distante arrivent par le propre ssh de l’utilisateur, vers un socket qui leur est réservé sur le Mac.
Les fichiers de session et les configs des agents, là où ils sont, pour les titres, la progression, le coût et les limites du forfait.
Son propre élément de trousseau, qui contient la clé de licence et le début de l’essai, que ses préférences gardent aussi. Jamais synchronisé.
Seulement avec permission : l’Automatisation et l’Accessibilité, pour mettre au premier plan le bon onglet de terminal ou la bonne fenêtre d’éditeur. Les deux sont facultatives.

Ce qu’il ne fait jamais

Il ne lit pas les éléments de trousseau des autres apps, ni aucun identifiant.
Il ne sonde pas les ports et n’analyse pas le réseau.
Il n’envoie ni télémétrie ni statistiques à aucun service, et n’a pas de compte. Un rapport de plantage ne part que si l’utilisateur l’accepte, ou si l’organisation a réglé CrashReportsMode sur always.
Il ne modifie la config d’un agent qu’à ses propres entrées : chaque config est d’abord sauvegardée, la mise en forme et l’ordre des clés sont conservés, et déconnecter un agent retire exactement les lignes de Gnista.

Chaque requête réseau

Serveur	Requête	Quand, et ce qu’elle envoie
`gnista.sh`	Recherche de mises à jour	Environ une fois par jour tant que les mises à jour automatiques sont activées. Envoie l’adresse IP, comme toute requête, et la version de Gnista. Aucun profil du Mac.
`github.com`	Téléchargements : mises à jour ; l’utilitaire Linux	Une mise à jour, une fois qu’une recherche en a trouvé une, et quand une machine distante connectée en a besoin, l’utilitaire Linux pour cette version et ce processeur : depuis les téléchargements publics de Gnista (github.com/BlixtDunder/gnista-downloads, servis par release-assets.githubusercontent.com). Envoie l’adresse IP, comme toute requête. Chacun n’est utilisé que s’il est signé avec la clé de Gnista.
`report.gnista.sh`	Licence ; rapports de plantage	Licence : à l’activation d’une clé, la clé et le nom du Mac comme libellé de l’activation ; puis environ une fois par semaine pour la vérifier ; et quand elle est retirée, pour libérer la place du Mac, à chaque fois avec la clé et l’identifiant d’activation de ce Mac. Le relais de Gnista ne transmet que cela à Creem, le revendeur officiel (merchant of record), et ne garde rien de la licence, hormis un compte des requêtes par adresse, sous forme de hash salé, oublié le lendemain. Rien sur les agents, les projets ou l’usage. Rapports de plantage : seulement après un plantage de Gnista ou de son utilitaire, et seulement si l’utilisateur l’accepte, a choisi de toujours les envoyer, ou si l’organisation a réglé `CrashReportsMode` sur `always` : l’erreur, le moment et l’endroit du code de Gnista où elle s’est produite, les noms des files d’attente de ses threads, les noms et adresses des bibliothèques qu’il avait chargées, les versions de Gnista et de macOS, le modèle et l’architecture de processeur du Mac, et un identifiant aléatoire créé pour les rapports de plantage. Ni noms d’utilisateur, ni chemins de fichiers, ni projets, ni prompts, ni code. Le relais de Gnista, hébergé en Suède, l’envoie par e-mail à l’équipe de Gnista et n’en garde aucune copie.
`ssh`	Machines distantes	Seulement pour une machine connectée dans Réglages ▸ À distance, via le propre `ssh` et la config ssh de l’utilisateur, ou `kubectl` pour un pod : l’installation de son utilitaire et des hooks de ses agents, une connexion qui amène leurs événements sur le Mac et ramène les réponses (aucune quand Connexion est réglé sur `manual`), et, sur un clic, l’affichage du volet tmux d’un agent. Rien ne part vers l’équipe de Gnista.
`ampcode.com`	Fils Amp	Seulement pour une session Amp sur une ligne : Gnista lance la propre CLI d’Amp (`amp threads export`, `amp threads usage`, `amp usage`), connectée avec le compte de l’utilisateur, qui lit depuis Amp le fil, son coût et les crédits du compte. Gnista n’y ajoute rien de son côté ; rien ne part vers l’équipe de Gnista.
`raw.githubusercontent.com`	Prix des modèles	Seulement avec le réglage Utilisation activé : la liste de prix publique des modèles de LiteLLM, au plus une fois par jour. Un simple téléchargement ; rien sur l’utilisateur ne l’accompagne.

Désactiver les mises à jour automatiques (ou AutomaticUpdates à false par votre MDM) arrête la recherche de mises à jour. L’essai n’a besoin de rien en ligne, et une fois activée, une clé personnelle fonctionne hors ligne ; une clé équipe a besoin d’une vérification de temps en temps, pour les versions sorties plus de 30 jours après la dernière. RemoteMachinesAllowed à false ferme tous les tunnels et empêche quiconque de connecter un serveur.

Des validations sûres en cas d’échec

Répondre aux demandes dans Gnista est un réglage, pour les agents qui peuvent recevoir une réponse depuis l’encoche, comme Claude Code, Codex et OpenCode. Une requête n’est autorisée que si une personne l’autorise, et Autoriser attend une demi-seconde avant de pouvoir être cliqué. Rien n’est approuvé par défaut.

Pas de réponse dans Gnista : Claude Code affiche sa propre invite en même temps, et la première réponse l’emporte. Les autres agents récupèrent la requête et demandent dans leur propre invite, comme d’habitude : tout de suite quand vous allez dans leur onglet, après 10 secondes quand l’encoche est fermée, et après 45 secondes au plus pendant que vous êtes dans l’encoche.
Gnista n’est pas lancé : le hook ne trouve personne à l’écoute et rend la main aussitôt. L’agent demande dans sa propre invite.
Gnista verrouillé (essai terminé, pas de licence) : chaque requête est rendue aussitôt, sans attendre.
Les hooks ne bloquent jamais un agent : les hooks d’état répondent en 30 ms environ et se terminent toujours proprement.
Machines distantes : l’utilitaire installé sur la machine n’attend l’encoche que tant que les réponses dans Gnista sont activées. Toute personne ayant les droits root sur cette machine peut répondre à ses demandes d’autorisation, comme les Réglages le signalent quand une machine est connectée.
Vos règles : avec un abonnement équipe, votre MDM peut désactiver les réponses dans Gnista ou les limiter à certains agents. Voir Gnista par MDM.

Machines distantes

Gnista peut afficher les agents qui tournent sur un serveur, dans un conteneur ou dans un pod Kubernetes, et leur répondre depuis l’encoche. C’est désactivé tant que personne ne connecte de machine, et RemoteMachinesAllowed à false le garde désactivé.

Le propre ssh de l’utilisateur : Gnista lance le ssh du Mac avec la config ssh, les clés et l’agent de l’utilisateur, comme il le ferait lui-même. Il ne stocke ni mot de passe ni clé ; quand la connexion demande une personne (un mot de passe, la 2FA), Se connecter ouvre Terminal pour cela. Les pods passent par le propre kubectl de l’utilisateur.
Un utilitaire signé, sans root, sans démon : Gnista copie son utilitaire dans ~/.gnista, dans le dossier personnel de l’utilisateur sur la machine, et ajoute ses lignes aux configs des agents là-bas, comme sur le Mac. L’utilitaire Linux est signé avec la clé de Gnista, et Gnista refuse celui dont la signature ne correspond pas ; la clé publique est sur gnista.sh/downloads/linux/gnista-linux.pub. Il n’a pas besoin de root, n’installe aucun service, et ne tourne que quand le hook d’un agent l’appelle.
Un socket par Mac : chaque Mac qui connecte une machine y obtient son propre socket, lisible seulement par cet utilisateur. Les conteneurs sur le Mac le joignent par un port sur la boucle locale du Mac, et chaque connexion doit commencer par un mot de passe aléatoire, gardé dans ~/.gnista/containers pour les conteneurs qui le montent.
Déconnecter retire les lignes de Gnista des configs des agents là-bas et supprime ~/.gnista, sauf si un autre Mac s’en sert encore.

Quand vos outils de sécurité signalent les tunnels

Chaque machine a un réglage Connexion, et avec un abonnement équipe, RemoteConnection dans votre MDM le règle pour tous les Mac :

Automatique (automatic) : la propre connexion ssh de Gnista redirige le socket de la machine vers le Mac ; là où le serveur ne redirige aucun socket, un port sur sa boucle locale qui demande un mot de passe ; et là où il ne redirige rien, comme Sans redirection.
Sans redirection (relay) : aucune redirection. L’utilitaire transporte les messages des hooks par l’entrée et la sortie d’une commande ssh ordinaire, comme pour un pod Kubernetes.
Par mon propre ssh (manual) : Gnista n’ouvre aucune connexion. Configurer installe l’utilitaire une fois et donne une ligne RemoteForward pour la config ssh de l’utilisateur ; ses propres sessions ssh transportent ensuite les événements des agents. Avec StreamLocalBindUnlink yes dans le sshd_config du serveur, une session qui suit une session coupée se connecte aussitôt.

Ce qu’il garde sur le Mac

Dans son dossier d’Application Support : les sessions terminées récemment, les dernières limites du forfait, la liste des prix des modèles, des sauvegardes des configs d’agents qu’il a modifiées, les rapports de plantage pas encore envoyés (supprimés après 30 jours), les utilitaires Linux qu’il a téléchargés, et les propres fichiers d’agents, de modèles et de règles de saut de l’utilisateur. Ses réglages vivent dans son domaine de préférences, sh.gnista.Gnista ; sa clé de licence et le début de l’essai, dans son propre élément de trousseau, et le début de l’essai aussi dans ses préférences. Retirer les intégrations de Gnista depuis les Réglages enlève ses lignes de la config de chaque agent.

Signature et mises à jour

Gnista est signé avec un Developer ID, notarisé par Apple et compilé avec le runtime renforcé : il s’ouvre sans avertissement, et macOS vérifie qu’il n’a pas été modifié. Gnista trouve les mises à jour sur gnista.sh et les télécharge via Sparkle depuis ses téléchargements publics sur GitHub, et chacune est signée avec notre clé EdDSA ; Gnista refuse une mise à jour dont la signature ne correspond pas.

Il n’est pas en bac à sable, et ne peut pas l’être : il doit lire les fichiers des agents et modifier leurs configs. C’est aussi pour cela qu’il n’est pas sur le Mac App Store.

Des questions

Votre revue a besoin de quelque chose qui n’est pas ici ? Écrivez à support@gnista.sh. Plus d’infos sur le site et l’achat : Confidentialité.