Sicherheit und Datenschutz,
für eure Prüfung.

• Läuft auf dem Mac. Kein Account, keine Telemetrie, keine Analytics.
• Nichts über Sitzungen, Code oder Prompts von irgendwem verlässt den Mac.
• Nur die unten aufgelisteten Netzwerkanfragen, und sonst nichts.
• Es erlaubt nie etwas von selbst. Im Zweifel fragt der Agent in seinem eigenen Prompt.
• Signiert mit einer Developer ID, notarisiert von Apple, gebaut mit der Hardened Runtime.

• Events aus den Hooks der Agents, die sein kleiner Helper über einen Unix-Socket in Gnistas Ordner unter Application Support schickt. Nur lokal: Der einzige Netzwerk-Listener, bei eingeschalteten Containern, ist ein Port auf dem Loopback des Macs, der nach einem Passwort fragt. Die Events eines entfernten Rechners kommen über das eigene ssh des Nutzers zu einem eigenen Socket auf dem Mac.
• Die eigenen Sitzungsdateien und Configs der Agents, dort, wo sie liegen, für Titel, Fortschritt, Kosten und Abolimits.
• Seinen eigenen Schlüsselbund-Eintrag mit dem Lizenzschlüssel und dem Beginn der Testphase, den auch seine Einstellungen speichern. Nie synchronisiert.
• Nur mit Erlaubnis: Automation und Bedienungshilfen, um den richtigen Terminal-Tab oder das richtige Editor-Fenster nach vorn zu holen. Beides ist optional.

• Es liest keine Schlüsselbund-Einträge anderer Apps und keine Zugangsdaten.
• Es scannt keine Ports und durchsucht nicht das Netzwerk.
• Es sendet keine Telemetrie und keine Analytics an irgendeinen Dienst, und es hat keinen Account. Ein Absturzbericht geht nur raus, wenn der Nutzer zustimmt oder die Organisation CrashReportsMode auf always gesetzt hat.
• Es ändert die Config eines Agents nur in seinen eigenen Einträgen: Jede Config wird vorher gesichert, Formatierung und Reihenfolge der Schlüssel bleiben erhalten, und das Trennen eines Agents entfernt genau Gnistas Zeilen.

Automatische Updates auszuschalten (oder AutomaticUpdates von eurem MDM auf false gesetzt) beendet die Suche nach Updates. Die Testphase braucht nichts online, und einmal aktiviert, funktioniert ein persönlicher Schlüssel offline; ein Team-Schlüssel braucht ab und zu eine Prüfung, für Builds, die mehr als 30 Tage nach seiner letzten erscheinen. RemoteMachinesAllowed auf false schließt jeden Tunnel, und niemand kann mehr einen Server verbinden.

Anfragen in Gnista zu beantworten ist eine Einstellung, für die Agents, die eine Antwort aus der Notch annehmen können, etwa Claude Code, Codex und OpenCode. Eine Anfrage wird nur erlaubt, wenn ein Mensch sie erlaubt, und „Erlauben“ lässt sich erst nach einer halben Sekunde drücken. Nichts wird standardmäßig erlaubt.

• Keine Antwort in Gnista: Claude Code zeigt gleichzeitig seinen eigenen Prompt, und was zuerst beantwortet wird, gilt. Die anderen Agents bekommen die Anfrage zurück und fragen wie gewohnt in ihrem eigenen Prompt: sofort, wenn du in ihren Tab gehst, nach 10 Sekunden bei geschlossener Notch und nach höchstens 45 Sekunden, solange du in der Notch bist.
• Gnista läuft nicht: Der Hook findet niemanden, der zuhört, und kehrt sofort zurück. Der Agent fragt in seinem eigenen Prompt.
• Gnista gesperrt (Testphase vorbei, keine Lizenz): Jede Anfrage geht sofort zurück, ohne Warten.
• Hooks blockieren nie einen Agent: Status-Hooks kehren in rund 30 ms zurück und beenden sich immer sauber.
• Entfernte Rechner: Der Helper dort wartet nur auf die Notch, solange das Beantworten in Gnista an ist. Wer auf diesem Rechner root ist, kann seine Freigaben beantworten; das sagen auch die Einstellungen, sobald ein Rechner verbunden ist.
• Eure Regeln: Mit einem Team-Plan kann euer MDM das Beantworten in Gnista abschalten oder auf einige Agents beschränken. Siehe Gnista per MDM.

Gnista kann Agents zeigen, die auf einem Server, in einem Container oder in einem Kubernetes-Pod laufen, und ihnen aus der Notch antworten. Es ist aus, bis jemand einen Rechner verbindet, und RemoteMachinesAllowed auf false hält es aus.

• Das eigene ssh des Nutzers: Gnista startet das ssh des Macs mit der ssh-Config, den Schlüsseln und dem Agent des Nutzers, so wie er selbst. Es speichert keine Passwörter oder Schlüssel; braucht die Anmeldung einen Menschen (ein Passwort, 2FA), öffnet „Anmelden“ dafür das Terminal. Pods laufen über das eigene kubectl des Nutzers.
• Ein signierter Helper, kein root, kein Daemon: Gnista kopiert seinen Helper nach ~/.gnista im Home-Verzeichnis des Nutzers dort und fügt seine Zeilen in die Configs der Agents dort ein, wie auf dem Mac. Der Linux-Helper ist mit Gnistas Schlüssel signiert, und Gnista lehnt einen ab, dessen Signatur nicht passt; der öffentliche Schlüssel liegt unter gnista.sh/downloads/linux/gnista-linux.pub. Er braucht kein root, installiert keinen Dienst und läuft nur, wenn der Hook eines Agents ihn aufruft.
• Ein Socket pro Mac: Jeder Mac, der einen Rechner verbindet, bekommt dort einen eigenen Socket, den nur dieser Nutzer lesen kann. Container auf dem Mac erreichen ihn über einen Port auf dem Loopback des Macs, und jede Verbindung muss mit einem zufälligen Passwort beginnen, das für die Container, die es einbinden, in ~/.gnista/containers liegt.
• Trennen nimmt Gnistas Zeilen aus den Configs der Agents dort und entfernt ~/.gnista, außer ein anderer Mac nutzt es noch.

Jeder Rechner hat die Einstellung Verbindung, und mit einem Team-Plan legt RemoteConnection in eurem MDM sie für jeden Mac fest:

• Automatisch (automatic): Gnistas eigene ssh-Verbindung leitet den Socket des Rechners an den Mac weiter; wo der Server keine Sockets weiterleitet, ein Port auf seinem Loopback, der nach einem Passwort fragt; und wo er gar nichts weiterleitet, wie ohne Weiterleitung.
• Ohne Weiterleitung (relay): überhaupt keine Weiterleitung. Der Helper trägt die Nachrichten der Hooks über Ein- und Ausgabe eines gewöhnlichen ssh-Befehls, wie bei einem Kubernetes-Pod.
• Über mein eigenes ssh (manual): Gnista öffnet keine Verbindung. „Einrichten“ installiert den Helper einmal und gibt eine RemoteForward-Zeile für die ssh-Config des Nutzers; danach tragen seine eigenen ssh-Sitzungen die Events der Agents. Mit StreamLocalBindUnlink yes in der sshd_config des Servers verbindet sich eine Sitzung nach einer abgebrochenen sofort.

In seinem Ordner unter Application Support: kürzlich beendete Sitzungen, die letzten Abolimits, die Preisliste der Modelle, Sicherungen der Agent-Configs, die es geändert hat, noch nicht gesendete Absturzberichte (nach 30 Tagen gelöscht), die heruntergeladenen Linux-Helper und die eigenen Agent-, Modell- und Sprungregel-Dateien des Nutzers. Seine Einstellungen liegen in seiner Preference Domain, sh.gnista.Gnista; Lizenzschlüssel und Beginn der Testphase in seinem eigenen Schlüsselbund-Eintrag, der Beginn der Testphase auch in seinen Einstellungen. Gnistas Integrationen in Einstellungen zu entfernen, nimmt seine Zeilen aus der Config jedes Agents.

Gnista ist mit einer Developer ID signiert, von Apple notarisiert und mit der Hardened Runtime gebaut, es öffnet also ohne Warnungen, und macOS prüft, dass es nicht verändert wurde. Gnista findet Updates auf gnista.sh und lädt sie über Sparkle aus Gnistas öffentlichen Downloads auf GitHub, und jedes ist mit unserem EdDSA-Schlüssel signiert; Gnista lehnt ein Update ab, dessen Signatur nicht passt.

Es läuft nicht in einer Sandbox und kann es auch nicht: Es muss die Dateien der Agents lesen und ihre Configs bearbeiten. Deshalb ist es auch nicht im Mac App Store.

Eure Prüfung braucht etwas, das hier fehlt? Schreibt an support@gnista.sh. Mehr zur Website und zum Kauf: Datenschutz.