Sicherheit beim KI-Coding
Zuletzt aktualisiert: 2026-07-02Lesezeit ca. 4 Min.
Die Sicherheitshaltung von Reality Graph ist Architektur statt Adjektive: local-first by design, advisory by default, kein Auto-Commit, menschliche Freigabe-Gates – und eine sichtbare Antwort auf „was verlässt meinen Rechner?“. Behauptet wird nichts, was die Architektur nicht decken kann.
Inhalt
Die Prinzipien, prüfbar formuliert
- Local-first. Workflow, Repository-Zugriff, Kontext, Validierung und Belege leben in eurer Umgebung. KI-generierten Code zu prüfen darf nicht voraussetzen, das Repository an einen weiteren Cloud-Dienst zu schicken – was „lokal“ wirklich abdeckt.
- Advisory by default. Reality Graph liest, prüft und berichtet. Es schreibt, committet und übernimmt nichts von allein – das tut ein Mensch, an einem Gate, mit Belegen vor Augen.
- Sichtbarer Datenfluss. Was euren Rechner verlässt, bestimmt eure Konfiguration – etwa welche Modell-API euer Setup unter euren eigenen Verträgen nutzt – kein versteckter Default. „Es verlässt nie etwas den Rechner“ wäre ein Marketingsatz; „ihr könnt sehen, was ihn verlässt“ ist eine Architektur-Eigenschaft.
- Keine Überraschungen. Keine Hintergrund-Jobs auf eurem Repository, keine Telemetrie aus eurer Codebasis nach Hause, kein stiller Netzwerkzugriff als Nebeneffekt der Prüfung.
- Belege statt Vertrauen. Jeder Run erzeugt einen prüfbaren Bericht – inklusive des Übersprungenen. Derselbe Maßstab, den diese Seite an sich selbst anlegt.
Weil das Architektur-Eigenschaften sind, müsst ihr sie nicht glauben – jede lässt sich konkret nachprüfen:
| Frage | So prüft ihr es selbst |
|---|---|
| Verlässt Quellcode meine Umgebung? | Konfiguration einsehen und den Netzwerk-Egress während eines Runs beobachten – die einzigen ausgehenden Aufrufe sind die Modell-API, die euer Setup ohnehin nutzt. |
| Kann es selbst schreiben oder committen? | Berechtigungen und Workflow-Gates prüfen: Es gibt keinen Auto-Commit-Pfad zu finden. |
| Was ist in einem Run genau passiert? | Den beim Code gespeicherten Prüfbericht lesen – Auftrag, Änderungen, Validierungsergebnisse und das Übersprungene. |
| Was erfährt der Anbieter über meinen Code? | Architekturbedingt nichts: kein Konto-Zwang, keine serverseitige Kopie der Runs, keine Telemetrie aus eurem Repository. |
Was wir bewusst nicht behaupten
Eine Sicherheitsseite ist nur so vertrauenswürdig wie die Claims, die sie verweigert. Reality Graph ist in privater Beta – deshalb steht hier ausdrücklich:
- Noch keine Zertifizierungen – kein SOC 2, kein ISO 27001. Wenn formale Audits kommen, werden sie hier verlinkt; bis dahin wird das Fehlen benannt, nicht übertüncht.
- Keine Compliance-Garantien– „DSGVO-konform“ ist eine Eigenschaft eures Einsatzes und eurer Prozesse, bewertet durch eure Rechtsberatung. Architektur kann diese Bewertung erleichtern; abnehmen kann sie euch kein Anbieter.
- Kein „garantiert sicheres KI-Coding“ – Verifikation senkt Risiko und macht es sichtbar. Sie schafft es nicht ab, und wer Ernst zu nehmen ist, erzählt euch nichts anderes.
Die Website lebt vor, was das Produkt predigt
Diese Seite läuft cookie-frei: keine Besucher-IDs, kein Fingerprinting, keine gespeicherten IPs, keine Drittanbieter-Tracker – nur aggregierte, anonyme Signale, dokumentiert im Datenschutz. Ein Produkt, dessen Kern Datenkontrolle ist, sollte euch nicht mit einem Consent-Banner begrüßen.
Wo Reality Graph ansetzt
Sicherheitsbewusste Teams sind Kernzielgruppe einer lokalen Verifikationsschicht – und die Zielgruppe, der Adjektive am wenigsten helfen. Sprecht mit dem Gründer über eure Randbedingungen oder fragt Early Access an.
Architektur-Eigenschaften
- Läuft in eurer Umgebung – local-first by design
- Advisory by default: liest, prüft, berichtet – schreibt nie von allein
- Menschliche Freigabe-Gates für jede Änderung
- Datenfluss sichtbar in der Konfiguration, nicht versteckt in Defaults
Bewusst nicht behauptet
- „Garantiert sicher“ – Verifikation senkt Risiko, sie schafft es nicht ab
- DSGVO-/SOC-2-/ISO-Zertifizierungen – es gibt noch keine; das steht hier
- „Es verlassen nie Daten den Rechner“ – was rausgeht, ist eure sichtbare Konfiguration
- Enterprise-Readiness – es ist eine private Beta, und sagt das auch
Wenn diese Grenzen zu eurem Team passen:
FAQ
- Ist Reality Graph sicher?
- Kein Tool sollte diese Frage mit „ja“ beantworten – Sicherheit ist eine Eigenschaft eures Gesamt-Setups, kein Produktfeature. Was Reality Graph bietet, sind prüfbare Architektur-Eigenschaften: Es läuft in eurer Umgebung, ist advisory by default, committet nichts automatisch, und was euren Rechner verlässt, bestimmt sichtbar eure Konfiguration. Beurteilt es an diesen Eigenschaften, nicht an Adjektiven.
- Verlässt mein Quellcode meine Umgebung?
- Reality Graph ist local-first: Workflow, Repository-Zugriff, Kontext und Prüfberichte leben in eurer Umgebung. Wo eine Modell-API Teil eures Setups ist, laufen Aufrufe unter euren eigenen Verträgen und Kontrollen – dieser Datenfluss ist eure Konfiguration, kein versteckter Default. Kein Dritt-Review-Dienst verarbeitet euer Repository.
- Ist Reality Graph DSGVO-konform / SOC-2- / ISO-27001-zertifiziert?
- Reality Graph ist in privater Beta und hält keine Zertifizierungen – und wir behaupten nichts anderes. Die Local-First-Architektur reduziert externe Verarbeitung, was compliance-bewusste Teams schätzen. Aber Compliance ist eine Bewertung eures konkreten Einsatzes, die bei euch und eurer Rechtsberatung bleibt.
- Kann Reality Graph selbst Code ändern oder committen?
- Nein. Es ist advisory by default: Es strukturiert Aufträge, prüft Grenzen, führt Validierung aus und erzeugt Belege – ein Mensch übernimmt oder verwirft Änderungen. Es gibt keinen Auto-Commit und keinen versteckten Schreibpfad.
- Welche Daten verarbeitet Reality Graph – und wo?
- Die Arbeitsdaten eines Verifikations-Runs – Auftragsdefinitionen, Grenzen, Validierungsergebnisse, Prüfberichte – entstehen und liegen lokal in deiner Umgebung, direkt beim Code, den sie beschreiben. Reality Graph verlangt kein Konto, funkt keine Ergebnisse nach Hause und hält keine serverseitige Kopie deiner Runs, die verloren gehen könnte.
- Was bedeutet local-first gegenüber einem Cloud-Review-Tool für die Sicherheit?
- Ein Cloud-Review-Dienst muss deinen Quellcode empfangen, um ihn zu prüfen – damit wird seine Infrastruktur Teil deiner Angriffsfläche und seine Datenpraxis Teil deiner Compliance-Dokumentation. Eine Local-First-Schicht hält diese Fläche innerhalb der Grenze, die du ohnehin kontrollierst. Keiner der Ansätze ist automatisch „sicherer“ – aber local-first heißt: eine Partei weniger, der man vertrauen muss, und ein Auftragsverarbeiter weniger, den man dokumentieren muss.
- Brauchen wir für Reality Graph einen Auftragsverarbeitungsvertrag (AVV)?
- Das entscheidet euer Datenschutzprozess – aber die Architektur macht die Prüfung einfach: Reality Graph läuft in eurer Umgebung, und die Local-First-Auslegung ist gerade darauf ausgelegt, dass Quellcode und Run-Daten sie nicht verlassen. Es gibt also keinen externen Dienst, der Code empfängt und als Auftragsverarbeiter dokumentiert werden müsste. Die Bewertung im Einzelfall bleibt bei eurem Datenschutzbeauftragten.
- Wie melde ich ein Sicherheitsproblem?
- Über das Kontaktformular, als sicherheitsrelevant markiert. Meldungen gehen direkt an den Gründer und werden ernst genommen – ein kleines Produkt in privater Beta hat kein Security-Theater, hinter dem es sich verstecken könnte, nur schnelle Fixes.
Weiterlesen
GovernanceKI-Coding-GovernanceKontrollen, Workflows, Freigaben und Belege, mit denen ein Team KI-Coding-Tools einführt, ohne Engineering-Verantwortung zu verlieren – samt der Grenzen jedes Bausteins.MethodeSoll-Ist-AbgleichKI-generierten Code gegen einen schriftlichen Auftrag prüfen statt gegen die Erinnerung an den Prompt – die fünf Schritte, das Zirkularitätsproblem und die Grenzen der Methode.Alle ArtikelDie ganze Sammlung – 58 belegte, datierte Guides zur Prüfung von KI-generiertem Code.