KI-APIs und LLM-Dienste sind in vielen IT-Stacks inzwischen Kernkomponenten – nicht nur in Entwicklungswerkzeugen, sondern auch in produktiven Systemen wie Monitoring-Automatisierung, Incident-Analyse und internen Assistenzsystemen. Doch anders als klassische Microservices werden KI-Endpunkte oft mit weniger Sicherheitssorgfalt behandelt: API-Keys landen in Environment-Variablen, Zugriffe werden selten auditiert, und Rate Limits werden erst konfiguriert, wenn Probleme auftreten.
Zero Trust als Sicherheitsprinzip bietet einen strukturierteren Ansatz – und dieser Artikel zeigt, wie er auf KI-Dienste angewendet wird.
Was Zero Trust in der Praxis bedeutet
Zero Trust ist kein Produkt und kein einzelnes Tool – es ist ein Architekturprinzip. Der Kern: Kein Zugriff wird standardmäßig als vertrauenswürdig eingestuft, weder von innen noch von außen. Jede Anfrage muss sich authentifizieren, autorisieren und auditierbar machen. Für KI-Dienste bedeutet das konkret:
- Wer darf welches Modell aufrufen und mit welchen Parametern?
- Welche Daten dürfen als Kontext an ein Modell mitgegeben werden?
- Wie wird protokolliert, was in Prompts und Antworten übermittelt wird?
- Wie wird sichergestellt, dass kompromittierte Zugangsdaten nicht unbegrenzt verwendet werden können?
Authentifizierung und Zugriffskontrolle für LLM-APIs
Statische API-Keys sind kein Authentifizierungskonzept
Statische API-Keys sind bequem, aber strukturell problematisch: Sie rotieren selten, sie landen in CI/CD-Logs, in .env-Dateien, in geteilten Dokumenten. Einmal kompromittiert, bieten sie vollen Zugriff auf den Dienst – oft ohne dass der Missbrauch sofort erkennbar ist.
Der erste Zero-Trust-Schritt ist daher, API-Keys durch kurzlebige Credentials zu ersetzen oder zumindest sicher zu verwalten:
- AWS IAM Roles: Für Bedrock-Zugriffe Instance Profiles statt statischer Keys verwenden
- Workload Identity: In Kubernetes-Umgebungen Service Accounts mit OIDC-Token für KI-API-Zugriffe einsetzen
- Secret Rotation: Wo statische Keys unvermeidbar sind, automatisierte Rotation über Tools wie HashiCorp Vault oder AWS Secrets Manager erzwingen
- Scope-Beschränkung: API-Keys mit minimalem Scope ausstellen – kein universeller Zugriff auf alle Modelle und Endpunkte
Least Privilege für KI-Zugriffe konsequent anwenden
Nicht jede Komponente benötigt Zugriff auf alle Modelle oder alle Funktionen eines KI-Dienstes. IAM-Policies oder API-Gateway-Konfigurationen sollten so gestaltet sein, dass jede Anwendung nur die Modelle aufrufen kann, die sie tatsächlich benötigt – und nur die Aktionen, die ihr Workflow erfordert. Ein Log-Analyse-Dienst braucht keinen Zugriff auf Bildgenerierungsmodelle; ein interner Chatbot braucht keine Agenten-Ausführungsrechte.
Netzwerksegmentierung und Endpunktkontrolle
KI-Dienste sollten nicht direkt aus öffentlichen Subnets erreichbar sein. Für selbst gehostete Modelle – etwa über Ollama oder vLLM auf eigener Infrastruktur – gilt dasselbe wie für jeden anderen internen Service: eigenes Subnetz, Firewall-Regeln, kein direkter Internet-Zugriff auf die Inference-Endpunkte.
Für externe KI-APIs gilt: Der ausgehende Traffic sollte über einen kontrollierten Egress-Punkt laufen – entweder ein API-Gateway als Proxy oder ein dedizierter Egress-NAT mit Allowlist. Das ermöglicht:
- Zentrales Rate Limiting unabhängig von der Client-Konfiguration
- Traffic-Logging ohne umfangreiche Client-seitige Instrumentierung
- Schnelles Sperren kompromittierter Credentials auf Netzwerkebene
- Einheitliche TLS-Inspection für ausgehende KI-API-Verbindungen
Prompt- und Response-Logging als Sicherheitssignal
Eine der wichtigsten Zero-Trust-Komponenten für KI-Dienste ist das Logging von Zugriffen und Nutzungsmustern. Vollständiges Prompt-Logging ermöglicht Sicherheitsanalyse, enthält aber potenziell sensible Daten – hier muss sorgfältig abgewogen werden.
Strukturiertes Metadaten-Logging ist für Sicherheitszwecke oft ausreichend und datenschutzfreundlicher:
- Service-ID und aufrufende Komponente
- Zeitstempel und Dauer des Aufrufs
- Verwendetes Modell und Modellversion
- Token-Anzahl (Input und Output getrennt)
- Erfolg oder Fehlercode
- User-ID oder Session-Referenz (ohne Prompt-Inhalt)
Dieses Metadaten-Profil reicht aus, um anomale Nutzungsmuster zu erkennen: ungewöhnlich hohe Token-Verbräuche, Aufrufe zu ungewöhnlichen Zeiten, unbekannte Calling-Services oder plötzliche Spitzen, die auf Credential-Missbrauch hindeuten können.
Rate Limiting und Kostenschwellenwerte als Sicherheitsebene
Rate Limiting schützt nicht nur vor Überlastung – es begrenzt auch den Schaden bei kompromittierten Credentials. Wenn ein gestohlener API-Key nur 100 Anfragen pro Minute generieren kann, ist der potenzielle Schaden strukturell begrenzt.
Konkrete Empfehlungen für den Betrieb:
- Rate Limits pro Service-ID oder Client-Credential konfigurieren, nicht nur global
- Burst-Limits für ungewöhnlich schnelle Anfragefolgen definieren
- Kostenschwellenwert-Alerts einrichten, die bei 70–80 % des Monatsbudgets warnen
- Automatische Sperrung oder Throttling bei Überschreitung kritischer Schwellenwerte
Prompt Injection: Eine neue Angriffskategorie
Zero Trust für KI-Dienste muss auch eine Bedrohung adressieren, die klassische Sicherheitsmodelle nicht kennen: Prompt Injection. Angreifer versuchen dabei, über manipulierte Eingaben – Benutzertexte, geparste Dokumente, externe Inhalte – das Verhalten des KI-Modells zu steuern. Ziele sind die Extraktion von Systemprompts, das Auslösen unerlaubter Aktionen oder das Umgehen von Sicherheitschecks.
Zero-Trust-Prinzipien helfen indirekt: Wenn KI-Agenten nur explizit erlaubte Aktionen ausführen können (Least Privilege auf Werkzeugebene), ist der Schaden durch Prompt Injection strukturell begrenzt. Ergänzend empfehlen sich:
- Strikte Trennung von Systemprompt und Nutzereingaben durch strukturierte Nachrichtenformate
- Validierung und Sanitierung von Eingaben, die aus externen Quellen stammen – Dokumente, E-Mails, Web-Inhalte
- Guardrails auf Modell- oder API-Ebene für sensible Informationskategorien
- Keine dynamische Konstruktion von Systemprompts aus Nutzereingaben
Praktischer Einstieg: Wo beginnen?
Wer Zero Trust für bestehende KI-Dienste einführen möchte, sollte priorisiert vorgehen:
- Inventar erstellen: Welche KI-Endpunkte werden von welchen Services genutzt? Welche Credentials werden wo verwendet?
- Credentials migrieren: Statische API-Keys durch verwaltete Identitäten oder automatisch rotierende Secrets ersetzen
- Metadaten-Logging aktivieren: Alle KI-API-Zugriffe mit Mindestmetadaten protokollieren
- Rate Limits konfigurieren: Pro Service und Credential definierte Limits einrichten
- Netzwerkzugriff kontrollieren: Egress-Kontrolle für ausgehende KI-API-Verbindungen einführen
Fazit: KI-Dienste sind Teil des Sicherheitsmodells
KI-APIs und LLM-Endpunkte sind keine Ausnahme vom Sicherheitsmodell – sie sind neue Zugriffspunkte in IT-Infrastruktur und müssen entsprechend behandelt werden. Die gute Nachricht: Zero-Trust-Prinzipien wie Least Privilege, kurzlebige Credentials, Netzwerksegmentierung und Audit-Logging sind auf KI-Dienste anwendbar – auch wenn die konkrete Implementierung Details erfordert, die sich von klassischen Services unterscheiden.
IT-Teams, die KI-Dienste ohne diese Absicherung betreiben, riskieren nicht nur Datenpannen – sie riskieren schwer nachverfolgbare Angriffe, die über KI-Systeme als Einfallstor stattfinden. Das Zero-Trust-Modell bleibt das zuverlässigste Gegenmittel.
Bildquelle: Pexels.com – Foto von Pixabay
Quellen: NIST Zero Trust Architecture SP 800-207 (csrc.nist.gov), OWASP LLM Top 10 2025 (owasp.org), AWS IAM Best Practices (aws.amazon.com), Anthropic API Security-Empfehlungen (anthropic.com)
