LLM-Secrets absichern: 12 Schritte, 90 Minuten [2026]

Im März 2026 veröffentlichte GitGuardian seinen jährlichen State-of-Secrets-Sprawl-Report mit einer Zahl, die viele IT-Teams aufhorchen ließ: 1.275.105 KI-Service-Secrets wurden 2025 in öffentlichen GitHub-Commits gefunden, ein Plus von 81 Prozent gegenüber dem Vorjahr. Darunter allein 113.000 offengelegte DeepSeek-API-Keys. Acht der zehn am schnellsten wachsenden Secret-Kategorien betrafen KI-Dienste. Wer heute ein Sprachmodell betreibt, ob als API-Anbindung an OpenAI und Claude oder als selbst gehostetes Llama- oder Mistral-Setup, verwaltet damit automatisch neue, oft unterschätzte Angriffsflächen.

Diese Anleitung zeigt, wie du KI-Modelle, die dazugehörigen API-Keys, Trainingsdaten und Chat-Protokolle in zwölf konkreten Schritten absicherst. Du brauchst dafür keinen Sicherheitsberater, sondern einen Nachmittag Zeit, ein paar Open-Source-Tools und die Bereitschaft, Secrets endlich aus dem Code zu verbannen. Am Ende steht ein funktionierendes Beispielprojekt, das du direkt als Vorlage für dein eigenes Setup nutzen kannst.

Der Hintergrund: Viele deutsche und österreichische Mittelständler sind 2026 von reiner API-Nutzung auf teilweise selbst gehostete Modelle umgestiegen, meist aus Kostengründen oder weil Kundendaten das Firmennetz nicht verlassen sollen. Genau dieser Schritt vergrößert die Angriffsfläche: Ein API-Zugang bei einem großen Anbieter bringt zumindest dessen Sicherheitsteam mit ins Boot, ein selbst betriebenes Llama- oder Mistral-Modell dagegen liegt komplett in der eigenen Verantwortung, von der Festplattenverschlüsselung bis zum letzten offenen Port. Wer beide Welten kombiniert, API-Anbindung für Standardaufgaben und ein lokales Modell für sensible Daten, braucht ein Sicherheitskonzept, das für beide Fälle greift. Genau das liefert diese Anleitung, Schritt für Schritt und mit lauffähigem Code.

Die Reihenfolge der Schritte folgt bewusst der Logik eines Angriffs: erst die Bestandsaufnahme, dann der Schutz der Zugangsdaten, danach die Absicherung des Modells selbst und zuletzt Erkennung und Reaktion. Wer nur einzelne Schritte herauspickt, etwa nur den Secret Manager ohne Rate Limiting, schließt eine Tür und lässt die nächste offen. Die Schritte bauen zwar aufeinander auf, lassen sich aber unabhängig voneinander nachrüsten, falls dein Stack bereits produktiv läuft und ein kompletter Neuaufbau nicht infrage kommt.

Vier Angriffsflächen: Wo KI-Modelle wirklich leaken

Bevor du irgendetwas konfigurierst, hilft ein klarer Blick darauf, was bei einem KI-Modell überhaupt verloren gehen kann. Die Praxis zeigt vier wiederkehrende Muster.

• API-Keys und Zugangsdaten: Der Klassiker. Ein Key landet im Git-Repo, in einem Jupyter-Notebook oder in einer Slack-Nachricht und wird von dort automatisiert abgegriffen.
• Modellgewichte: Bei selbst gehosteten Modellen liegen die Gewichte oft unverschlüsselt auf einer Festplatte oder in einem Object-Storage-Bucket, der versehentlich öffentlich lesbar ist.
• Trainings- und RAG-Daten: Vektor-Datenbanken und Retrieval-Pipelines enthalten häufig sensible Kundendaten, die ohne Zugriffskontrolle über die Chat-Schnittstelle wieder ausgegeben werden können.
• Schatten-KI (Shadow AI): Mitarbeitende nutzen private ChatGPT- oder Gemini-Konten für Firmendaten, außerhalb jeder IT-Kontrolle.

Laut GitGuardian leakt LLM-Infrastruktur wie Orchestrierung, RAG-Anbindung und Vektor-Storage inzwischen fünfmal schneller als die API-Keys der großen Modell-Anbieter selbst. Das verschiebt den Fokus: Es reicht nicht, nur den OpenAI- oder Anthropic-Key zu schützen, das gesamte Ökosystem drumherum braucht dieselbe Sorgfalt.

Jede der vier Angriffsflächen hat einen eigenen typischen Fehlerpfad. Bei API-Keys ist es fast immer ein versehentlicher Commit oder ein Screenshot in einem Ticket-System. Bei Modellgewichten sind es falsch konfigurierte Storage-Buckets, die per Default öffentlich lesbar bleiben, weil niemand die Berechtigungen nach dem ersten Upload noch einmal geprüft hat. Bei Trainings- und RAG-Daten liegt das Problem oft tiefer: Die Vektor-Datenbank wurde als internes Tool ohne Zugriffskontrolle aufgesetzt und wächst dann organisch in eine produktive Kundenschnittstelle hinein. Und Schatten-KI entsteht meistens nicht aus böser Absicht, sondern weil die offizielle, freigegebene Lösung langsamer oder umständlicher ist als die kostenlose App auf dem privaten Smartphone. Wer diese vier Muster kennt, weiß auch, wo die zwölf folgenden Schritte ansetzen müssen.

OWASP Top 10 für LLM-Anwendungen 2026: Der aktuelle Rahmen

Wer sich nicht an einer einzelnen Checkliste, sondern an einem anerkannten Standard orientieren will, findet ihn bei OWASP. Das OWASP-Projekt Top 10 for LLM Applications hat im August 2026 seine aktuelle 2026er Ausgabe veröffentlicht. Sie ordnet Risiken wie Prompt Injection, ungewollte Offenlegung sensibler Informationen und Schwachstellen in der KI-Lieferkette in einen gemeinsamen Rahmen ein, an dem sich Sicherheitsteams bei Audits und Ausschreibungen orientieren.

Für die Praxis heißt das: Die zwölf Schritte in dieser Anleitung decken mehrere dieser Kategorien gleichzeitig ab. Der Secret Manager und das Rotationsverfahren adressieren die Offenlegung sensibler Informationen, der Gateway mit RBAC und Rate Limiting begrenzt die Folgen einer erfolgreichen Prompt Injection, und die Netzwerksegmentierung reduziert das Risiko aus einer kompromittierten Lieferkette, etwa wenn ein verwendetes Open-Source-Paket selbst manipuliert wurde. Wer sein Setup dokumentiert, kann diese Zuordnung direkt für interne Audits oder für einen Nachweis gegenüber Kunden nutzen, ohne jede Anforderung neu zu erfinden.

Für deutsche und österreichische Unternehmen kommt ein zusätzlicher Aspekt dazu: Sicherheitsvorgaben aus Standards wie dem OWASP-Rahmen ersetzen keine Meldepflichten nach DSGVO oder branchenspezifischen Regeln, sie ergänzen sie. Ein sauber dokumentiertes Vorgehen nach OWASP erleichtert es aber, gegenüber Kunden oder Aufsichtsbehörden nachzuweisen, dass angemessene technische Maßnahmen getroffen wurden, sollte es trotz aller Vorsorge doch zu einem Vorfall kommen.

Voraussetzungen: Tools, Accounts und Versionen

Die folgende Anleitung ist toolagnostisch aufgebaut, nutzt aber konkrete Beispiele, damit du direkt loslegen kannst. Diese Versionen wurden für dieses Tutorial verwendet:

Tool	Zweck	Version / Stand
HashiCorp Vault	Secret Manager	aktuelle Community-Version
Docker & Docker Compose	Container-Orchestrierung	Docker 27.x, Compose v2
Gitleaks	Secrets-Scanning im Repo	aktuelle Version
ggshield (GitGuardian CLI)	Secrets-Scanning in CI/CD	aktuelle Version
Ollama	Self-Hosted LLM-Runtime	aktuelle Version
Python	Gateway- und Filterlogik	3.12 oder neuer
Nginx oder Traefik	Reverse Proxy / Gateway	aktuelle Version

Du brauchst außerdem Root- oder Sudo-Rechte auf einer Linux-Maschine (oder WSL2 unter Windows), einen GitHub- oder GitLab-Account für die CI/CD-Beispiele und mindestens 8 GB RAM, wenn du das komplette Beispielprojekt inklusive Ollama lokal laufen lassen willst. Nutze immer die aktuelle stabile Version der genannten Tools, da sich Sicherheitsfunktionen wie Rate-Limiting-Module oder Secret-Engines regelmäßig weiterentwickeln.

Wichtig ist auch die organisatorische Vorbereitung: Kläre vor dem ersten Schritt, wer im Unternehmen Owner des Secret Managers wird, wer Zugriff auf die Vault-Root-Policy bekommt und wer im Ernstfall berechtigt ist, einen Key sofort zu widerrufen. Technische Maßnahmen ohne klare Zuständigkeit verpuffen erfahrungsgemäß, weil im Zweifel niemand den ersten Schritt macht. Plane für die komplette Umsetzung aller zwölf Schritte realistisch ein bis zwei Arbeitstage ein, wenn du bei null anfängst, für das reine Beispielprojekt aus dieser Anleitung reichen 90 Minuten.

Schritt 1: Bestandsaufnahme – Schatten-KI im Unternehmen aufspüren

Der erste Schritt hat nichts mit Technik zu tun, sondern mit Sichtbarkeit. Eine Analyse zu Schatten-KI aus dem Sommer 2026 empfiehlt, fünf Quellen systematisch zu prüfen: .env-Dateien in Repositories, bestehende Secret-Manager-Einträge, CI/CD-Pipelines, IDE-Konfigurationen und ausgehenden Netzwerkverkehr zu bekannten LLM-Endpunkten. Nur so findest du nicht genehmigte KI-Nutzung, bevor sie zum Datenschutzproblem wird.

Praktisch heißt das: Prüfe deine Firewall- oder Proxy-Logs auf Zugriffe auf api.openai.com, api.anthropic.com oder generativelanguage.googleapis.com von Rechnern, die dafür nie offiziell freigeschaltet wurden. Ergänze das mit einer Inventur aller Repos, die Machine-Learning-Code enthalten, und einer kurzen Umfrage im Team, welche KI-Tools tatsächlich im Alltag genutzt werden. Die Lücke zwischen offizieller Liste und echter Nutzung ist meistens größer, als IT-Teams erwarten.

# Proxy-Logs grob nach bekannten LLM-Endpunkten filtern
grep -E "api\.openai\.com|api\.anthropic\.com|generativelanguage\.googleapis\.com" \
  /var/log/squid/access.log | awk '{print $3, $7}' | sort | uniq -c | sort -rn

Das Ergebnis ist eine einfache Häufigkeitsliste, welche interne IP-Adresse wie oft welchen LLM-Endpunkt anspricht. Tauchen dort Rechner auf, die laut IT-Inventar keine KI-Freigabe haben, ist das der erste konkrete Fund deiner Bestandsaufnahme, und ein guter Anlass für ein Gespräch statt für eine Abmahnung.

Schritt 2: Secret Manager statt Klartext-Keys einrichten

Das OWASP Secure AI Model Ops Cheat Sheet, zuletzt im August 2026 aktualisiert, nennt Secret Manager wie AWS Secrets Manager oder HashiCorp Vault als Grundvoraussetzung für jede produktive KI-Anwendung. Statt API-Keys in Umgebungsvariablen der Anwendung oder, schlimmer, direkt im Code zu hinterlegen, wandern sie in einen zentralen, verschlüsselten Speicher mit Zugriffsprotokoll.

# Vault im Dev-Modus starten (nur für lokale Tests, nicht produktiv!)
vault server -dev -dev-root-token-id="root" &

# In einem zweiten Terminal: Vault-Adresse setzen
export VAULT_ADDR='http://127.0.0.1:8200'
export VAULT_TOKEN='root'

# KV-Secrets-Engine aktivieren
vault secrets enable -path=llm-secrets kv-v2

# API-Key für den LLM-Provider ablegen
vault kv put llm-secrets/openai api_key="sk-...dein-key..."

# Key wieder auslesen (zur Kontrolle)
vault kv get llm-secrets/openai

Die Ausgabe von vault kv get zeigt dir Metadaten wie Erstellungszeit und Versionsnummer zusätzlich zum Key selbst. Das ist der entscheidende Unterschied zu einer .env-Datei: Jeder Lesezugriff wird protokolliert, und du kannst den Key jederzeit rotieren, ohne den Anwendungscode anzufassen. Eine typische Ausgabe sieht so aus:

====== Metadata ======
Key                Value
---                -----
created_time       2026-09-10T08:12:41Z
custom_metadata    
deletion_time      n/a
destroyed          false
version            3

===== Data =====
Key         Value
---         -----
api_key     sk-...dein-key...

Die version zeigt, dass dieser Key bereits zweimal rotiert wurde, drei Versionen inklusive der aktuellen. Genau diese Historie fehlt bei einer klassischen .env-Datei komplett, dort gibt es nur den einen aktuellen Wert und keine Nachvollziehbarkeit, wann und warum er sich geändert hat. Für den produktiven Einsatz ersetzt du den Dev-Modus durch eine echte Vault-Installation mit Auto-Unseal und Storage-Backend, der Dev-Server dient ausschließlich dem lokalen Ausprobieren.

Falls Vault für dein Team zu viel Betriebsaufwand bedeutet, sind AWS Secrets Manager, Azure Key Vault oder Google Secret Manager gleichwertige Alternativen mit demselben Grundprinzip: zentrale Ablage, feingranulare Zugriffsrechte und ein lückenloses Zugriffsprotokoll. Entscheidend ist nicht der Anbietername, sondern dass überhaupt ein dedizierter Secret Manager zum Einsatz kommt, statt Zugangsdaten verstreut in Konfigurationsdateien, Wikis oder Chat-Verläufen zu verwalten.

Schritt 3: Zugriff auf Secrets mit Policies begrenzen

Ein Secret Manager ohne Zugriffsregeln ist nur eine zentralisierte Version desselben Problems. Vault-Policies legen fest, welcher Dienst welches Secret lesen darf, nach dem Least-Privilege-Prinzip. Microsofts Zero-Trust-Leitfaden zu KI-Angriffstechniken empfiehlt dafür rollenbasierte Zugriffskontrolle (RBAC), eingeschränkten Werkzeugzugriff und Service-Identitäten pro Komponente, damit jeder Baustein nur auf die Daten zugreifen kann, die er für seine Aufgabe wirklich braucht.

# policy.hcl: Nur Lesezugriff auf den LLM-Pfad
path "llm-secrets/data/openai" {
  capabilities = ["read"]
}

# Policy in Vault registrieren
vault policy write llm-reader policy.hcl

# Token mit dieser Policy für den Gateway-Dienst erzeugen
vault token create -policy="llm-reader" -ttl="24h"

Der letzte Befehl erzeugt ein Token, das nach 24 Stunden automatisch verfällt. Das begrenzt den Schaden, falls dieses Token selbst irgendwo landet, wo es nicht hingehört. Kombiniere das mit IP-Whitelisting auf Netzwerkebene, wenn dein Gateway von einer festen Serverliste aus zugreift.

Lege für unterschiedliche Rollen getrennte Policies an, statt eine einzige Policy für alle Dienste zu verwenden. Ein Beispiel: Der Gateway-Dienst bekommt reinen Lesezugriff auf den API-Key, ein separater Rotationsjob bekommt zusätzlich Schreibrechte auf denselben Pfad, und ein Audit-Dienst bekommt nur Lesezugriff auf die Zugriffsprotokolle, aber nicht auf die Secrets selbst. Diese Trennung sorgt dafür, dass eine kompromittierte Komponente nie automatisch alle anderen mit sich reißt.

Schritt 4: API-Keys rotieren und mit RBAC scopen

Ein deutschsprachiger Fachartikel zu LLM-API-Sicherheit, zuletzt im August 2026 aktualisiert, rät, API-Zugangsdaten wie kryptografische Assets zu behandeln: im Secret Manager speichern, verschlüsseln, per RBAC und IP-Whitelisting absichern und regelmäßig rotieren. Die Rotation lässt sich automatisieren, statt sie als jährliche Erinnerung im Kalender zu verwalten.

#!/usr/bin/env python3
# rotate_key.py: einfache Rotationslogik für einen LLM-API-Key
import subprocess, datetime

def rotate_key(new_key: str) -> None:
    timestamp = datetime.datetime.utcnow().isoformat()
    subprocess.run([
        "vault", "kv", "put", "llm-secrets/openai",
        f"api_key={new_key}",
        f"rotated_at={timestamp}"
    ], check=True)
    print(f"Key rotiert um {timestamp}")

if __name__ == "__main__":
    rotate_key(new_key="sk-...neuer-key...")

Plane die Rotation an einen Cron-Job oder eine CI/CD-Pipeline, die alle 30 bis 90 Tage automatisch einen neuen Key beim Provider anfordert und den alten widerruft. Wichtig: Scope jeden Key so eng wie möglich. Ein Key für den Batch-Job, der nachts Reports erstellt, braucht andere Limits als der Key, der Live-Chatanfragen von Kunden bedient.

Halte bei jeder Rotation den alten Key noch für ein kurzes Übergangsfenster aktiv, meist 15 bis 30 Minuten, bevor du ihn endgültig widerrufst. Andernfalls riskierst du, dass laufende Anfragen mitten in der Bearbeitung mit einem 401-Fehler abbrechen. Die meisten Provider-APIs unterstützen genau dafür einen zweiten, parallel gültigen Key, oft als sekundären oder Backup-Key bezeichnet.

Schritt 5: Secrets-Scanning in der CI/CD-Pipeline verankern

Selbst mit einem Secret Manager passieren Fehler, ein Praktikant kopiert einen Key testweise in eine Debug-Zeile, ein Commit wird versehentlich gepusht. Genau hier setzt automatisiertes Secrets-Scanning an. Ein Snyk-Vergleich von Ende März 2026 nennt für Gitleaks eine Recall-Quote von 88 Prozent bei 46 Prozent Precision, TruffleHog kommt in diesem Test auf 52 Prozent Recall. Kein Tool ist perfekt, aber jedes ist besser als kein Scan.

# .github/workflows/secrets-scan.yml
name: Secrets Scan
on: [push, pull_request]

jobs:
  gitleaks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Run Gitleaks
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Ein typischer Fund im Terminal sieht so aus: Finding: sk-proj-*** | Secret: OpenAI API Key | File: notebooks/test.ipynb | Line: 42. Lässt du den Job bei einem Treffer fehlschlagen (exit code 1), verhindert das den Merge, bis das Secret entfernt und der betroffene Key widerrufen wurde. Ergänze das um ggshield, wenn du zusätzlich KI-spezifische Secret-Muster wie Anthropic- oder Mistral-Keys erkennen willst.

Ergänzend lohnt sich ein lokaler Pre-Commit-Hook, damit ein Fund gar nicht erst bis zum Push kommt:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.21.2
    hooks:
      - id: gitleaks

Nach pip install pre-commit && pre-commit install läuft der Scan bei jedem lokalen Commit automatisch mit. Das kostet auf einem durchschnittlichen Repository kaum mehr als ein bis zwei Sekunden, verhindert aber den Großteil der versehentlichen Leaks, bevor sie überhaupt in die Historie gelangen. Kombiniere den lokalen Hook mit dem CI-Job aus dem Beispiel oben, denn nicht jeder Entwickler installiert Pre-Commit-Hooks zuverlässig, die Pipeline ist die letzte Verteidigungslinie vor dem Merge.

Findest du beim ersten Scan einen Key, der bereits vor Monaten committet wurde, reicht das Löschen der aktuellen Zeile nicht aus, der alte Wert bleibt in der Git-Historie für jeden sichtbar, der das Repository klont. In diesem Fall musst du die Historie selbst bereinigen, etwa mit dem BFG Repo-Cleaner oder git filter-repo, und den betroffenen Key beim Provider parallel widerrufen. Die Reihenfolge ist wichtig: Zuerst den Key sperren, danach in Ruhe die Historie aufräumen, denn ein bereits kompromittierter Key bleibt gefährlich, solange er gültig ist, unabhängig davon, wie schnell die Git-Historie bereinigt wird.

Schritt 6: Modellgewichte verschlüsseln und read-only bereitstellen

Wer eigene Modelle hostet, etwa über Ollama, vLLM oder llama.cpp, muss auch die Gewichtsdateien selbst schützen. Ein Sicherheitsleitfaden zu Self-Hosted LLMs aus dem Juni 2026 empfiehlt, Modellgewichte auf verschlüsselten Datenträgern mit Read-Only-Mounts zu speichern und den Inference-Zugang ausschließlich über einen authentifizierenden Gateway freizugeben.

# docker-compose.yml (Ausschnitt): Modellgewichte read-only mounten
services:
  ollama:
    image: ollama/ollama:latest
    volumes:
      - type: bind
        source: /srv/models
        target: /root/.ollama/models
        read_only: true
    networks:
      - internal
    # Kein Port-Mapping nach außen: nur der Gateway darf zugreifen

networks:
  internal:
    internal: true

Das internal: true-Netzwerk sorgt dafür, dass der Ollama-Container gar keine Route ins öffentliche Internet hat. Zugriff bekommt ausschließlich der Gateway-Dienst, den du im nächsten Schritt aufsetzt. Für die Festplattenverschlüsselung reicht unter Linux LUKS, unter den gängigen Cloud-Anbietern ist Verschlüsselung im Ruhezustand oft nur ein Häkchen beim Erstellen des Volumes.

Denk zusätzlich an die Dateiberechtigungen auf Betriebssystemebene. Modellgewichte sollten einem eigenen Systembenutzer gehören, nicht dem Benutzer, unter dem auch die Webanwendung läuft. So verhindert ein einfaches chmod 640 in Kombination mit einer eigenen Benutzergruppe, dass ein kompromittierter Webserver-Prozess direkt auf die Gewichte zugreifen kann, selbst wenn der Read-Only-Mount aus irgendeinem Grund umgangen wird. Wer Modelle in der Cloud hostet, sollte zusätzlich prüfen, ob der verwendete Object-Storage-Bucket per Default privat ist, und das regelmäßig automatisiert kontrollieren, nicht nur einmal beim Einrichten.

Schritt 7: Authentifizierenden Gateway vor die Inference-API setzen

Ein Enterprise-LLM-Leitfaden von März 2026 empfiehlt für produktive Setups JWT-basierte Authentifizierung, RBAC, tokenbewusstes Rate-Limiting und Netzwerksegmentierung mit mTLS zwischen den Diensten. Der Gateway ist die zentrale Kontrollstelle, durch die jede Anfrage muss, bevor sie das Modell erreicht.

# gateway.py: minimaler FastAPI-Gateway mit JWT-Prüfung
from fastapi import FastAPI, Depends, HTTPException, Header
import jwt

app = FastAPI()
SECRET = "aus-vault-laden-nicht-hardcoden"

def verify_token(authorization: str = Header(...)):
    token = authorization.replace("Bearer ", "")
    try:
        payload = jwt.decode(token, SECRET, algorithms=["HS256"])
        return payload
    except jwt.InvalidTokenError:
        raise HTTPException(status_code=401, detail="Ungültiges Token")

@app.post("/v1/chat")
def chat(payload: dict, user=Depends(verify_token)):
    # Hier folgt der Aufruf an Ollama oder die externe LLM-API
    return {"status": "authentifiziert", "tenant": user.get("tenant")}

Wichtig: Der SECRET-Wert im Beispiel steht dort nur zur Veranschaulichung, in der Praxis lädst du ihn zur Laufzeit aus Vault, genau wie den LLM-API-Key selbst. Ergänze MFA für administrative Zugriffe auf den Gateway und aktiviere mTLS zwischen Gateway und Modell-Container, sobald beide auf getrennten Hosts laufen.

Teste den Gateway direkt nach dem Deployment mit einem einfachen curl-Aufruf, um Authentifizierung und Fehlerverhalten zu prüfen:

curl -i -X POST http://localhost:8443/v1/chat \
  -H "Authorization: Bearer ungueltiges-token" \
  -H "Content-Type: application/json" \
  -d '{"prompt": "Testanfrage"}'

# Erwartete Antwort:
# HTTP/1.1 401 Unauthorized
# {"detail":"Ungültiges Token"}

Nur wenn ein ungültiges Token zuverlässig mit 401 abgelehnt wird, ist der Gateway korrekt verdrahtet. Erst danach folgt der Test mit einem gültigen, kurzlebigen Token aus deinem Authentifizierungssystem. Verzichte darauf, den Gateway während der Testphase versehentlich offen im Internet erreichbar zu lassen, ein kurzer Blick in die Firewall-Regeln vor dem ersten öffentlichen Deployment erspart unangenehme Überraschungen.

Schritt 8: Rate Limits und Spend Limits pro Mandant setzen

Ohne Limits wird aus einem gestohlenen Token schnell eine vierstellige Rechnung, oder ein Denial-of-Service gegen dein eigenes Modell. Das OWASP Secure AI Model Ops Cheat Sheet nennt Token-, Request-, Concurrency- und Spend-Limits pro Mandant als Standardmaßnahme.

Limit-Typ	Beispielwert	Schützt vor
Requests pro Minute	60 pro Nutzer	Automatisierten Massenanfragen
Tokens pro Tag	500.000 pro Mandant	Kostenexplosion bei Missbrauch
Concurrency	5 parallele Anfragen	Ressourcen-Erschöpfung
Spend-Limit	Hartes Tages-Budget in Euro	Unkontrollierten API-Kosten

Setze diese Limits direkt im Gateway um, nicht erst beim Provider. Ein 429-Statuscode mit klarer Fehlermeldung ist für einen legitimen Nutzer nur ein kurzer Stolperstein, für einen automatisierten Angriff dagegen ein harter Stopp. Prüfe die Limits monatlich anhand der tatsächlichen Nutzung, zu enge Werte frustrieren Teams, zu weite Werte verlieren ihren Schutzeffekt.

Ein realistisches Szenario: Ein interner Chatbot für den Kundenservice verbraucht im Normalbetrieb rund 40.000 Tokens pro Stunde. Ohne Limit kann ein gestohlenes Token, das über ein Skript automatisiert Anfragen abfeuert, denselben Wert in wenigen Minuten erreichen. Mit einem Concurrency-Limit von fünf gleichzeitigen Anfragen und einem Tages-Budget verlangsamt sich der Missbrauch so weit, dass dein Monitoring aus Schritt 10 genug Zeit hat, Alarm zu schlagen, bevor die Rechnung außer Kontrolle gerät.

Schritt 9: Prompt-Injection- und Output-Leak-Filter einbauen

Das OWASP Prompt Injection Prevention Cheat Sheet, im August 2026 zuletzt aktualisiert, nennt Rate Limiting, Content Filter und Circuit Breaker als aktuelle Verteidigungslinien, ergänzt um lückenloses Logging aller LLM-Interaktionen. OWASP beschreibt Prompt Injection dabei als Schwachstelle, bei der manipulierte Eingaben das beabsichtigte Verhalten eines Sprachmodells verändern, mit dem Risiko, dass Systemprompts, interne Anweisungen oder zuvor geladene Kontextdaten in der Antwort wieder auftauchen. Red Hat ordnet die Abwehr von Prompt Injection dabei explizit als Architekturfrage ein, nicht als reines Prompt-Engineering-Problem.

# output_filter.py: einfacher Post-Generation-Filter gegen Secret-Leaks
import re

SECRET_PATTERNS = [
    r"sk-[A-Za-z0-9]{20,}",      # OpenAI-artige Keys
    r"AKIA[0-9A-Z]{16}",         # AWS Access Keys
    r"-----BEGIN (RSA )?PRIVATE KEY-----",
]

def scrub(output: str) -> str:
    for pattern in SECRET_PATTERNS:
        output = re.sub(pattern, "[REDACTED]", output)
    return output

Dieser Filter läuft, nachdem das Modell geantwortet hat, und ersetzt erkannte Muster, bevor die Antwort den Nutzer erreicht. Kombiniere ihn mit einer semantischen Firewall vor dem Modell, wie es eine deutschsprachige Quelle vom Oktober 2025 vorschlägt: Systemprompts landen in einem schreibgeschützten, signierten Speicher, sodass sie sich zur Laufzeit nicht durch geschickte Eingaben überschreiben lassen.

Schritt 10: Logging und Monitoring aller LLM-Interaktionen

Ohne Protokoll gibt es im Ernstfall keine Antwort auf die Frage, was genau abgeflossen ist. Logge pro Anfrage mindestens Zeitstempel, Mandant, verwendetes Modell, Tokenzahl und, sofern datenschutzrechtlich vertretbar, einen Hash des Prompts zur Deduplizierung auffälliger Muster. Richte darauf einen Alert ein, der bei ungewöhnlichen Spitzen im Tokenverbrauch oder bei wiederholten 401-Antworten auf falsche Tokens automatisch das Sicherheitsteam benachrichtigt.

Ein Beispiel für eine unauffällige, aber verräterische Logzeile: 2026-09-10T03:14:02Z tenant=default model=llama3 tokens=48213 status=200. Ein einzelner Batch-Job mit 48.000 Tokens um drei Uhr nachts ist vielleicht normal, wenn er sich jede Nacht wiederholt, aber ein einmaliger Ausreißer dieser Größe verdient einen zweiten Blick.

Wer bereits ein SIEM-System im Einsatz hat, sollte die Gateway-Logs dort zentral einspeisen, statt eine separate Insellösung nur für KI-Vorfälle zu betreiben. So lassen sich auffällige Muster im LLM-Traffic mit anderen Sicherheitsereignissen korrelieren, etwa einem gleichzeitigen fehlgeschlagenen Login auf demselben Nutzerkonto. Für kleinere Teams reicht zum Einstieg auch ein einfacher Log-Aggregator mit einem täglichen Report, wichtig ist nur, dass überhaupt jemand regelmäßig hinschaut und nicht nur im Ernstfall in die Logs blickt.

Schritt 11: Netzwerksegmentierung mit mTLS zwischen Services

Isoliere Gateway, Modell-Container, Vektor-Datenbank und Secret Manager in getrennten Netzwerksegmenten. Zwischen den Diensten kommt mTLS zum Einsatz, sodass sich zwei Komponenten gegenseitig per Zertifikat authentifizieren, statt sich blind zu vertrauen, nur weil sie im selben internen Netz liegen. Isoliere zusätzlich die RAG-Pipeline: Ein Dienst, der nur Embeddings berechnet, braucht keinen direkten Zugriff auf den Secret Manager, in dem der LLM-API-Key liegt.

In der Praxis reicht dafür oft ein Service Mesh wie Linkerd oder eine einfache Zertifikatsverwaltung über cert-manager in Kubernetes. Wichtig ist weniger das konkrete Werkzeug als das Prinzip: Jede Verbindung zwischen zwei Diensten sollte begründbar sein, nicht einfach erlaubt, weil es historisch so gewachsen ist.

Ein einfacher, aber wirkungsvoller Test: Erstelle ein Diagramm aller Dienste in deinem KI-Stack und zeichne jede erlaubte Verbindung als Pfeil ein. Bleiben danach Pfeile übrig, die sich nicht in zwei Sätzen begründen lassen, etwa “der Reporting-Dienst braucht Zugriff auf den Secret Manager, weil…” , ist das ein guter Kandidat, um die Verbindung zu entfernen oder zumindest enger zu scopen.

Schritt 12: Incident-Response-Plan für den Ernstfall

Trotz aller Vorsorge kann ein Leak passieren. Ein Incident-Response-Plan für KI-Modelle sollte vier Punkte klar regeln: Wer widerruft im Notfall welchen Key, welches Team prüft die Logs auf Missbrauch, wie wird der Vorfall dokumentiert, und ab welcher Schwere greift die Meldepflicht nach DSGVO oder gegebenenfalls NIS2. Übe diesen Ablauf einmal im Jahr wie eine Feuerübung, damit im Ernstfall niemand erst die Dokumentation suchen muss.

Eine minimale Checkliste für die ersten 60 Minuten nach der Entdeckung eines Leaks:

• Betroffenen API-Key oder Zugang sofort beim Provider widerrufen
• Neuen Key über den Rotationsprozess aus Schritt 4 ausrollen
• Logs der letzten 30 Tage auf ungewöhnliche Nutzung dieses Keys prüfen
• Betroffene Systeme und Zeitraum in der Vorfallsdokumentation festhalten
• Prüfen, ob personenbezogene Daten betroffen waren und eine Meldepflicht nach DSGVO greift
• Nach Abschluss eine kurze Ursachenanalyse im Team durchführen, ohne einzelne Personen an den Pranger zu stellen

Halte für jeden produktiven LLM-Dienst eine Kontaktliste bereit: Wer beim Cloud-Anbieter kann einen Key sofort sperren, wer im eigenen Team hat Zugriff auf Vault, und welche externe Meldestelle, etwa das BSI, muss bei einem größeren Vorfall informiert werden.

Dokumentiere jeden Vorfall unabhängig von seiner Schwere in einer einfachen Tabelle: Datum, betroffener Key oder Dienst, vermuteter Auslöser, ergriffene Sofortmaßnahme und Abschlussdatum. Diese Historie zahlt sich doppelt aus, sie hilft bei wiederkehrenden Mustern, etwa wenn immer wieder derselbe Batch-Job betroffen ist, und sie ist die erste Unterlage, die ein Prüfer oder eine Aufsichtsbehörde im Zweifel sehen will.

Häufige Fehler beim Absichern von KI-Modellen

Die meisten Vorfälle entstehen nicht durch ausgefeilte Angriffe, sondern durch dieselben wiederkehrenden Nachlässigkeiten. Diese sechs Fehler tauchen in Audits am häufigsten auf.

• Keys in Notebooks statt Secret Manager: Jupyter-Notebooks landen erstaunlich oft in Repositories, inklusive ausgeführter Zellen mit Klartext-Keys in der Ausgabe.
• Ein Key für alle Umgebungen: Dev, Staging und Produktion teilen sich denselben API-Key, sodass ein Leak in der Testumgebung sofort die Produktion betrifft.
• Rate Limits nur beim Provider, nicht im eigenen Gateway: Providerseitige Limits greifen oft erst, wenn der Schaden schon entstanden ist.
• Fehlende Isolation der RAG-Pipeline: Die Vektor-Datenbank mit Kundendaten läuft im selben Netzwerksegment wie öffentlich erreichbare Dienste.
• Kein Rotationsplan: Ein Key wird einmal erstellt und dann nie wieder angefasst, oft über Jahre.
• Systemprompts als vermeintliches Geheimnis: Teams verlassen sich darauf, dass Nutzer den Systemprompt nicht extrahieren können, obwohl das per Prompt Injection regelmäßig gelingt.
• Logging erst nach dem ersten Vorfall aktiviert: Ohne historische Daten lässt sich im Nachhinein kaum rekonstruieren, seit wann ein Missbrauch tatsächlich läuft.
• Vertrauen in den Provider-Namen statt in eigene Kontrollen: Ein bekannter, seriöser API-Anbieter schützt nicht vor einem Key, der im eigenen Repository offen herumliegt.

Troubleshooting: Die häufigsten Probleme und Lösungen

Auch bei sorgfältiger Umsetzung tauchen beim ersten Aufsetzen des Stacks typische Stolpersteine auf. Die folgende Tabelle deckt die neun häufigsten Fälle aus der Praxis ab, sortiert nach der Reihenfolge der Schritte in dieser Anleitung.

Problem	Lösung
Vault startet, aber vault kv get schlägt fehl	Prüfe, ob VAULT_ADDR und VAULT_TOKEN im aktuellen Terminal gesetzt sind
Gitleaks findet in CI nichts, obwohl lokal ein Fund auftaucht	Setze fetch-depth: 0 im Checkout-Schritt, sonst fehlt die Git-Historie
Gateway gibt 401 trotz gültigem Token zurück	Uhrzeit zwischen Client und Server prüfen, JWT-Ablauf reagiert empfindlich auf Zeitversatz
Ollama-Container hat trotz internal: true Internetzugriff	Docker-Netzwerk neu erstellen, alte Netzwerke behalten teils alte Routing-Regeln
Rate Limiting blockiert legitime Nutzer	Limits pro Mandant statt global setzen und Werte anhand echter Nutzungsdaten kalibrieren
Output-Filter erkennt Secret-Muster nicht	Regex-Pattern erweitern, neue Provider-Key-Formate regelmäßig nachpflegen
mTLS-Handshake zwischen Services schlägt fehl	Zertifikatskette und Ablaufdatum prüfen, häufigste Ursache ist ein abgelaufenes Zertifikat
Secrets-Scan meldet False Positives bei Test-Keys	Bekannte Test-Werte in einer Allowlist-Datei des Scanners eintragen, nicht den Scan deaktivieren
Rotationsskript schlägt beim Provider-API-Call fehl	Retry mit Backoff einbauen, viele Provider-APIs haben eigene Rate Limits für Key-Management

Fortgeschrittene Tipps für Enterprise-Setups

Sobald die zwölf Grundschritte stehen, lohnt sich der Blick auf Maßnahmen, die über den Standardfall hinausgehen. Diese fünf Ansätze setzen größere Teams zusätzlich ein, wenn KI-Anwendungen produktiv und in größerem Umfang laufen.

• Canary-Tokens einsetzen: Lege absichtlich einen Fake-Key ins Repo, der bei Nutzung sofort einen Alarm auslöst und dir zeigt, ob überhaupt jemand nach Secrets sucht.
• Confidential Computing für Modellgewichte: Bei besonders sensiblen, selbst trainierten Modellen lohnt sich der Blick auf Trusted Execution Environments, die Gewichte auch während der Inferenz verschlüsselt halten.
• SBOM auch für KI-Abhängigkeiten: Führe eine Software-Bill-of-Materials, die nicht nur Python-Pakete, sondern auch verwendete Modellversionen und deren Lizenzen erfasst.
• Wiz-Studie als Weckruf nutzen: Laut einer Untersuchung von Wiz von November 2025 hatten 65 Prozent der geprüften Forbes-AI-50-Unternehmen verifizierte Secrets auf GitHub offengelegt. Selbst gut finanzierte KI-Firmen sind nicht automatisch sicherer.
• Regelmäßige Red-Team-Übungen gegen die eigene KI-Anwendung: Lasse gezielt versuchen, Systemprompts oder Trainingsdaten über Prompt Injection zu extrahieren, und behebe jede erfolgreiche Lücke.
• Output-Wasserzeichen für generierte Inhalte: Markiere KI-generierte Antworten intern mit unsichtbaren Metadaten, um im Streitfall nachweisen zu können, ob ein Text tatsächlich aus deinem System stammt.
• Getrennte Kostenstellen pro Team: Ordne Spend-Limits nicht nur technisch, sondern auch buchhalterisch einzelnen Teams zu, damit ein Kostenanstieg sofort dem richtigen Verantwortlichen auffällt, nicht erst der Finanzabteilung am Monatsende.

Das komplette Projekt: Sicherer Self-Hosted-LLM-Stack zum Nachbauen

Zum Abschluss ein vollständiges Beispiel, das die wichtigsten Bausteine aus dieser Anleitung zusammenführt: Vault für Secrets, Ollama für das Modell in einem isolierten Netzwerk und ein Gateway als einzigen öffentlichen Zugangspunkt.

# docker-compose.yml: kompletter Mini-Stack
version: "3.9"
services:
  vault:
    image: hashicorp/vault:latest
    cap_add: [IPC_LOCK]
    environment:
      VAULT_DEV_ROOT_TOKEN_ID: "root"
    networks: [internal]

  ollama:
    image: ollama/ollama:latest
    volumes:
      - type: bind
        source: /srv/models
        target: /root/.ollama/models
        read_only: true
    networks: [internal]

  gateway:
    build: ./gateway
    depends_on: [vault, ollama]
    ports:
      - "8443:8443"
    networks: [internal, public]

networks:
  internal:
    internal: true
  public:

Nur der Gateway-Dienst hängt sowohl im internen als auch im öffentlichen Netzwerk, Vault und Ollama sind von außen unerreichbar. Starte den Stack mit docker compose up -d und prüfe mit docker compose logs gateway, ob die Verbindung zu Vault und Ollama beim Start erfolgreich aufgebaut wurde.

Lege zusätzlich eine .env.example-Datei ins Repository, die zeigt, welche Umgebungsvariablen der Gateway erwartet, ohne echte Werte zu enthalten:

# .env.example: Vorlage, niemals mit echten Werten committen
VAULT_ADDR=http://vault:8200
VAULT_ROLE_ID=
VAULT_SECRET_ID=
JWT_ISSUER=
RATE_LIMIT_PER_MINUTE=60
SPEND_LIMIT_DAILY_EUR=50

Jeder Entwickler kopiert diese Datei lokal zu .env und trägt echte Werte ein, während die Vorlage selbst frei von Secrets bleibt und bedenkenlos im Repository liegen kann. Von hier aus lässt sich der Stack schrittweise um die Filter- und Rate-Limiting-Logik aus den vorherigen Schritten erweitern, bis alle zwölf Maßnahmen produktiv laufen. Ein guter Test für den Abschluss: Führe alle neun Troubleshooting-Fälle aus der Tabelle oben einmal bewusst herbei und prüfe, ob dein Setup jeweils das erwartete Verhalten zeigt, bevor der Stack live geht.

Häufig gestellte Fragen

Was zählt genau als KI-Modell-Leak?

Darunter fallen vier Fälle: offengelegte API-Keys, gestohlene oder öffentlich zugängliche Modellgewichte, ausgeleitete Trainings- oder RAG-Daten sowie unautorisierte Nutzung externer KI-Dienste über Schatten-IT.

Wie oft werden LLM-API-Keys tatsächlich geleakt?

GitGuardian zählte für 2025 über 1,27 Millionen KI-Service-Secrets in öffentlichen GitHub-Commits, ein Anstieg von 81 Prozent gegenüber dem Vorjahr. Die Dunkelziffer in privaten Repositories dürfte deutlich höher liegen.

Reicht ein Secret Manager allein aus, um KI-Modelle abzusichern?

Nein. OWASP betont, dass Prompt-Injection-Abwehr und Secret-Schutz allein nicht genügen, notwendig sind zusätzlich Output-Validierung, Least-Privilege-Zugriff, lückenloses Logging und die Trennung von System- und Nutzeranweisungen.

Muss ich Modellgewichte auch bei einem reinen API-Zugang wie über Claude oder GPT schützen?

Die Gewichte selbst liegen dann beim Anbieter, trotzdem bleiben API-Key, Rate Limits, Logging und Output-Filterung in deiner Verantwortung. Diese Bausteine schützen dich unabhängig davon, ob das Modell lokal oder in der Cloud läuft.

Wie erkenne ich Schatten-KI im eigenen Unternehmen?

Prüfe Firewall- und Proxy-Logs auf Zugriffe zu bekannten LLM-Endpunkten von nicht freigegebenen Systemen, ergänzt um eine Inventur der .env-Dateien, CI/CD-Pipelines und IDE-Konfigurationen im Unternehmen.

Welche Rolle spielt die DSGVO beim Schutz von KI-Trainingsdaten?

Sobald personenbezogene Daten in Trainings- oder RAG-Pipelines fließen, gelten die üblichen DSGVO-Pflichten zu Zweckbindung, Speicherbegrenzung und Meldepflicht bei einer Datenpanne unverändert weiter, unabhängig davon, ob die Verarbeitung über ein klassisches System oder ein Sprachmodell läuft.

Wie schnell sollte ich nach einem entdeckten Leak reagieren?

Widerrufe den betroffenen Key sofort, nicht erst nach Analyse der Logs. Die Analyse, wie viel abgeflossen ist, kann parallel laufen, die Sperrung des Zugangs duldet keinen Aufschub.

Welche Kosten verursacht die Absicherung eines KI-Modells realistisch?

Die in dieser Anleitung genutzten Werkzeuge, Vault, Gitleaks und ein selbst geschriebener Gateway, sind alle als Open-Source-Version kostenlos nutzbar. Kosten entstehen vor allem durch Betriebszeit für Einrichtung und Pflege sowie, bei sehr großen Setups, durch eine kommerzielle Vault-Lizenz mit zusätzlichem Support.

Unterscheidet sich der Schutz von KI-Modellen von klassischer API-Sicherheit?

Vieles überschneidet sich, Authentifizierung, Rate Limiting und Secret Management gelten für jede API. Neu bei KI-Modellen sind aber Risiken wie Prompt Injection, ungewollte Preisgabe von Trainingsdaten in generierten Antworten und der Schutz der Modellgewichte selbst, für die klassische API-Sicherheit keine fertigen Lösungen bereithält.