Ihr KI-Agent kann über Plugins kompromittiert werden: So sichern Sie Claude Code und Codex Skills im Produktivbetrieb

von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau. In meinem DennisCraft AI Studio setze ich für DACH-B2B-Kunden auf Claude, Supabase, n8n, Doppler und selbst gehostete Postgres-Datenbanken. Kürzlich entdeckte ich bei einem ausgelieferten Agentensystem eine SQL-Injection-Schwachstelle in einem automatisch generierten Plugin — unbemerkt im Demo, kritisch im Produktivbetrieb.

Wo liegen die Schwachstellen: Plugins und LLM-generierte Skills

Produktive KI-Agenten erweitern Sie meist mit Plugins oder „Skills“ — oft kleine Module in Python oder JavaScript, vielfach von LLMs wie Claude Code oder Codex generiert. In meinem Audit von 11 Projekten in 2024 waren ca. 80 % der Plugin-Codes automatisch generiert. Ohne gezielte Prüfung schleichen sich so SQL-Injection (CWE-89), SSRF oder RCE direkt in Ihr produktives System ein.

Typische Schwachstellen in Claude Code und Codex

SQL-Injection: LLM generiert Code, der Benutzereingaben ungefiltert in SQL-Strings einfügt.
Unsichere Deserialisierung: Plugins laden Daten ohne Validierung.
SSRF: Agent kann interne URLs abfragen, weil LLM-Logik zu permissiv ist.
Shell Command Injection: Automatisch generierter Code nutzt unsichere eval- oder subprocess-Aufrufe.

Ein Beispiel aus der Praxis — von Claude generierter Python-Code, der ungeprüft in Produktion gelangte:


def get_user_data(user_id):
    query = f"SELECT * FROM users WHERE id = {user_id}"
    cursor.execute(query)
    return cursor.fetchall()

Dieser Code wurde im Review als „auto-generated“ akzeptiert und öffnete eine SQL-Injection-Lücke.

Schutzmaßnahmen: Pipeline für sichere Auslieferung

Ich setze in meinen Agenten-Systemen auf ein dreistufiges Prüfverfahren:

Statische Analyse (semgrep, bandit, gitleaks)
Sandbox-Tests mit realen Payloads
Manuelles Review — gezielt für kritische Plugins

Statische Analyse: semgrep und bandit

semgrep erkennt Muster wie f"SELECT ..." und unsichere Funktionsaufrufe. bandit ist speziell für Python-Sicherheit optimiert. Beispiel für eine semgrep-Regel gegen SQL-Injection:


rules:
  - id: possible-sql-injection
    pattern: cursor.execute(f"...")
    message: "Mögliche SQL-Injection durch f-string"
    severity: ERROR

bandit lässt sich einfach in Ihre CI/CD-Pipeline einbinden:


bandit -r ./plugins/

gitleaks überprüft, ob Tokens oder Passwörter versehentlich im Plugin-Code landen.

Sandbox-Tests: Angriffsvektoren real simulieren

Jedes neue Plugin teste ich in einer isolierten Umgebung mit typischen Angreifer-Payloads — etwa ' OR '1'='1 für SQL-Injection, file:///etc/passwd für SSRF. Dummy-Endpunkte und Testdatenbanken sind Pflicht.


# Beispiel für einen Unit-Test gegen SQL-Injection
def test_sql_injection():
    result = get_user_data("' OR '1'='1")
    assert "admin" not in result

Produktivbetrieb: Reaktion und schnelle Patches

Falls doch eine Schwachstelle in Produktion gerät, ist ein Notfall-Branch für kritische Plugins entscheidend — unabhängig vom regulären Release-Zyklus, mit eigenem Audit-Log.

Loggen Sie sämtliche Input-Payloads mit Plugin-Version — so rekonstruieren Sie im Angriffsszenario, welcher Code betroffen war.

Phase	Tool	Ziel
Statische Analyse	semgrep, bandit	Bekannte Muster erkennen
Secret Scanning	gitleaks	Tokens aus Code entfernen
Sandbox-Tests	pytest, eigene Skripte	Mit realen Payloads prüfen

Sandboxing von LLM: Grenzen und Empfehlungen

Claude Code und Codex laufen im Produktivbetrieb häufig mit eingeschränkten Rechten (Sandbox-Modus). Viele Frameworks erlauben aber standardmäßig das Generieren beliebigen Python-Codes, inklusive Shell-Kommandos. Verlassen Sie sich nicht auf ein „Default-Sandboxing“. Die Anthropic-Dokumentation empfiehlt ausdrücklich, Funktionsaufrufe zu whitelisten und Outputs vor Ausführung zu validieren.


# Beispiel: Funktionswhitelist in Claude Code
allowed_functions = {"get_user_data", "send_email"}
if requested_function not in allowed_functions:
    raise Exception("Nicht erlaubte Funktion")

In n8n gilt: Jeder Custom Node, insbesondere wenn LLM-generiert, ist ein potenzielles Risiko.

Compliance-Anker: DSGVO und BSI Grundschutz

Für DACH-Kunden ist Compliance Pflicht: DSGVO (GDPR), BSI Grundschutz und die Anforderungen der NIS2-Richtlinie setzen Standards für sichere Softwarebereitstellung. Automatisch generierte Plugins müssen denselben Prüfprozess durchlaufen wie manuell geschriebener Code.

FAQ

Welches Tool erkennt SQL-Injection in LLM-generiertem Code am zuverlässigsten?

semgrep ist flexibel und lässt sich mit eigenen Regeln perfekt in jede Pipeline integrieren.

Kann ich bandit oder semgrep komplett vertrauen?

Nein. Sie erkennen nur bekannte Muster. In der Praxis gab es Lücken, die beide Tools nicht fanden — z.B. bei eval-Aufrufen oder komplexen Funktionsketten.

Sollte jede Plugin-Änderung manuell geprüft werden?

Nein, nicht bei hoher Frequenz (>10/Woche). Manuelles Review nur für Plugins mit Zugriff auf kritische Daten oder externe APIs.

Wie schütze ich selbst gehostetes Postgres vor LLM-Agenten?

Alle Anfragen in parametrisierten Prozeduren kapseln. Dem Agenten keinen direkten SQL-Zugriff geben. In Supabase Row Level Security (RLS) nutzen.

Was tun, wenn eine Schwachstelle in Produktion gelangt?

Sofortiger Patch-Branch und ein Audit-Log der Payloads, um das Angriffsausmaß schnell einzugrenzen.

In welcher Phase Ihrer Pipeline entdecken Sie die meisten Schwachstellen — statische Analyse, Sandbox-Tests oder manuelles Review? Geben Sie mir gern ein Signal.

Ich biete DACH-Firmen einen kostenfreien 30-min Stack-Check für KI-Systeme im regulierten Umfeld an. Kontaktieren Sie mich via LinkedIn oder schreiben Sie an @ger_dennis_ai.