Sicherheit: Was nicht in den Prompt gehört

Dies ist das Kapitel, das die meisten Entwickler überspringen — und genau deshalb das wichtigste der Serie. KI-Tools machen produktiver, keine Frage. Aber sie verändern auch, welche Daten dein Rechner verlassen. Und in dem Moment, in dem ein API-Key oder ein Kundenname in einem Prompt landet, hast du ein Problem, das kein Modell der Welt lösen kann.

Was niemals in einen Prompt gehört

Die Liste ist kurz und nicht verhandelbar: API-Keys, Passwörter, Datenbankzugangsdaten, Kundendaten, interne IP-Adressen, Geschäftsgeheimnisse. Klingt offensichtlich? Passiert trotzdem ständig. Du debuggst einen Verbindungsfehler und pastest die Fehlermeldung mitsamt Connection-String in den Prompt. Du fragst, warum ein API-Call fehlschlägt, und kopierst den kompletten Request inklusive Authorization-Header. Du zeigst einen Log-Eintrag, der eine Kunden-E-Mail enthält. Alles schon gesehen, alles vermeidbar.

Jeder Prompt, den du an einen Cloud-Dienst schickst, verlässt deinen Rechner. Die Daten werden über das Internet übertragen, auf Servern verarbeitet, möglicherweise zwischengespeichert. Auch wenn der Anbieter zusichert, die Daten nicht fürs Training zu verwenden — du hast keine technische Garantie. Ein Datenleck bei einem KI-Anbieter, ein kompromittierter Server, ein fehlkonfigurierter Log — und deine Datenbank-Credentials stehen im Darknet. Das ist kein hypothetisches Szenario, das ist ein realistisches Risiko.

Besonders tückisch sind indirekte Leaks. Du pastest eine Fehlermeldung, die einen Dateipfad enthält — und der Dateipfad verrät deine interne Serverstruktur. Du zeigst eine Konfigurationsdatei mit Platzhaltern, aber die Kommentare daneben enthalten den echten Hostnamen. Du kopierst einen Code-Ausschnitt, und drei Zeilen weiter steht ein define('DB_PASSWORD', '...') in einer WordPress-Config. Diese Leaks passieren nicht aus Böswilligkeit, sondern aus Unachtsamkeit — und genau das macht sie so häufig. Gründlichkeit schützt, Nachlässigkeit nicht.

.env und Secrets — Platzhalter statt Klartext

Die Lösung ist einfach: Arbeite mit Platzhaltern. Statt den echten Connection-String zu pasten, beschreibst du die Struktur. Statt mysql://admin:geheim123@10.0.0.5:3306/shop_live schreibst du: „Die Datenbank-URL steht in .env unter DATABASE_URL, Format ist mysql://user:pass@host:port/dbname.“ Die KI versteht das Format und kann dir trotzdem helfen — sie braucht die echten Werte nicht.

# So NICHT — echte Credentials im Prompt:
DATABASE_URL=mysql://shopware:s3cret@192.168.1.50:3306/sw6_prod
APP_SECRET=a1b2c3d4e5f6g7h8i9j0
MAILER_DSN=smtp://user:pass@mail.example.com:587

# So JA — Platzhalter, gleiche Information:
DATABASE_URL=mysql://USER:PASS@HOST:3306/DBNAME
APP_SECRET=<32-stelliger Hex-String aus .env>
MAILER_DSN=smtp://USER:PASS@MAILHOST:587

Die KI braucht keine echten Werte, um dir bei einem Konfigurationsproblem zu helfen. Sie braucht die Struktur, den Kontext und die Fehlermeldung — nicht die Credentials selbst. Wenn ein Prompt ohne echte Daten nicht funktioniert, formulierst du ihn falsch. Dann ist die Lösung ein besserer Prompt, nicht weniger Sicherheit. In über einem Jahr täglicher KI-Nutzung hatte ich keinen einzigen Fall, in dem ich echte Credentials hätte teilen müssen, um eine Lösung zu bekommen.

Kundendaten — DSGVO ist das Minimum

Nie — unter keinen Umständen — echte Kundendaten in einen Prompt pasten. Keine Namen, keine E-Mail-Adressen, keine Bestellnummern, keine Adressen, keine Telefonnummern. Die DSGVO verbietet die Übermittlung personenbezogener Daten an Dritte ohne Rechtsgrundlage. Ein KI-Anbieter in den USA ist ein Dritter. Punkt. Und selbst bei EU-basierten Anbietern brauchst du eine Rechtsgrundlage, die „ich wollte schnell debuggen“ nicht abdeckt.

Aber selbst ohne DSGVO wäre es falsch. Wenn du einem KI-Modell Kundendaten gibst, um einen Bug zu debuggen, und diese Daten jemals in einem Trainingsdatensatz oder einem Datenleck auftauchen, hast du das Vertrauen deiner Kunden verspielt. Kein Feature, kein Produktivitätsgewinn ist das wert. Das Vertrauen deiner Kunden ist das wertvollste Asset deines Unternehmens — es zu riskieren für zehn Minuten Zeitersparnis ist unverantwortlich.

Die Alternative: Anonymisiere konsequent. Erstelle Test-Fixtures mit Fake-Daten. Statt „Max Mustermann, max@example.com, Musterstraße 1″ nimmst du „User-A, user-a@test.local, Adresse-1″. Die KI versteht das Problem genauso gut, und du hast kein Datenschutzproblem. Für wiederkehrende Debugging-Szenarien lohnt sich ein kleines Skript, das echte Daten automatisch durch Platzhalter ersetzt — einmal geschrieben, bei jeder Debugging-Session verwendbar.

Interne Architektur — wie viel darf raus?

Diese Frage ist weniger eindeutig als bei Credentials. Allgemeine Architekturmuster — „Wir nutzen Hexagonale Architektur mit Ports und Adaptern“ — sind unproblematisch. Das ist kein Geheimnis, das ist ein bekanntes Pattern. Proprietäre Geschäftslogik ist etwas anderes. Der Algorithmus, der euren Pricing-Vorteil ausmacht. Die Custom-Integration, die euer Alleinstellungsmerkmal ist. Die interne API-Struktur, die ein Angreifer nutzen könnte, um gezielt Schwachstellen zu suchen.

Für sensible Projekte gibt es eine klare Empfehlung: lokale Modelle verwenden. Tools wie Ollama oder LM Studio lassen dich KI-Modelle auf deinem eigenen Rechner betreiben. Die Qualität liegt unter Claude oder GPT-4, aber die Daten verlassen nie dein Netzwerk. Für den schnellen Security-Review eines Auth-Moduls ist ein lokales Modell die bessere Wahl als ein Cloud-Dienst. Die Antwort ist vielleicht weniger elegant, aber dafür bleiben deine Daten bei dir.

In der Praxis handhabe ich es so: Öffentliche Projekte und Open-Source-Code gehen bedenkenlos an Cloud-KI. Kundenprojekte mit sensiblen Daten werden abstrahiert — ich beschreibe die Struktur, ohne die konkreten Business-Regeln offenzulegen. Und wenn es wirklich kritisch wird — Kryptografie, Auth-Flows, Payment-Integration — arbeite ich entweder lokal oder ganz ohne KI.

Team-Richtlinien für KI-Sicherheit

In Teams reicht es nicht, wenn nur du sicherheitsbewusst arbeitest. Jeder im Team muss die Regeln kennen und einhalten. Das bedeutet: eine dokumentierte Policy, die definiert, welche Daten an KI-Dienste gehen dürfen und welche nicht. Kein langer Compliance-Roman, sondern eine klare, kurze Liste. API-Keys: nein. Kundendaten: nein. Open-Source-Code: ja. Allgemeine Architekturmuster: ja. Interne Algorithmen: prüfen.

Diese Policy gehört in die CLAUDE.md oder in eine eigene Datei im .ai/rules/-Verzeichnis. So ist sie dort, wo die KI-Nutzung stattfindet — nicht in einem Confluence-Dokument, das niemand liest. Sicherheitsregeln müssen sichtbar sein, am Ort der Nutzung, nicht drei Klicks entfernt in einer Dokumentationsplattform. Wenn die Regel nicht direkt neben dem Prompt sichtbar ist, existiert sie de facto nicht.

Die .gitignore als Sicherheitsnetz

Eine saubere .gitignore schützt nicht nur dein Repository, sondern auch deine KI-Workflows. Viele KI-Tools lesen automatisch Dateien aus deinem Projekt — wenn die .env nicht in der .gitignore steht, kann sie im Kontext landen, ohne dass du es merkst. Jede Datei mit Secrets muss in der .gitignore stehen, und dein KI-Tool muss so konfiguriert sein, dass es diese Ausschlüsse respektiert.

Dazu gehören offensichtliche Kandidaten wie .env, .env.local, credentials.json, serviceAccountKey.json. Aber auch weniger offensichtliche: SSH-Keys, lokale Datenbank-Dumps, Export-Dateien mit Kundendaten, IDE-Konfigurationen mit gespeicherten Passwörtern. Eine gründliche .gitignore ist der erste Schritt zu einem sicheren KI-Workflow — und der einfachste. Nimm dir zehn Minuten, geh deine .gitignore durch und frag dich bei jedem Eintrag: Könnte diese Datei Secrets enthalten? Wenn ja, gehört sie rein.

Sicherheit ist kein Feature, das du nachträglich einbaust. Es ist eine Gewohnheit, die du von Anfang an pflegst. Und die wichtigste Gewohnheit ist die einfachste: Bevor du Enter drückst, lies deinen Prompt noch einmal und frag dich, ob dort etwas steht, das nicht nach draußen darf. Zwei Sekunden Nachdenken ersparen dir im schlimmsten Fall eine Datenschutzmeldung.

Fehlerprotokolle und Stack-Traces

Ein oft übersehener Vektor: Stack-Traces und Fehlerlogs. Du pastest eine Exception, um Hilfe beim Debugging zu bekommen — und im Stack-Trace stehen absolute Dateipfade, die deine Serverstruktur offenlegen. Oder der Log enthält eine Request-URL mit einem Session-Token als Query-Parameter. Oder die Fehlermeldung gibt einen Datenbanknamen preis, der Rückschlüsse auf den Kunden erlaubt.

Die Lösung: Bereinige Stack-Traces, bevor du sie an die KI gibst. Ersetze absolute Pfade durch relative. Entferne Query-Parameter mit Tokens. Schwärze Datenbanknamen. Das kostet 30 Sekunden und verhindert, dass sensible Infrastruktur-Details dein Netzwerk verlassen. Auch hier gilt: Die KI braucht die Exception-Klasse und die Fehlermeldung — nicht den vollständigen Pfad zu deinem Deployment-Verzeichnis. Und sie braucht definitiv nicht den Authorization-Header, der zufällig im Request-Log steht.

Die goldene Regel lässt sich auf einen Satz reduzieren: Wenn du den Prompt ausdrucken und ans Schwarze Brett im Büro hängen würdest, ohne ein schlechtes Gefühl zu haben, dann ist er sicher genug. Wenn nicht, bereinige ihn — bevor du ihn abschickst.

Alle Teile dieser Serie

Teil 1: Projekt vorbereiten — Dateien, Struktur, Kontext
Teil 2: Gute Regeln schreiben — der KI Grenzen setzen
Teil 3: Saubere Prompts — präzise formulieren, Token sparen
Teil 4: Modelle und Tools — Stärken, Schwächen, Einsatzgebiete
Teil 5: Sicherheit — was nicht in den Prompt gehört
Teil 6: Reviews — warum der Mensch das letzte Wort haben muss
Teil 7: Wann KI nicht nutzen — die Grenzen kennen
Glossar: Begriffe für Entwickler