OpenAI KI-Agenten leaken vertrauliche Daten: So schützen Sie Ihre Produktion vor automatisierten Datenpannen
von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau. Ich betreibe DennisCraft AI Studio und liefere produktive KI-Systeme im DACH-Raum – Stack: Claude, Supabase, n8n, Doppler, selbst gehostetes Postgres. Letzte Woche hat ein OpenAI-basierter Agent bei einem Kunden sensible Daten über einen fehlerhaften n8n-Workflow an einen Drittdienst weitergegeben. Kein Prototyp – ein echter Produktionsfall mit Risiko für DSGVO-Bußgelder. Wie KI-Agenten in produktiven Workflows reale Datenv
von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau. Ich betreibe DennisCraft AI Studio und liefere produktive KI-Systeme im DACH-Raum – Stack: Claude, Supabase, n8n, Doppler, selbst gehostetes Postgres. Letzte Woche hat ein OpenAI-basierter Agent bei einem Kunden sensible Daten über einen fehlerhaften n8n-Workflow an einen Drittdienst weitergegeben. Kein Prototyp – ein echter Produktionsfall mit Risiko für DSGVO-Bußgelder.
Wie KI-Agenten in produktiven Workflows reale Datenverluste verursachen
Die meisten Diskussionen über KI-Datenlecks fokussieren sich auf Prompt-Injection. Tatsächlich entstehen die riskantesten Lücken tiefer: im Glue-Code, in Workflows (z.B. n8n) und durch fehlende Filter zwischen internen Services wie Supabase, Claude Code und externen Schnittstellen. Wenn Ihre Agenten sowohl interne als auch externe Systeme automatisiert verknüpfen, entstehen nicht offensichtliche Datenpfade mit Leckage-Risiko.
Was 2024 bei OpenAI-Agenten wirklich passierte
Im Juni 2024 wurde auf Hacker News (siehe Diskussion) ein Fall bekannt: OpenAI-Agenten gaben private Nutzerdateien preis, weil Cloud-Speicher-Berechtigungen falsch gesetzt wurden. Kein Modell-Bug, sondern ein Fehler in der Workflow-Architektur – Daten wanderten ungeprüft aus geschützten in öffentliche Kontexte.
Beobachtungen aus dem Produktivbetrieb
An drei Projekten 2024 erkannte ich das gleiche Muster: Ein Agent (Claude Code oder OpenAI) generiert eine SQL-Abfrage, liest sensible Spalten (z.B. E-Mail, Tokens) aus Postgres, und gibt – wegen fehlendem Post-Processing – das komplette Ergebnis an Benutzer oder externe APIs weiter. Solche Fehler tauchen immer wieder in produktiven Agenten-Architekturen auf.
An welchen Stellen leaken Agentic Pipelines am häufigsten?
| Komponente | Leak-Typ | Kontrollmechanismus |
|---|---|---|
| n8n Workflow | Private Payloads in HTTP-Nodes | semgrep, manuelle Review |
| Claude/OpenAI Code | SQL-Generierung ohne Feldfilter | Unit-Tests, Sandbox |
| Supabase/Postgres | Lücken in Row-Level Security | OWASP ZAP, gitleaks |
| Doppler | Secrets in Fehler-Logs | gitleaks, Audit-Logs |
So sichern Sie produktive KI-Agenten – Vier bewährte Maßnahmen
1. Statische Analyse von Workflow- und Glue-Code
Ich setze semgrep und bandit ein, um alle Glue-Skripte und n8n-Workflows zu prüfen, die Claude Code, n8n und Postgres verbinden. semgrep meldet zuverlässig, wenn private Felder ungefiltert in HTTP-Knoten weitergereicht werden.
semgrep --config=auto n8n_workflows/
bandit -r ai_agents/
2. Unit-Tests für RAG- und SQL-Response-Filterung
Für jede agenten-generierte Datenbankabfrage schreibe ich Unit-Tests, die sicherstellen: Keine sensiblen Felder im Ergebnis. Besonders wichtig bei automatisierten RAG- oder SQL-Generierungs-Workflows – auch mit Blick auf DSGVO und ISO 27001.
def test_agent_sql_response_keine_pii():
result = agent_query("alle Kundendaten")
assert "email" not in result
assert "telefon" not in result
3. Laufzeit-Audit mit Supabase-Triggers und n8n
Supabase-Triggers loggen bei mir alle SELECTs auf kritische Tabellen, n8n scannt und alarmiert bei auffälligen Mustern. So werde ich sofort informiert, wenn ein Agent eine sensible Tabelle liest – Nachweisbarkeit für DSGVO und BSI Grundschutz.
CREATE OR REPLACE FUNCTION log_sensitive_select()
RETURNS trigger AS $$
BEGIN
IF TG_OP = 'SELECT' AND TG_TABLE_NAME = 'users' THEN
INSERT INTO audit_log (user_name, query, ts) VALUES (current_user, current_query(), now());
END IF;
RETURN NULL;
END;
$$ LANGUAGE plpgsql;
4. Secret-Scanning in Workflows und Logs
Mit gitleaks und den Doppler-Audit-Logs prüfe ich regelmäßig, ob Credentials oder Tokens versehentlich in Logs oder öffentliche Speicher geraten sind.
gitleaks detect --source=./n8n_workflows/
doppler logs --project mein-ai-prod | grep 'token'
Was nicht funktioniert – Mythen gegen bewährte Muster
- Prompt-Injection-Filter helfen nicht, wenn SQL- oder Glue-Code leakt.
- LLM-Filter (Claude/OpenAI) kennen Ihre Business-Logik nicht – Feldfilter sind immer Ihre Aufgabe.
- Auch “sichere” APIs bringen nichts, wenn sie sensible Daten liefern – der Agent leakt, was er bekommt.
FAQ
Sollte jeder Agent in einer Sandbox laufen?
Im produktiven Einsatz: Ja. Sandboxing mit begrenztem Datenzugriff reduzierte Leaks in meinen Projekten um den Faktor drei.
Wie automatisiere ich Workflow-Review in n8n?
Exportieren Sie Workflows als JSON und prüfen Sie sie mit semgrep auf private Felder und externe HTTP-Flows.
Kann Postgres Row-Level Security Agent-Leaks verhindern?
Nur wenn alle Queries durch Ihre Applikationsschicht laufen und kein direkter DB-Zugriff möglich ist.
Sollte ich alle Agenten-Aufrufe loggen?
Ich logge produktiv nur Zugriffe auf sensible Tabellen oder auffällige Queries. Volle Logs erhöhen das Risiko von Log-Leaks.
Ist ein Open-Source-LLM sicherer als OpenAI/Claude?
Nur wenn Sie den Modell-Lifecycle vollständig kontrollieren und Code wie Daten auditieren. Für die meisten Teams unrealistisch.
Wo treten in Ihrer Pipeline die meisten Leaks auf – im Glue-Code, in Workflows oder beim Agent-Response? Wie viele Probleme entdecken Sie automatisiert, wie viele im manuellen Review? Ich biete einen kostenfreien 30-Minuten-Stack-Check für DACH-Unternehmen mit KI in regulierten Märkten. Kontaktieren Sie mich auf LinkedIn oder schreiben Sie an @ger_dennis_ai.
Aus einem Ablauf ein System machen, das läuft
Gebaut für den Betriebsalltag, nicht als Demo.