KI-Gateway: die Sicherheitsschicht vor dem Sprachmodell

Ein KI-System wird sicher, ohne langsam oder dumm zu werden, wenn die Prüfung nicht im Modell stattfindet, sondern in einer eigenen Schicht davor. Ein KI-Gateway, auch AI Firewall oder LLM Proxy genannt, nimmt jede Anfrage entgegen, prüft Eingabe, Ausgabe und Werkzeugaufrufe gegen Regeln und protokolliert sie. Das Modell selbst bleibt unverändert und behält seine Fähigkeiten.

Klug, schnell, sicher: meist nur zwei davon

Wer ein KI-System baut, will ein fähiges Modell, kurze Antwortzeiten und eine belastbare Absicherung zugleich. In der Praxis zieht jede dieser Eigenschaften an den anderen. Fähigkeit braucht Kontext, Werkzeuge und Rechte: Ein Assistent, der Angebote vorbereiten soll, muss Preislisten, Kundendaten und die Dokumentenablage lesen können. Geschwindigkeit lässt wenig Zeit für Prüfung, denn jede Kontrolle zwischen Anfrage und Antwort verlängert die Wartezeit. Absicherung bringt Prüfung, Filter, eine Sandbox, ein Protokoll und an kritischen Stellen eine menschliche Freigabe, und jedes davon bremst.

Oft genügen zwei der drei Eigenschaften. Ein Recherche-Agent, der über Nacht Marktberichte zusammenfasst, darf langsam sein, solange er gründlich und abgesichert arbeitet. Eine Steuerung für Licht und Heizung im Büro braucht kein großes Modell, wohl aber eine schnelle Reaktion und Schutz vor fremdem Zugriff. Ein Prototyp, der auf öffentlichen Daten ausprobiert, ob eine Idee trägt, kommt mit weniger Prüfung aus, weil dort nichts Schützenswertes liegt. Schwierig wird es bei Systemen, die alles zugleich brauchen, etwa bei einem Agenten mit Zugriff auf ERP und Postfach, der im Tagesgeschäft rasch antworten soll.

Jede Fähigkeit vergrößert die Angriffsfläche

Mit jeder Fähigkeit, die ein Modell bekommt, entsteht ein neuer Weg, auf dem ein Angreifer es erreicht oder über das Modell etwas auslöst.

Gedächtnis: Was in einer Sitzung gespeichert wird, kann in einer späteren wieder auftauchen, auch eine untergeschobene Anweisung.
Internetzugang: Jede abgerufene Webseite hat ein Fremder geschrieben. Steht darin eine versteckte Anweisung, ist das eine Prompt Injection (OWASP LLM01) über einen Umweg.
Werkzeuge: Ein Werkzeug macht aus einer Textantwort eine Handlung, etwa eine versendete E-Mail oder einen geänderten Datensatz.
Datenbanken: Das Modell liest Daten, die der Fragende möglicherweise nicht sehen darf, und gibt sie in der Antwort weiter.
APIs: Was das Modell an eine Schnittstelle übergibt, landet in nachgelagerten Systemen. Wird es dort ungeprüft verarbeitet, ist das Improper Output Handling (OWASP LLM05).
Sensoren und Aktoren: In der Produktion kommen Eingaben aus Maschinen, und Ausgaben steuern Anlagen. Ein Fehler wirkt dann physisch.

Eine Angriffsfläche teilen alle Fähigkeiten: die Kosten. Jede Anfrage verbraucht Rechenzeit, und wer ein System mit Anfragen flutet oder in Schleifen schickt, verursacht Last und Rechnungen. OWASP führt das als Unbounded Consumption (LLM10).

Warum die Prüfung vor das Modell gehört

Ein Sprachmodell kann seine eigene Eingabe nicht zuverlässig bewerten. Es verarbeitet Anweisung und Inhalt im selben Strom aus Text, und eine geschickt formulierte Anweisung in einem Dokument sieht für das Modell aus wie eine legitime Aufgabe. Eine Regel im System Prompt („Gib niemals Gehaltsdaten aus“) ist deshalb eine Bitte an das Modell. Eine Regel im Gateway ist eine Durchsetzung: Sie greift unabhängig davon, ob sich das Modell hat überreden lassen.

Auf der Seite zu Excessive Agency (OWASP LLM06) steht derselbe Gedanke für Berechtigungen: Verbindlich wird eine Regel erst dort, wo die Handlung ausgeführt wird. Das Gateway ist die erste Stelle, an der eine Regel durchgesetzt statt erbeten wird; verbindlich für die Berechtigung bleibt das Zielsystem. Zusammen fangen beide ab, was das Modell durchlässt.

Security Proxy, AI Firewall, LLM Proxy und KI-Gateway beschreiben dasselbe Muster: eine Schicht außerhalb des Modells, durch die jede Anfrage und jede Antwort läuft. Der Name hängt meist am Hersteller oder am Blickwinkel, die Aufgabe ist dieselbe.

Was ein Gateway prüft

Fünf Bereiche deckt ein Gateway ab, und jeder lässt sich je Anwendung eigens einstellen.

Eingaben. Das Gateway sucht in Anfragen und abgerufenen Inhalten nach bekannten Injection-Mustern, nach fremden URLs und nach Dateianhängen, die nicht zur Anwendung passen. Auffälliges wird blockiert oder markiert, bevor das Modell es liest, etwa bei Zero-Click-Angriffen auf Agenten.
Ausgaben. Antworten werden auf Muster sensibler Daten geprüft, etwa Kontonummern, Sozialversicherungsnummern oder Zugangsdaten. Dazu kommen Format und Links, denn eine Antwort mit einer unbekannten Adresse kann ein Kanal für abfließende Daten sein.
Werkzeugrechte. Jede Anwendung hat eine Allowlist der Werkzeuge, die sie aufrufen darf, und jeder Parameter einen erlaubten Wertebereich. Für unumkehrbare Aktionen wie Zahlungen, Löschungen oder Nachrichten nach außen verlangt das Gateway die Freigabe durch einen Menschen.
Protokollierung. Festgehalten werden Anfrage, Modellantwort und jeder Werkzeugaufruf mit seinen Parametern. Nach einem Vorfall lässt sich damit nachvollziehen, welche Eingabe welche Handlung ausgelöst hat.
Kostenlimits. Das Gateway begrenzt die Anfragen je Nutzer und Zeitraum und setzt ein Tokenbudget je Anwendung. Wird es überschritten, bricht die Verarbeitung ab, statt weiterzulaufen.

So bauen wir das vor lokalen Modellen

In unseren Projekten mit lokaler KI läuft das Modell auf eigener Hardware, bereitgestellt über Ollama oder vLLM. Davor sitzt eine Oberfläche wie Open WebUI oder ein eigener Assistent, angebunden an die Dokumentenablage und an Fachsysteme. Das Gateway setzen wir zwischen Oberfläche beziehungsweise Agent und Modell. Jede Anfrage passiert es auf dem Hinweg, jede Antwort und jeder Werkzeugaufruf auf dem Rückweg.

Jede Anwendung bekommt eine eigene Regeldatei. Ein Assistent für die Dokumentensuche braucht andere Regeln als ein Agent, der Bestellungen vorbereitet. In derselben Datei steht die Allowlist der Werkzeuge, sodass jede Änderung an den Rechten nachvollziehbar bleibt. Das Protokoll schreibt das Gateway in das Logsystem, das beim Kunden ohnehin läuft, damit die IT es mit ihren gewohnten Werkzeugen auswertet.

Die Rechteprüfung selbst bleibt im Zielsystem, also im ERP, in der Ablage oder im Mailserver.

Wann welche Kombination genügt

Nicht jedes System braucht jede Prüfung. Entscheidend ist, was es darf:

Was das System darf	Welche Prüfung nötig ist	Was das Gateway dafür tut
Interner Assistent auf freigegebenen Dokumenten: liest Dokumente und antwortet im Chat, löst nichts aus	Ausgaben auf sensible Daten, Berechtigungen der Ablage	prüft Ausgaben und protokolliert Anfragen; die Rechte prüft die Ablage
Chatbot auf der Webseite: beantwortet Fragen von Besuchern auf Basis veröffentlichter Inhalte	Eingaben auf Injection, Links in Antworten, Kosten	filtert Eingaben, prüft Links und begrenzt Anfragen je Besucher
Agent mit Schreibzugriff auf ERP oder E-Mail: legt Datensätze an und versendet Nachrichten	alle fünf Bereiche, Freigabe vor unumkehrbaren Aktionen	Allowlist mit Wertebereichen, Freigabeschritt, vollständiges Protokoll
Prototyp auf öffentlichen Daten: testet eine Idee ohne vertrauliche Daten und ohne Werkzeuge	Kosten, Protokoll	begrenzt das Tokenbudget; strengere Regeln folgen vor dem Produktivbetrieb

Fazit

Das Trilemma lässt sich nicht auflösen, aber verschieben. Wer die Prüfung aus dem Modell herausnimmt und in ein Gateway legt, behält das fähige Modell und gewinnt eine Stelle, an der Regeln tatsächlich gelten. Welche Regeln dort stehen, hängt davon ab, was das System darf, und nicht davon, wie gut das Modell ist. Den Überblick über die übrigen Risiken eines KI-Systems gibt unsere Seite zur KI-Sicherheit.

Weiterführend

What Is the AI Security Trilemma? Smart, Fast, or Secure AI?, IBM Technology, 18.8.2026
Zero-Click Attacks: AI Agents and the Next Cybersecurity Challenge, IBM Technology, 30.9.2025
Lokale KI-Infrastruktur: Modelle auf eigener Hardware, Aufbau und Betrieb
KI-Sicherheit im Überblick: alle Angriffswege nach OWASP und der Sicherheitscheck

Häufige Fragen

Ist ein KI-Gateway dasselbe wie eine Web Application Firewall?

Nein. Eine Web Application Firewall (WAF) prüft HTTP-Anfragen auf bekannte Angriffsmuster gegen Webanwendungen, etwa SQL-Injection in einem Formularfeld. Ein KI-Gateway liest den Inhalt von Anfrage und Antwort in natürlicher Sprache und kennt die Werkzeuge, die das Modell aufrufen darf. Eine Anweisung, die in einem hochgeladenen Lebenslauf versteckt ist, sieht für eine WAF aus wie gewöhnlicher Text. Beide haben ihren Platz: Die WAF schützt die Webanwendung, das Gateway das Modell und seine Werkzeuge.

Macht das Gateway die Antworten spürbar langsamer?

Jede Prüfung kostet Zeit, das lässt sich nicht wegdiskutieren. Für einen Chat ist das meist unerheblich, weil Nutzer dort ohnehin auf eine ausformulierte Antwort warten. Bei Echtzeitanwendungen, etwa einer Sprachsteuerung, entscheidet die Auswahl der Prüfungen: Schnelle Musterprüfungen laufen bei jeder Anfrage, aufwendigere nur dort, wo ein Werkzeug tatsächlich etwas auslösen würde. Welche Prüfung wohin gehört, legt die Regeldatei der jeweiligen Anwendung fest.

Brauchen wir ein Gateway, wenn wir nur ChatGPT oder Copilot nutzen?

Sobald eigene Daten oder Werkzeuge an ein Modell angebunden sind, ja, zumindest für die Anbindungen, die Sie selbst bauen, etwa einen Agenten, der über eine Schnittstelle Aufträge anlegt. Nutzen Mitarbeitende nur einen freigegebenen Chatzugang ohne Anbindung, ist ein Gateway nicht das passende Werkzeug. Dann zählen eine klare Richtlinie, welche Daten hineindürfen, und ein freigegebener Zugang statt privater Konten. Wie man das einführt, beschreibt unsere Seite zu Schatten-KI.

Ersetzt das Gateway die Rechteprüfung im ERP?

Nein. Das Gateway prüft, ob ein Werkzeugaufruf überhaupt erlaubt ist und ob seine Parameter im zulässigen Bereich liegen. Ob der Mensch, in dessen Auftrag der Agent handelt, einen bestimmten Datensatz sehen oder ändern darf, weiß nur das ERP. Fällt diese Prüfung weg, genügt ein einziger Fehler in der Regeldatei, und der Agent darf mehr als sein Auftraggeber. Wie Rechte für Agenten zugeschnitten werden, steht auf der Seite zu Excessive Agency.

Gibt es fertige Gateways?

Ja, als Open-Source-Projekte und als kommerzielle Produkte, teils als eigener Dienst, teils als Funktion einer API-Plattform. Sie unterscheiden sich darin, welche Prüfbereiche sie abdecken und wie fein sich Regeln je Anwendung einstellen lassen. Für die Auswahl zählt weniger der Name als die Frage, ob sich Ihre Werkzeuge und Ihr Logsystem anbinden lassen. Die Regeln für die eigene Anwendung schreibt Ihnen auch ein fertiges Gateway nicht, diese Arbeit bleibt im Haus oder beim Dienstleister.