Ihre privaten Claude-Chats landeten bei Google: So verhindern Sie das Leaken von API-Schlüsseln und Unternehmensgeheimnissen

von Denis Shokhirev, Enterprise AI Architect aus Erlangen. Bei DennisCraft AI Studio liefere ich produktive KI-Agenten für DACH-B2B-Kunden in Logistik, Fintech und Industrieautomation – auf Basis von Claude, Supabase, n8n, Doppler und selbst gehostetem Postgres. Die erste ernsthafte Datenpanne mit vertraulichen Informationen in Google ist kein hypothetisches Risiko, sondern ein Produktionsmoment, der zur Anpassung der Pipeline zwingt.

Wie Claude-Chats und Schlüssel tatsächlich öffentlich werden

Reale Leaks aus dem Betrieb

In einem Logistik-Projekt mit Supabase als Logging-Backend landeten Prompt-Logs in einem öffentlich zugänglichen S3-Bucket. Wenige Wochen später war ein Claude-Prompt über eine einfache Google-Suche auffindbar. Vergleichbare Leaks wurden 2024 auf Hacker News diskutiert: Private Chats, API-Schlüssel oder Testdaten tauchten in öffentlichen Gists, Debug-Logs oder Pastebin auf. Ursache: Automatisierung ohne klare Abgrenzung zwischen Test und Produktion, fehlende Datenschutzschranken.

Wo Sie wirklich Geheimnisse verlieren

Warum LLM-Agenten besonders anfällig sind

LLMs als neue Angriffsfläche

Agenten auf Basis von LLMs (RAG, Autovervollständigung, Automatisierung via n8n) arbeiten oft mit Produktivdaten und vertraulichen Zugangstoken. Anders als klassische Backends fehlt häufig strikte Typisierung und Validierung. LLMs können versehentlich Code- oder SQL-Fragmente mit echten Schlüsseln generieren. In drei aktuellen Deployments loggten Agenten access_token direkt im System-Prompt – diese landeten in Supabase-Logs und konnten im CI/CD-Stack ausgelesen werden.

Konkrete Schwachstellen in generiertem Code

Laut Stanford CodeML (2024) enthalten 38 % des von LLMs erzeugten Python-Codes klassische CWE-89 (SQL Injection) Muster (codeml.stanford.edu). Werden echte Secrets im Prompt verwendet, gibt Claude diese im Worst Case als Output zurück. Ohne Filterung werden sie geloggt oder geraten in Chat-Historien – und landen so z. B. in Suchmaschinen oder beim Support.

Praktische Schutzmaßnahmen im produktiven Stack

1. Protokoll-Filterung und Maskierung

Payload immer vor Logging filtern. Beispiel in Python:

import re

def mask_secrets(payload):
    return re.sub(r'(api_key|access_token|secret)=([a-zA-Z0-9\-]+)', r'\1=***', payload)

def safe_log(payload):
    print(mask_secrets(payload))

2. Secret-Scanner in der Codebasis

Ich setze gitleaks im CI ein, um versehentliche Schlüssel im Repository zu entdecken. Beispiel:

gitleaks detect --source=. --report-path=leaks.json

Im Mai/Juni 2024 fand gitleaks in einem Agent-Test ein echtes access_token – vier Stunden manuelle Kontrolle gespart.

3. Statische Codeanalyse für LLM-Code

semgrep filtert SQL-Injection- und Secret-Leaks im generierten Code. Minimal-Konfiguration:

rules:
  - id: sql-injection
    pattern: cursor.execute($QUERY)
    message: Possible SQL injection
    severity: ERROR

semgrep erkennt Muster, die klassische Linter oder manuelle Reviews regelmäßig übersehen.

4. Getrennte Umgebungen & Secrets via Doppler

Alle Schlüssel liegen in Doppler, werden für jede Session temporär bereitgestellt. Für Tests existieren eigene Schlüssel, ohne Zugriff auf Produktivdaten.

doppler run --command "python agent.py"

Vergleich von Leak-Detection-Tools

FAQ

Weshalb ein Secret-Manager statt .env?

.env-Dateien geraten oft versehentlich ins Git oder in CI/CD-Pipelines. Doppler/HashiCorp Vault bieten Audit, Schlüsselrotation und fein granulierte Rechteverwaltung.

Kann Claude Secrets aus Prompts wiedergeben?

Ja. Schlüssel im Prompt werden von Claude unter Umständen im Output repliziert. In meiner Entwicklungspraxis kam das regelmäßig in Debug-Outputs vor.

Wie sichern Sie n8n-Workflows ab?

Alle Secrets ausschließlich im Credential-Manager, keine Workflows öffentlich exportieren, keine Schlüssel als Parameter verwenden.

Alternativen zu Regex-Filterung?

Bandit (Python) oder eigene Middleware, die sensible Keys vor Logging entfernt, sind praxiserprobt.

Was tun bei bereits erfolgtem Leak?

Sofort Schlüssel rotieren, Zugriffslogs prüfen, alle öffentlichen Gists und Pastebins auf weitere Leaks scannen.

In welcher Stufe Ihrer LLM-Pipeline erkennen Sie die meisten Leaks – statische Analyse, Laufzeit-Masking oder manuelle Kontrolle? Das interessiert mich wirklich.

Ich biete einen kostenfreien 30-min Stack-Audit für DACH-CTOs und Gründer, die KI im regulierten Markt produktiv betreiben. Kontaktieren Sie mich auf LinkedIn oder unter @ger_dennis_ai.