Sicherheit beim KI-Coding
Zuletzt aktualisiert: 2026-07-17Lesezeit ca. 4 Min.
Die Sicherheitshaltung von Reality Graph ist Architektur statt Adjektive: Local-First-Design, advisory Defaults, explizite Commit- und Freigabegrenzen sowie prüfbare Belege. Das sind Kontrollen in einem geschichteten Risikomanagement - kein Beweis sicherer Software und kein Ersatz für Überwachung, Vorfallreaktion und Wiederherstellung.
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, Plugins und Subprozesse prüfen, Netzwerk-Egress bei repräsentativen Runs beobachten und Blindstellen sowie Ausnahmen dokumentieren. |
| Kann es selbst schreiben oder committen? | Wirksame Berechtigungen und Workflow-Gates prüfen; diese Kontrolle belegt weder Korrektheit noch sichere Bereitstellung. |
| 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? | Den vollständigen Datenpfad und Anbieterbedingungen prüfen; lokaler Produktzustand allein belegt nicht, was jedes umgebende Tool empfängt. |
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. Die konkrete Fassung steht auf einer eigenen Seite: was den Rechner verlässt und was nicht, samt der Fälle, in denen doch etwas rausgeht.
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 geschichtetes Risikomanagement über Design, Konfiguration, Zugriff, Scanning, Tests, Verifikation, Überwachung, Reaktion und Wiederherstellung. Reality Graph macht Architektur- und Workflow-Kontrollen prüfbar; jede hat Abdeckungs-, Konfigurations- und Umgehungsgrenzen. Kein Tool oder Gate garantiert sichere Software.
- Verlässt mein Quellcode meine Umgebung?
- Reality Graphs eigener Workflow-Zustand und seine Belege sind für eure Umgebung ausgelegt. Quellcode kann dennoch über konfigurierte Modell-APIs, Plugins, Subprozesse, Logs, Telemetrie oder Bedienhandlungen abfließen. Prüft Version, Konfiguration und Netzwerkverhalten; local-first verengt eine Grenze, belegt aber nicht den vollständigen Datenpfad.
- 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?
- Reality Graphs Auftragsdefinitionen, Grenzen, Validierungs-Receipts und Prüfberichte sind für lokale Speicherung beim Code ausgelegt. Diese Produktgrenze belegt nichts über Agent, Modellanbieter, Shell-Tools, Plugins, Logs, Backups oder Netzkonfiguration. Prüft die eingesetzte Version und den vollständigen Workflow, statt aus dem Architekturbegriff eine Garantie abzuleiten.
- 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 anhand des vollständigen Datenpfads, der Verträge und Rollen. Reality Graphs Local-First-Auslegung ist ein Architekturinput, kein rechtliches Ergebnis: Modellanbieter, Plugins, Telemetrie, Support und andere Dienste können eigene Rollen erzeugen. Rechtsstand Juli 2026; keine Rechtsberatung.
- Wie melde ich ein Sicherheitsproblem?
- Nutzt das Kontaktformular und markiert die Meldung als sicherheitsrelevant. Eine Meldung startet die Triage; diese Seite verspricht weder eine Reaktionsfrist noch ein bestimmtes Behebungsergebnis. Sendet keine aktiven Zugangsdaten oder unnötigen sensiblen Inhalte.
Weiterlesen
Quellen
- NIST SP 800-218 - Secure Software Development Framework (final, 2022, englisch); Praktiken senken Risiko, garantieren aber keine sichere Software
- CISA - Secure-by-Design-Leitlinien (abgerufen Juli 2026, englisch); Designleitlinie, keine Zertifizierung oder Sicherheitsbewertung
- Reality Graph - Datenschutz-Haltung dieser Website (keine Cookies, keine IDs)