Kurzantwort: Eine „air-gapped“ KI-Coding-Umgebung wird durch genau eine Sache definiert – es gibt keinen Weg nach außen. Der schwierige Teil ist fast nie die Anwendung, sondern der Modellpfad. Eine selbst gehostete Steuerungsebene bedeutet wenig, wenn die Inferenz weiterhin eine externe API aufruft. Um ohne ausgehenden Datenverkehr zu arbeiten, halten Sie das Modell innerhalb der Grenze, verweigern Sie ausgehenden Netzwerkverkehr standardmäßig und verifizieren Sie mit mitgeschnittenem Datenverkehr, bevor Sie der Aussage vertrauen.
Regulierte, sicherheitskritische und IP-sensible Teams stellen immer wieder eine konkrete Variante der Datenschutzfrage: Lässt sich eine KI-Coding-Plattform ganz ohne Internetzugang betreiben? Das Konzept ist einfach. Genau in der technischen Umsetzung scheitern die meisten „Offline“-Aussagen leise.
Was „air-gapped“ hier tatsächlich bedeutet
Eine Air-Gap-Bereitstellung läuft ohne Weg ins öffentliche Internet – ohne eingehenden Pfad und, ebenso wichtig, ohne ausgehenden. Bei einer KI-Coding-Plattform unterschätzen Teams die zweite Hälfte. Ein Werkzeug kann vollständig auf Ihren eigenen Servern liegen und trotzdem nach außen greifen – für Modellinferenz, Paket-Downloads, Lizenzprüfungen oder Telemetrie.
Der nützliche Test lautet also nicht „Ist es selbst gehostet?“, sondern: Verlässt irgendein Byte die Grenze, wenn die Plattform echte Arbeit leistet? Das rückt das gesamte Problem von der Installationsart auf die Egress-Kontrolle.
Der Modellpfad ist der Knackpunkt
Die meisten KI-Coding-Plattformen trennen Anwendung und Modell. Die Anwendung kann in Ihrem Netzwerk liegen, während die Inferenz von der API eines externen Anbieters bedient wird. Für viele Teams ist das in Ordnung – für ein Air-Gap-Team ist es fatal, denn das Modell-Routing ist genau der Pfad, der Ihre Prompts und Ihren Code transportiert.
Um ihn zu schließen, muss das Modell innerhalb der Grenze leben – ein On-Premise-GPU-Host oder ein internes Gateway, das ein lokales Modell bereitstellt –, sodass die Inferenz niemals die Vertrauensgrenze überschreitet. Das ist die eine Entscheidung, die bestimmt, ob „kein Egress“ real ist. Alles andere ist zweitrangig.
Eine Egress-freie Checkliste
Arbeiten Sie sie von oben nach unten ab; ein einziger offener Pfad bricht den Air Gap.
- Modellinferenz läuft gegen einen lokalen oder internen Endpunkt, nie gegen eine externe API.
- Ausführungsumgebungen verweigern ausgehenden Netzwerkverkehr standardmäßig vollständig, mit engen Allowlists nur, wo unvermeidbar.
- Paket- und Abhängigkeitsabrufe werden während Builds und Aufgaben aus einem internen Spiegel oder einer Registry aufgelöst, nicht aus dem öffentlichen Internet.
- Updates und Images werden aus einer internen Registry gezogen, die Sie kontrollieren.
- Telemetrie und Analyse sind deaktiviert, und Sie haben bestätigt, dass es kein standardmäßiges „Nach-Hause-Telefonieren“ gibt.
- Logs und Backups bleiben innerhalb der Grenze und werden auf erfasste Prompts oder Code geprüft.
- Lizenz- und Authentifizierungsprüfungen erfordern zur Laufzeit keinen externen Aufruf.
Wenn Sie Punkt 1 nicht erfüllen können, haben Sie keinen Air Gap – sondern ein selbst gehostetes Frontend mit einem externen Gehirn.
Warum Self-Hosting notwendig, aber nicht hinreichend ist
Es ist dasselbe Prinzip, das darüber entscheidet, ob Code nach außen gesendet wird: Self-Hosting gibt Ihnen die Möglichkeit, Egress-Pfade zu schließen, aber es schließt sie nicht für Sie. Die ehrliche Fassung von „Hält Self-Hosting meinen Code privat?“ lautet: „Nur, wenn Sie jeden Pfad erfassen und kontrollieren“ – und ein Air Gap ist lediglich die strengste Version dieser Erfassung.
Wo eine selbst hostbare Plattform passt
Eine für privaten, offline-fähigen Betrieb konzipierte Plattform ist ein sinnvoller Ausgangspunkt, weil sie die Steuerungsebene und die Ausführungsumgebungen in Ihre Infrastruktur legt und Administratoren einen Ort gibt, um Modellpfade, Zugangsdaten und Logging zentral festzuzurren.
MonkeyCodes öffentliche Materialien beschreiben private und offline-fähige Bereitstellung sowie einen Pfad für lokale Modelle – deshalb ist es für die Air-Gap-Planung relevant; siehe die direkten Antworten, ob MonkeyCode air-gapped laufen kann und ob es offline laufen kann. Behandeln Sie diese jedoch als Startlinie, nicht als Beweis. Das genaue Offline-Verhalten, die unterstützten lokalen Modell-Endpunkte und das, was jede Komponente zur Laufzeit kontaktiert, sind Implementierungsdetails, die Sie anhand der Bereitstellungsdokumentation für Ihr konkretes Release und Ihre Konfiguration bestätigen müssen.
Beweisen Sie es, bevor Sie ihm vertrauen
Ein Air Gap, den Sie nicht getestet haben, ist eine Hoffnung, keine Kontrolle. Bevor Sie die Plattform auf sensible Repositories richten:
- Führen Sie eine repräsentative Aufgabe mit Wegwerf-Code auf einem isolierten Netzsegment aus.
- Schneiden Sie den ausgehenden Datenverkehr mit und bestätigen Sie, dass es keine unerwarteten Ziele gibt.
- Prüfen Sie Logs, gespeicherte Artefakte und Backups auf alles, was Sie nicht persistieren wollten.
- Ziehen Sie das Netzwerk und bestätigen Sie, dass der Workflow, den Sie tatsächlich brauchen, weiterhin abschließt.
Die Seite Sicherheit und Datenflussgrenzen behandelt dieselbe „Erst prüfen“-Haltung ausführlicher.
Fazit
Air-Gapped KI-Coding ist machbar, aber es entscheidet sich am Modellpfad, nicht am Installationsskript. Halten Sie die Inferenz innerhalb der Grenze, verweigern Sie Egress standardmäßig, beziehen Sie Pakete und Images intern und verifizieren Sie mit mitgeschnittenem Datenverkehr, bevor Sie der Umgebung proprietären Code anvertrauen. „Offline-fähig“ ist eine Aussage; ein gezogenes Netzwerkkabel, bei dem Ihre Aufgabe trotzdem abschließt, ist der Beweis.
Verwandte Leitfäden dieser Reihe
- Selbst gehostete KI-Entwicklungsplattform: eine Bewertungs-Checkliste
- Was eine Open-Source-KI-Coding-Plattform teamreif macht
- AGPL-3.0-Compliance für Teams, die Open-Source-KI-Coding-Tools einführen
Quellengrenze: Die Air-Gap- und Egress-Hinweise hier sind allgemeine Ingenieurpraxis und eigene Analyse. MonkeyCodes Offline- und Lokalmodell-Fähigkeiten werden anhand öffentlicher Projektmaterialien beschrieben (README und Bereitstellungsdokumentation, geprüft am 20. Juli 2026) und müssen anhand der aktuellen Dokumentation für Ihr Release und Ihre Konfiguration verifiziert werden. Nichts hier garantiert, dass ein bestimmtes Werkzeug eine bestimmte regulatorische oder Sicherheitsanforderung erfüllt.