LiteLLM erneut kompromittiert: Wie Sie verhindern, dass SSH-Schlüssel und API-Geheimnisse über Ihr KI-Gateway im Produktivbetrieb abfließen

von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau

Ich bin Denis Shokhirev, Agentic AI Systems Architect aus Freiburg im Breisgau, Germany, und bei DennisCraft AI Studio baue ich produktive KI-Systeme für DACH-B2B-Kunden mit Claude, Supabase, n8n, Doppler und selbst betriebenem Postgres. Der unangenehme Moment im Produktivbetrieb ist selten die Modellantwort oder die Latenz. Kritisch wird es dann, wenn Ihr KI-Gateway plötzlich SSH-Schlüssel, .env-Dateien, Service-Token und interne API-Geheimnisse sehen kann, die dort nie hätten landen dürfen.

Genau deshalb ist eine erneute Kompromittierung von LiteLLM relevant. Ein KI-Gateway bleibt in der Praxis selten nur ein Vermittler zwischen Anwendung und Modellanbieter. Es wird zur Sammelstelle für Zugangsdaten, Protokolle, Werkzeugausgaben, Rückrufadressen und Prozesskontext. Wenn diese Schicht kompromittiert wird, reden Sie nicht mehr nur über KI-Sicherheit, sondern über einen klassischen Infrastrukturvorfall mit erweitertem Schadenradius.

Das eigentliche Problem ist Rechtekonzentration

Die Einführung eines Gateways ist fachlich nachvollziehbar: ein Endpunkt, Ausweichrouten zwischen Anbietern, Kostenkontrolle, zentrale Protokollierung, einheitliche Schnittstellen. Der operative Nutzen ist real. Das Risiko entsteht, wenn dieselbe Instanz schrittweise zu viele Aufgaben und damit zu viele Rechte erhält.

OWASP nennt im LLM Top 10 für 2025 unter anderem Sensitive Information Disclosure und Excessive Agency als zentrale Risiken für produktive KI-Systeme. Quelle: OWASP GenAI Project, 2025, https://genai.owasp.org/. Im Alltag äußert sich das unspektakulär: vollständige Protokollierung von Anfragen, Werkzeuge mit Dateisystemzugriff, vererbte Umgebungsvariablen und Prompt-Kontext, der aus Bequemlichkeit breiter ausfällt als nötig.

Wo Geheimnisse typischerweise abfließen

Planen Sie so, als würde das Gateway irgendwann kompromittiert

Die nützliche Architekturfrage lautet nicht: „Ist dieses Gateway sicher genug?“ Sondern: Was kann ein Angreifer innerhalb von 15 Minuten erreichen, wenn genau dieser Prozess kompromittiert wird? Wenn die Antwort lautet „Produktionsdatenbank, Modellschlüssel und Bereitstellungszugänge“, ist die Architektur bereits zu offen angelegt.

1. Trennen Sie Geheimnisverwaltung und Werkzeugausführung

Wenn Ihre Agenten Shell-Befehle ausführen, Dateien lesen oder Webhooks aufrufen dürfen, sollte diese Laufzeitumgebung nicht neben langlebigen Zugangsdaten betrieben werden. Ich bevorzuge möglichst eng begrenzte Berechtigungen mit kurzer Gültigkeit. Ziel ist nicht Perfektion, sondern Schadensbegrenzung nach einem Vorfall.

#!/usr/bin/env bash
set -euo pipefail

export APP_ENV=production
export ANTHROPIC_API_KEY="$(doppler secrets get ANTHROPIC_API_KEY --plain)"
export DB_URL="$(doppler secrets get READONLY_DB_URL --plain)"

exec env -i \
  PATH="/usr/bin:/bin" \
  APP_ENV="$APP_ENV" \
  ANTHROPIC_API_KEY="$ANTHROPIC_API_KEY" \
  DB_URL="$DB_URL" \
  python3 worker.py

Entscheidend ist hier nicht das Produkt Doppler allein, sondern das Muster: saubere Umgebung mit env -i, nur notwendige Variablen, nur lesender Datenbankzugang, keine ungeprüfte Vererbung lokaler Sitzungsdaten.

2. Verhindern Sie Zugriff auf Home-Verzeichnisse und lokale Zugangsdaten

Viele Teams unterschätzen dieses Risiko. Werkzeuge sollen angeblich „nur Projektdateien lesen“, können aber über relative oder absolute Pfade auch ~/.ssh, ~/.aws, Git-Zugangsdaten oder alte .env-Dateien erreichen. Gerade in regulierten Umgebungen widerspricht das dem Prinzip der minimalen Rechte und häufig auch den Erwartungen aus ISO 27001, BSI Grundschutz oder NIS2-naher Governance.

services:
  agent-runner:
    image: python:3.12-slim
    working_dir: /app
    volumes:
      - ./workspace:/app:ro
    read_only: true
    tmpfs:
      - /tmp
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL

Diese Trennung ist kein vollständiger Ersatz für eine ausgereifte Isolationsstrategie, aber ein sinnvoller erster Schritt. Sie senkt direkt das Risiko, dass ein Agent auf Entwicklergeheimnisse oder Betriebszugänge zugreift.

Was vor der Bereitstellung in die Prüfstrecke gehört

Vorfälle rund um KI-Gateways werden fast immer dadurch verschärft, dass im restlichen System bereits zu viele Freiheiten bestehen. Deshalb beginne ich auch hier mit klassischen Prüfwerkzeugen statt mit neuen Schlagworten. Bestehende Werkzeuge finden erstaunlich viele Probleme früh.

#!/usr/bin/env bash
set -euo pipefail

gitleaks detect --source . --no-git --exit-code 1
bandit -r . -x tests
semgrep --config auto .

echo "Static checks passed"

gitleaks erkennt versehentlich eingecheckte Schlüssel und Token, bandit prüft riskante Python-Muster, und semgrep deckt unter anderem Shell-Aufrufe, Pfadmanipulation und unsichere Eingabeverarbeitung ab. Das ist einfach einzuführen und im Produktivbetrieb gut vertretbar.

Die Dokumentation von Anthropic sowie das OpenAI Cookbook sind wertvoll für die Umsetzung von Werkzeugaufrufen und strukturierten Antworten. Sie sind aber keine Sicherheitsarchitektur. Quellen: Anthropic Docs, 2025, https://docs.anthropic.com/; OpenAI Cookbook, 2025, https://cookbook.openai.com/. Beispielcode dient dem Verständnis, nicht automatisch Ihrer Schutzbedarfsanalyse nach DSGVO, ISO 27001 oder EU AI Act.

Mindestregeln für jedes KI-Gateway

• Keine vollständige Protokollierung von Anfrage- und Antwortinhalten im Standardbetrieb.
• Maskierung von Authorization-Headern, API-Schlüsseln und potenziell sensiblen Werkzeugausgaben.
• Klare physische Trennung von Test- und Produktionszugängen.
• Ausgehende Verbindungen der Werkzeugausführung nur zu freigegebenen Zielen.
• Schlüsselrotation ohne Neuaufbau der gesamten Plattform.

Ein tragfähiges Muster für produktive Multi-Agenten-Systeme

In meinen Systemen für DACH-Kunden bleibt das Gateway bewusst schmal. Es sollte Modellanbieter ansprechen können und wenig mehr. Datenbankzugriffe laufen über einen gesonderten Backend-Dienst mit begrenzten Abfragen, nicht über weitreichende Service-Zugangsdaten im Agentenkontext. Supabase ist praktisch, aber ein service_role-Schlüssel in einer Agenten-Pipeline ist in vielen Fällen architektonisch falsch.

from anthropic import Anthropic
import os

client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])

message = client.messages.create(
    model="claude-sonnet-4-20250514",
    max_tokens=512,
    system="You may call only approved tools. Never request secrets.",
    messages=[{"role": "user", "content": "Summarize ticket status"}]
)

print(message.content)

Wichtig ist, was hier fehlt: kein SSH-Material, kein Datenbank-Superuser, kein allgemeiner Dateisystemzugriff als Standard. Bevorrechtigte Vorgänge liegen hinter einer getrennten Dienstgrenze mit Nachvollziehbarkeit.

FAQ

Sollten Sie LiteLLM vollständig vermeiden?

Nicht zwingend. Das größere Problem ist meist die Überprivilegierung rund um das Gateway, nicht allein der Name der eingesetzten Bibliothek. Wenn der Prozess isoliert ist und nur wenige Geheimnisse sehen kann, sinkt der Schadenradius deutlich.

Sind Umgebungsvariablen für API-Schlüssel noch vertretbar?

Ja, unter Bedingungen. Sie müssen Protokollierung, Speicherabbilder, Kindprozesse und Host-Zugriffe so kontrollieren, dass die Variablen nicht ungewollt sichtbar werden.

Brauchen Sie einen eigenen Container für Werkzeugausführung?

Wenn Agenten auf Dateien, Shell oder Netzwerk zugreifen dürfen: ja. Schon einfache Isolation mit nur lesenden Einbindungen und reduzierten Fähigkeiten beseitigt mehrere häufige Fehlerquellen.

Welche Maßnahme bringt am schnellsten Klarheit?

Prüfen Sie, welche Geheimnisse und Dateipfade der Gateway-Prozess heute tatsächlich erreichen kann, und schalten Sie die vollständige Nutzdatenprotokollierung ab. Das offenbart meist sofort zu breite Berechtigungen.

Was ist nach einem Verdacht auf Kompromittierung zu tun?

Behandeln Sie alle für das Gateway sichtbaren Geheimnisse als offengelegt: Schlüsselrotation, Protokollprüfung, Überprüfung der Werkzeugrechte und Kontrolle des ausgehenden Verkehrs. Wenn dieser Ablauf Tage dauert, ist Ihr Betriebsmodell zu träge.

Welche Stelle in Ihrer LLM-Pipeline fängt im Produktivbetrieb derzeit die meisten Probleme ab: statische Analyse, Laufzeitisolation, Kontrolle ausgehender Verbindungen oder menschliche Prüfung privilegierter Werkzeuge? Diese Antwort ist oft aussagekräftiger als jede allgemeine Sicherheitsbehauptung.

I run a free 30-min stack audit for DACH founders building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.