Die LLM-API ist immer noch eine API

Eine KI-Funktion erreicht den Nutzer fast nie als nacktes Modell, sondern als HTTP-Endpunkt: ein POST /chat, das einen Prompt entgegennimmt, ihn an ein Sprachmodell weiterreicht und die Antwort zurückgibt. Damit gelten zuerst alle Regeln, die für jede API gelten. Wer hier nur an Prompt Injection denkt, übersieht die Basis.

Konkret bedeutet das: Der LLM-Endpunkt braucht Authentifizierung und Autorisierung wie jeder andere. Eine Object-Level-Prüfung (BOLA) entscheidet, ob ein Nutzer überhaupt auf das Dokument, die Konversation oder den Datensatz zugreifen darf, den er per Prompt referenziert. Ohne diese Prüfung wird das Modell zum Umgehungspfad: Der Angreifer fragt nicht die geschützte Ressource direkt ab, sondern bittet die KI darum.

  • Rate Limiting und Quotas: LLM-Inferenz ist rechen- und kostenintensiv. Fehlende Begrenzung führt zu Denial of Service und direkten Geldverlusten. OWASP führt dies als eigenes Risiko LLM10:2025 Unbounded Consumption, das unter anderem Variable-Length-Input-Floods und Modelldiebstahl umfasst.
  • Eingabevalidierung: Auch wenn das Eingabefeld Freitext ist, gehören Länge, Format und Anzahl der Anhänge geprüft.
  • Fehlerbehandlung und Konfiguration: Stacktraces, Modellnamen oder System-Prompts dürfen nicht in Antworten oder Fehlermeldungen durchschlagen (vgl. API8:2023 Security Misconfiguration).

Die modellspezifischen Risiken kommen also zusätzlich zur klassischen API-Absicherung, nicht an ihrer Stelle.

IDRisikoKern der GefahrWichtigste Gegenmaßnahme
LLM01Prompt InjectionEingaben (direkt oder indirekt) verändern das Modellverhalten unbeabsichtigtVerhalten per System-Prompt einschränken, externe Inhalte kennzeichnen und trennen, Least Privilege
LLM02Sensitive Information DisclosurePII, Geheimnisse oder Zugangsdaten gelangen in die ModellausgabeDatenbereinigung/Maskierung vor Verarbeitung, Zugriffskontrolle, kein Training auf Eingaben
LLM05Improper Output HandlingUngeprüft weitergereichte Modellausgaben führen zu XSS, SSRF, RCEModellausgaben wie Nutzereingaben behandeln, kontextgerecht encodieren
LLM06Excessive AgencyZu viele Tools, Rechte oder Autonomie lassen schädliche Aktionen zuTools minimieren, Backend-Autorisierung (vollständige Mediation), Human-in-the-Loop
LLM10Unbounded ConsumptionUnkontrollierte Inferenz führt zu DoS, Kostenexplosion, ModelldiebstahlRate Limiting, Quotas und Spend-Limits, etwa am AI-Gateway

OWASP Top 10 for LLM Applications (2025): Kernrisiken für API-Betreiber

OWASP Top 10 for LLM Applications: die drei Kernrisiken

Das OWASP Gen AI Security Project pflegt mit den Top 10 for LLM Applications (Ausgabe 2025) den De-facto-Standard für modellspezifische Risiken. Drei Kategorien sind für API-Betreiber besonders relevant.

LLM01:2025 Prompt Injection

Prompt Injection liegt vor, wenn Eingaben das Verhalten oder die Ausgabe des Modells in unbeabsichtigter Weise verändern. OWASP unterscheidet direkte Injection (der Nutzer manipuliert den Prompt selbst) und indirekte Injection (das Modell verarbeitet manipulierte Inhalte aus externen Quellen wie Webseiten, Dokumenten oder Tool-Antworten). Da generative Modelle stochastisch arbeiten, gibt es laut OWASP keine narrensichere Prävention. Wirksame Maßnahmen sind Verhalten per System-Prompt einschränken, Ein- und Ausgaben filtern, externe Inhalte klar kennzeichnen und vom Nutzer-Prompt trennen sowie Least-Privilege für alle Modellzugriffe durchsetzen.

LLM02:2025 Sensitive Information Disclosure

Das Modell kann personenbezogene Daten (PII), Geschäftsgeheimnisse, Zugangsdaten oder proprietäre Algorithmen über seine Ausgaben preisgeben. Ursachen sind unzureichende Datenbereinigung, fehlende Zugriffskontrolle auf angebundene Datenquellen oder Trainingsdaten, die sensible Inhalte enthalten. OWASP empfiehlt Datenbereinigung (Scrubbing, Maskierung) vor jeder Verarbeitung, strikte Zugriffskontrollen und klare Nutzungsbedingungen. Wichtig: Eine reine Anweisung im System-Prompt, bestimmte Daten nicht herauszugeben, kann per Prompt Injection umgangen werden und ist daher keine verlässliche Kontrolle.

LLM06:2025 Excessive Agency

Sobald ein Modell Funktionen aufrufen oder Tools, Plugins und Extensions bedienen darf, entsteht Agency. Excessive Agency ist die Schwachstelle, die schädliche Aktionen aus unerwarteten, mehrdeutigen oder manipulierten Modell-Ausgaben heraus ermöglicht. OWASP nennt drei Wurzeln: übermäßige Funktionalität (das Tool kann mehr als nötig, etwa löschen statt nur lesen), übermäßige Berechtigungen (der genutzte Datenbank-Account hat UPDATE/DELETE statt nur SELECT) und übermäßige Autonomie (Aktionen ohne Bestätigung). Gegenmittel sind die Reduktion der Tools und ihrer Funktionen, Berechtigungen im Backend nach Least Privilege, Ausführung im Kontext des jeweiligen Nutzers (z. B. OAuth mit minimalem Scope) und ein Human-in-the-Loop für wirkungsstarke Aktionen.

Tool-Use und Datenabfluss: wenn das Modell handelt

Die gefährlichste Kombination entsteht, wenn indirekte Prompt Injection auf Excessive Agency trifft. OWASP illustriert das am Beispiel eines Assistenten mit Postfach-Zugriff: Eine präparierte eingehende E-Mail weist das Modell an, das Postfach nach sensiblen Informationen zu durchsuchen und sie an eine Angreifer-Adresse weiterzuleiten. Der Nutzer hat nie etwas Bösartiges eingegeben - der Angriff steckt im verarbeiteten Inhalt.

Daraus folgt eine klare Trennung von Verantwortlichkeiten: Das Modell entscheidet was getan werden soll, aber die Berechtigung ob es getan werden darf, gehört nicht in den Prompt. OWASP fasst das als Prinzip der vollständigen Mediation: Autorisierung wird im nachgelagerten System erzwungen, nicht vom Modell entschieden. Praktisch heißt das:

  • Tool-Aufrufe laufen über eigene, deterministisch im Code geprüfte Funktionen statt über offene Fähigkeiten wie run_shell oder fetch_url.
  • Jeder Tool-Aufruf trägt die Identität und den Scope des handelnden Nutzers, nicht einen generischen Hochprivileg-Account.
  • Ausgaben des Modells, die downstream verarbeitet werden, werden wie Nutzereingaben behandelt - sonst drohen laut LLM05:2025 Improper Output Handling XSS, SSRF oder sogar Remote Code Execution.
  • Hochwirksame Aktionen (Löschen, Versenden, Zahlungen) erfordern eine menschliche Freigabe.

Der Datenabfluss-Pfad ist dabei nicht nur die Antwort an den Nutzer, sondern jeder Kanal, den ein Tool öffnen kann: ausgehende HTTP-Requests, E-Mails, Datenbankschreibzugriffe.

KI-Codegeneratoren vergrößern die Angriffsfläche

Ein eigener Risikopfad entsteht abseits der Laufzeit: bei der Entwicklung selbst. KI-Codegeneratoren und Coding-Agenten erzeugen schnell neue Endpunkte, Hilfsrouten, Debug-Schnittstellen und Versionen. Was produktiv wird und was nur ein Entwurf bleibt, ist oft nicht sauber dokumentiert. So entstehen Phantom- oder Schatten-Endpunkte: Routen, die erreichbar sind, aber in keinem Inventar und keiner API-Spezifikation auftauchen.

Genau dieses Muster beschreibt OWASP als API9:2023 Improper Inventory Management. Angreifer gelangen typischerweise über alte API-Versionen oder vergessene, ungepatchte Endpunkte mit schwächeren Sicherheitsanforderungen an Zugriff. Eine API hat laut OWASP einen Dokumentations-Blindspot, wenn unklar ist, welche Version läuft, ob es Dokumentation gibt und ob ein Außerbetriebnahme-Plan existiert. KI-Generierung beschleunigt das Wachstum genau dieser unklaren Fläche.

Die Gegenmaßnahmen sind klassisch, gewinnen aber an Gewicht: ein gepflegtes Endpunkt-Inventar, automatisierte API-Discovery gegen den tatsächlichen Verkehr (nicht nur gegen die Doku), Versionierungs- und Retirement-Pläne sowie ein Abgleich generierter Routen mit der freigegebenen Spezifikation, bevor sie produktiv gehen. Wer KI im Build einsetzt, braucht deshalb eher mehr Inventardisziplin, nicht weniger.

AI-Gateways: zentraler Kontrollpunkt für LLM-Verkehr

Wie ein klassisches API Gateway zwischen Clients und Backends sitzt, schiebt sich ein AI-Gateway zwischen Anwendung und Modellanbieter. Es bündelt übergreifende Aufgaben für LLM-Verkehr an einem Punkt. Kong beschreibt sein AI Gateway als Kontroll- und Governance-Ebene, die über eine anbieterunabhängige API zu verschiedenen LLM-Providern routet, Zugangsdaten zentral verwaltet und Anfragen nach Kosten, Latenz oder Verfügbarkeit lenkt. Cloudflare beschreibt sein AI Gateway als Sichtbarkeits- und Kontrollschicht mit Analytics und Logging, Caching, Rate Limiting, Retries und Model-Fallback.

Sicherheitsrelevant sind vor allem diese Funktionen:

  • Zentrale Schlüsselverwaltung: Provider-Keys liegen im Gateway statt verstreut in Anwendungen, was Key-Leakage reduziert.
  • Rate Limiting und Spend-Limits: direkte Gegenmaßnahme gegen Unbounded Consumption.
  • Observability: Prompts, Token-Verbrauch und Kosten werden protokolliert und damit auditierbar.
  • Guardrails und Moderation: Ein- und Ausgaben lassen sich gegen Richtlinien prüfen. Mistrals Moderation umfasst etwa eine eigene Jailbreaking-Kategorie und kann über Custom Guardrails Eingaben vor Erreichen des Modells blockieren (HTTP 403).

Ein AI-Gateway ersetzt aber keine der OWASP-Maßnahmen. Es ist ein Durchsetzungspunkt - die Autorisierung pro Nutzer, das saubere Tool-Design und die Output-Behandlung bleiben Aufgabe der Anwendung. Und wie bei jedem Gateway gilt: Wenn ein verwaltetes Drittanbieter-SaaS den gesamten Prompt-Verkehr inklusive sensibler Payloads sieht, ist das eine bewusste Souveränitäts-Entscheidung.

Souverän umgesetzt: der Venedy-Ansatz

Venedy verarbeitet seine eigenen KI-Analysen über einen EU-KI-Anbieter und läuft auf europäischer Infrastruktur. Vor jeder KI-Anfrage werden Secrets maskiert, und die übermittelten Daten fließen nicht in das Modelltraining. Das adressiert genau die Risiken aus LLM02:2025 Sensitive Information Disclosure: Datenbereinigung vor der Verarbeitung und ein Anbieter, bei dem Eingaben nicht zu Trainingsmaterial werden.

Für Organisationen, die selbst LLM-Funktionen ausliefern, lässt sich der Ansatz verallgemeinern:

  1. Den LLM-Endpunkt wie jede API absichern: Authentifizierung, Objekt- und Funktionsebenen-Autorisierung, Rate Limiting, saubere Fehlerbehandlung.
  2. Sensible Daten vor der Modellanfrage bereinigen oder maskieren und nur das Nötigste an den Anbieter geben.
  3. Einen EU-Anbieter ohne Training auf Kundendaten wählen, wenn Datenstandort und Rechtsraum relevant sind - das ordnet sich in den Rahmen aus DORA, NIS2 und DSGVO ein.
  4. Tools restriktiv schneiden, im Nutzerkontext ausführen und wirksame Aktionen menschlich freigeben (Excessive Agency).
  5. Das Endpunkt-Inventar pflegen, gerade wenn KI-Codegeneratoren im Build mitarbeiten.

Orientierung bieten dabei das OWASP Gen AI Security Project, das NIST AI 600-1 (Generative AI Profile zum AI Risk Management Framework, Juli 2024) sowie die BSI-Publikation zu generativen KI-Modellen, die Risiken und Gegenmaßnahmen für Unternehmen und Behörden zusammenfasst.

Quellen

Weiterlesen
API5Broken Function Level Authorization Angriffe & RisikenImproper Inventory Management SouveränitätSouveränität im Sicherheitskontext