Air-Gapped KI-Code-Prüfung
Zuletzt aktualisiert: 2026-07-17Lesezeit ca. 4 Min.
ausgewählte KI-Code-Prüfung kann ohne öffentliches Netz laufen, wenn Quellcode, Toolchains, Dependencies, Fixtures, Dienste, Policy und ein optionales lokales Modell innerhalb der Grenze provisioniert sind. Trennung vom Netz, lokale Verarbeitung, Offline-Betrieb, Secrets-Handling und Prüfung sind getrennte Kontrollen. Keine davon garantiert allein Datenschutz, Sicherheit, Korrektheit oder Compliance.
Kurz: Trennt erst das Netz und prüft dann jeden Weg für Daten und Code. Legt fest, was im Raum liegt, wer es nutzt und wie ein Paket hinein oder ein Beleg hinaus darf. Haltet jede Lücke fest. Ein Lauf ohne Netz kann Wege sperren. Er sagt nicht, ob der Code gut ist. Tests, klare Regeln und ein Mensch bleiben nötig.
Beginnt mit einer Liste der Teile im Raum: Repo, Build, Tests, Modell und Pakete. Markiert jeden Pfad über die Grenze.
Prüft dann für jeden Pfad, wer ihn frei gibt, was er trägt und wie ihr den Vorgang belegt. Plant auch den Fall, dass ein Tool fehlt oder ein Paket alt ist. Führt die nötigen Checks vor Ort aus. Lasst den Befund von der zuständigen Person lesen. So zeigt der Ablauf, was lief und was offen blieb. Er macht aus einem Netz-Gap kein Gütesiegel.
Inhalt
Was Isolation ändert - und was sie nicht beweist
NIST SP 800-53 Rev. 5.1, geprüft am 17. Juli 2026, behandelt Boundary Protection und Network Disconnect als ausdrückliche Security-Kontrollen, nicht als vollständiges Security-Ergebnis. Die Kontrollen SC-7 und SC-10 begrenzen Kommunikationspfade. Prüfung braucht weiterhin deklarierte Kriterien, verfügbare Eingaben, ausgewählte Checks, Ergebnisinterpretation, Restrisiko-Review und einen benannten Entscheidungsinhaber.
Was offline geht, abgebildet
| Schicht | Offline-Status | Was es braucht |
|---|---|---|
| Schriftlicher Auftrag (die Referenz) | Kann lokal gelesen werden | Aktuelle Revision, Zugriff, Annahmen und Konfliktprüfung |
| Deterministische Checks (Build, Typen, Tests, Linter, Secret-Scan) | Kann lokal laufen, wenn Eingaben vorhanden sind | Toolchains, Dependencies, Lizenzen, Fixtures, Dienste und aktuelle Regeldaten |
| LLM-Urteils-Schicht | Optionale lokale Verarbeitung | Freigegebene Modell-Provenienz, Integrität, Fähigkeit, Setup und Hardware |
| Belege pro Run | Kann lokal gespeichert werden | Integrität, Zurechnung, Zeitstempel, Aufbewahrung, Zugriff, Review und Export-Policy |
| Erzeugung (zum Kontrast) | Auf provisionierte lokale Fähigkeit begrenzt | Keine Annahme, dass Auftragsstruktur fehlende Fähigkeit kompensiert |
Die Hardware-Seite der dritten Zeile steht in Lokales LLM fürs Code-Review. Hardware ist nur eine Abhängigkeit. NIST SP 800-161 Rev. 1 Update 1, aktualisiert im November 2024 und geprüft am 17. Juli 2026, behandelt Provenienz, Beschaffung, Integration und Wartung als fortlaufende Supply-Chain-Risiken. Ein interner Mirror oder eine Allowlist kann Namen außerhalb ihrer Policy abweisen, aber veraltet, fehlkonfiguriert oder mit einem kompromittierten legitimen Artefakt bestückt sein; Isolation beseitigt dieses Restrisiko nicht.
Der Workflow, der zum Gap passt
- Präzise schriftliche Aufträge. Ein schriftlicher Auftrag gibt Erzeugung und Prüfung eine deklarierte Referenz; Annahmen und Ausschlüsse halten seine Abdeckung sichtbar. Fehlende oder schwächere Tools kompensiert er nicht automatisch. Die prüfbare Form ist dieselbe wie überall.
- Kleine Änderungen, jede verifiziert. Begrenzte Diffs können den Review-Scope leichter prüfbar machen. Sie beweisen keine Testabdeckung.
- Deterministische Schicht zuerst, Modell danach. Lokal verfügbare deterministische Checks ausführen und festhalten, was jeder abdeckte oder übersprang. Optionale Modellbefunde bleiben nichtdeterministische Belege mit Review-Bedarf.
- Belege beim Code. Ergebnisse, Eingaben, Versionen, Auslassungen und offene Risiken lokal speichern, wo die Policy es verlangt. Eine Aufzeichnung ist ein Belegartefakt, kein Audit-Ergebnis und keine Freigabe.
Die am 4. Oktober 2024 veröffentlichten ANSSI/BSI-Empfehlungen beschreiben Security-Risiken und Kontrollen für KI-Programmierassistenten über Deployment-Modelle hinweg. Die gemeinsamen Empfehlungen sind Guidance, keine Zertifizierung dieser Aufbau und kein Beleg, dass ein Air Gap generierten Code sicher macht.
Die ehrlichen Grenzen
Trennung vom Netz begrenzt Kommunikationspfade. Lokale Verarbeitung benennt den Rechenort. Offline-Betrieb beschreibt einen gemessenen Laufzeitzustand. Secrets-Handling regelt Zugriff und Transfer. Prüfung vergleicht ausgewählte Belege mit deklarierten Kriterien. Keines impliziert das andere.
Restrisiken umfassen Wechselmedien, Transferstationen, Insider, verwundbare Endpunkte, veraltete Dependencies und Regeln, kompromittierte provisionierte Artefakte, schwache Credentials, unvollständige Tests und falsche menschliche Interpretation. Teams brauchen Bedrohungsmodell und verantwortliche Freigabe für ihre echte Umgebung; lokale Verarbeitung ohne Gap adressiert eine andere Aufbau und ist getrennt zu bewerten.
Wo Reality Graph ansetzt
Reality Graph kann deklarierte Aufträge, ausgewählte Checkergebnisse und Belegdateien in einer lokal kontrollierten Umgebung speichern, wenn es entsprechend deployt und eingerichtet ist. Die Prüfberichte können beim Code bleiben. Operatoren müssen tatsächliche Netzaufrufe, Dependencies, Telemetrie, Modell-Endpunkte, Secrets, Transferpfade, Zugriff und Aufbewahrung weiter prüfen; die Produktseite dieser Frage, was Reality Graph selbst überträgt, steht an eigener Stelle. Reality Graph macht eine Umgebung nicht air-gapped und garantiert weder Datenschutz, Sicherheit, Korrektheit, Compliance, Belegintegrität noch Freigabequalität.
Offline-Prüfung gibt euch
- Einen Weg für ausgewählte lokal provisionierte Checks ohne öffentliches Netz
- Lokale Belegspeicherung, wenn Integrität und Aufbewahrung eingerichtet sind
- Eine engere Kommunikationsgrenze, die gemessen werden kann
- Explizite Provisionierungs- und Restrisikoentscheidungen
Sie gibt euch nicht
- Garantie für Datenschutz, Sicherheit, Korrektheit oder Compliance
- Beweis vollständiger Checks oder vertrauenswürdiger Dependencies
- Sicheres Secrets-Handling, Transfer, Zugriff oder menschliche Freigabe von selbst
- Ein universelles Ergebnis für vernetzte oder anders eingerichtete Systeme
Wenn diese Grenzen zu eurem Team passen:
FAQ
- Funktioniert KI-Code-Prüfung ohne Internetzugang?
- Ausgewählte Prüfung kann ohne öffentliches Netz laufen, wenn Quellcode, Toolchains, Dependencies, Testdienste, Policies und ein optionales lokales Modell bereits in der Umgebung vorhanden sind. Das ist Offline-Betrieb. Trennung vom Netz ist eine Grenzkontrolle; lokale Verarbeitung benennt den Rechenort. Keines davon belegt ausreichende Checks oder ein korrektes, privates, sicheres oder konformes Ergebnis.
- Was läuft offline von Haus aus - und was braucht Arbeit?
- Git und viele Compiler, Type-Checker, Test-Runner, Linter und Scanner können lokal laufen; ein echter Run kann trotzdem provisionierte Dependencies, Lizenzen, Fixtures, Dienste, Schwachstellendaten oder Doku brauchen. Lokale Modelle und Mirrors brauchen ebenfalls kontrollierte Beschaffung, Integritätsprüfung, Freigabe, Transfer, Setup und Updates. Ob ein Workflow offline ist, muss an seinen tatsächlichen Netzaufrufen und Eingaben geprüft werden.
- Wie verhalten sich KI-Coding-Tools in einer Air-Gapped-Umgebung?
- Tools, die einen externen Dienst brauchen, können diesen über einen durchgesetzten Gap nicht nutzen. Lokal provisionierte Agenten, IDE-Erweiterungen und Modell-Endpunkte können je nach Lizenzen, Dependencies, Hardware, Setup und Policy laufen. Fähigkeit und Prüfabdeckung sind deploymentspezifisch; ein schriftlicher Auftrag und kleinere Änderungen können Reviews helfen, kompensieren fehlende Tools aber nicht automatisch und beweisen keine Korrektheit.
- Wie kommen Modelle und Updates rein, ohne den Gap zu brechen?
- Über den freigegebenen Transferpfad der Organisation, mit Provenienz, Integritätsprüfung, gegebenenfalls Malware-Prüfung, Autorisierung, Inventar und Rollback. Eine Checksumme bestätigt Bit-Identität mit einer Referenz, nicht deren Vertrauenswürdigkeit oder Sicherheit. Mirrors, Allowlists und Pinning können Auflösung begrenzen; Setup und Inhalt bleiben Supply-Chain-Risiken, kompromittierte legitime Pakete bleiben möglich.
- Sind Prüf-Belege offline schwerer zu erzeugen?
- Belege können ohne externen Dienst in lokale Dateien geschrieben werden. Das macht sie weder vollständig noch unveränderlich, zurechenbar, aufbewahrt, geprüft oder freigegeben. Integritätsschutz, Zugriff, Zeitstempel, Aufbewahrung, Export und die benannte menschliche Entscheidung bleiben getrennte Kontrollen; ein Prüfbericht ist kein Audit-Ergebnis.
- Lohnt sich ein Air Gap allein für KI-Datenschutz?
- Ein Air Gap ist eine risikobasierte Architekturentscheidung, kein allgemeines Datenschutzrezept. Lokale Verarbeitung kann mit Netzpfaden, Telemetrie, Wechselmedien, zu breitem Zugriff oder schwachem Secrets-Handling einhergehen; ein isoliertes System kann verwundbare oder bösartige Artefakte enthalten. Datenschutz, Sicherheit, Korrektheit und Compliance brauchen eigenes Bedrohungsmodell, Kontrollen, Belege und verantwortliche Freigabe.
Weiterlesen
Quellen
- ANSSI/BSI - Security-Empfehlungen für KI-Programmierassistenten (4. Oktober 2024; Empfehlung, keine Zertifizierung, englisch)
- NIST SP 800-53 Rev. 5.1 - SC-7 Boundary Protection und SC-10 Network Disconnect (2026; Kontrollkatalog, keine Zusicherung, englisch)
- NIST SP 800-161 Rev. 1 Update 1 - Cybersecurity-Supply-Chain-Umgang mit Risiken (Mai 2022, aktualisiert November 2024; Risikohilfe, keine Garantie, englisch)