Wie Sie Ihre KI-Agenten und Daten beim Skalieren absichern: Typische Schwachstellen und Best Practices

von Denis Shokhirev, Enterprise AI Architect aus Freiburg. In den letzten sechs Monaten habe ich 14 produktive KI-Agenten für DACH-B2B-Kunden ausgeliefert (Stack: Claude, Supabase, n8n, Doppler, selbstgehostetes Postgres). Ein konkretes Risiko: Nach einer einzigen unentdeckten Token-Leakage im Git-Repository musste ein Industrie-Kunde DSGVO-Meldung machen und 24 Stunden den Zugang zu sensiblen Produktionsdaten sperren.

Wo KI-Agenten in der Praxis angreifbar sind

Bei Audits und Rollouts sehe ich wiederholt ähnliche Fehlerquellen:

API-Keys und Tokens werden im Klartext in .env-Dateien gespeichert
Es gibt keine Validierung der Nutzereingaben (Prompt Injection bleibt möglich)
Audit-Logging fehlt, Rückverfolgung und Rollbacks sind nicht machbar
LLM-generierter Code wird ohne gründliche Prüfung übernommen
Kundendaten liegen unverschlüsselt in der Datenbank

Konkrete Erfahrung: In drei aktuellen Projekten enthielten von Claude erzeugte Python-Skripte für die Datenbankschicht klassische SQL-Injection-Muster. Erst bandit und manuelle Sichtung haben diese vor Produktivstart identifiziert. Ohne statische Analyse hätte es mindestens einen kritischen Vorfall gegeben.

Typische Schwachstellen bei KI-Agenten

1. SQL-Injection in LLM-generiertem Code

LLMs wie Claude oder GPT-4 erzeugen oft unsichere DB-Zugriffe. Laut Stanford CodeML-Studie 2024 enthalten 38% der von LLM generierten Python-Beispiele CWE-89-SQL-Injection-Muster (Quelle).

# Unsicher (LLM-generiert)
def get_user(email):
    query = f"SELECT * FROM users WHERE email = '{email}'"
    cursor.execute(query)
# Sicher: Parameter statt String-Interpolation
def get_user(email):
    query = "SELECT * FROM users WHERE email = %s"
    cursor.execute(query, (email,))

2. Geheimnis-Leakage (API-Keys, Tokens)

API-Keys in Git oder unverschlüsselt in .env sind leider Standard. Mit gitleaks finde ich in fast jedem zweiten Audit kritische Geheimnisse im Repo.

# Geheimnisse im Git scannen
gitleaks detect --source .

3. Prompt Injection & RAG-spezifische Risiken

Unvalidierte Nutzereingaben können den Agenten zu gefährlichen Aktionen verleiten. In RAG-Setups (Retrieval-Augmented Generation) führen fehlerhafte Vektorzugriffe schnell zu DSGVO-relevanten Leaks.

Best Practices für produktive KI-Absicherung

1. Statische und dynamische Codeanalyse

Für Python/JS setze ich bandit und semgrep ein; bei TypeScript eslint und snyk. Diese Tools laufen bei mir auf jedem Commit.

# Python: bandit
bandit -r .
# JS/TS: semgrep
semgrep --config=auto .

Tool	Sprache	Einsatz
bandit	Python	Sicherheitsprüfung
semgrep	Python, JS/TS	Flexible Code-Analyse
gitleaks	Alle	Geheimnisse finden

2. Zentrale Verwaltung von Geheimnissen

Keine Geheimnisse im Code oder in .env! Für DACH-Kunden setze ich Doppler oder HashiCorp Vault ein. In n8n werden Secrets als Environment-Variable eingebunden.

# Geheimnisse via Doppler CLI holen
doppler secrets download --no-file --format env

3. Zugriffskontrolle und Audit-Logging

Mit Supabase setze ich grundsätzlich Row Level Security (RLS) um. Jede Agentenaktion schreibe ich in ein dediziertes audit_log-Tabellenobjekt in Postgres, bei kritischen Aktionen zusätzlich syslog-Integration. DSGVO- und BSI-Anforderungen sind so abbildbar.

-- RLS aktivieren
ALTER TABLE customers ENABLE ROW LEVEL SECURITY;
-- Audit Log-Tabelle
CREATE TABLE audit_log (
    id serial PRIMARY KEY,
    agent_id text,
    action text,
    ts timestamp DEFAULT now()
);

4. Prompt-Filterung und Output-Sandboxing

Ich filtere eingehende Prompts per Regex auf verbotene Kommandos (z.B. DROP, DELETE). Output-Sandbox: Agenten dürfen nur SELECT-Queries absetzen oder erhalten Funktionswhitelists zur Laufzeit.

5. Verschlüsselung von Daten

Für Postgres setze ich Verschlüsselung auf Plattenebene (z.B. LUKS) ein. Bei besonders sensiblen Daten nutze ich pgcrypto direkt in der Datenbanktabelle. DSGVO-Artikel 32 fordert dies explizit für personenbezogene Informationen.

Tabelle: Schwachstellen und Gegenmaßnahmen

Schwachstelle	Erkennung	Gegenmaßnahme
SQL-Injection	bandit, manuelle Prüfung	Parametrisierung
Geheimnis-Leakage	gitleaks	Doppler, Vault
Prompt-Injection	Tests, Analyse	Prompt-Validierung, Sandbox
Fehlende RLS	Log, Testfälle	RLS, Audit-Log

FAQ

Wo treten Sicherheitsprobleme im KI-Agentenbetrieb am häufigsten auf?

In 70% der Fälle bei der Datenbankschicht – speziell bei LLM-generiertem Code ohne bandit/semgrep-Prüfung.

Reicht gitleaks allein?

Nein. gitleaks deckt nur Git-Leaks auf. Geheimnisse tauchen aber auch in Logs oder CI/CD-Pipelines auf. Für DACH-Kunden setze ich immer Doppler-Alerts ein.

Wie filtern Sie Prompts in der Praxis?

Per Regex-Filter für riskante Kommandos und Limitierung von Promptlänge sowie Kontext. Sandboxen für Output standardmäßig aktiv.

Wie sieht Ihre bevorzugte Audit-Log-Architektur aus?

Separate Audit-Log-Tabelle in Postgres, bei Bedarf syslog-Anbindung für kritische Aktionen. DSGVO- und BSI-konform.

Kann LLM-generierter Code für Produktivbetrieb genutzt werden?

Nur nach statischer und manueller Prüfung. LLMs sind Entwicklungshilfe, ersetzen aber keine Sicherheitsprüfung.

In welchem Abschnitt Ihrer KI-Pipeline entstehen die meisten Produktionsvorfälle – statische Analyse, Laufzeit-Sandbox oder menschliches Review? Ich freue mich auf Ihren Erfahrungswert.

Ich biete einen kostenlosen 30-minütigen Stack-Audit für DACH-Unternehmen im regulierten Umfeld an. Kontaktieren Sie mich auf LinkedIn oder schreiben Sie an @ger_dennis_ai.