Sicheres LLM-Gateway: Was es braucht, um KI-Traffic zu schuetzen

Ihr LLM-Traffic ist ein unueberwachter Egress-Kanal

Die meisten Unternehmen haben das letzte Jahrzehnt damit verbracht, Datenabfluesse abzuriegeln — DLP auf E-Mail, Zugriffskontrollen auf Datenbanken, Secret-Scanning in der CI. Dann kamen KI-Features, und ploetzlich streamt jeder Entwickler, jedes Support-Tool und jeder autonome Agent Freitext an Dritt-APIs. Namen, Vertraege, Zugangstokens, medizinische Details: Was in einem Prompt auftauchen kann, verlaesst Ihre Infrastruktur.

Ein sicheres LLM-Gateway schliesst diesen Kanal, indem es einen Sicherheits-Checkpoint direkt in den Anfragepfad setzt. Dieser Beitrag behandelt das Bedrohungsmodell, die Faehigkeiten, die "sicher" tatsaechlich ausmachen, wo ein Gateway gegenueber Guardrail-Bibliotheken und DLP steht — und was Sie pruefen sollten, bevor Sie einem vertrauen.

Das Bedrohungsmodell fuer LLM-Traffic

LLM-Gateway-Sicherheit ist nicht ein Problem — es sind fuenf verschiedene:

1. +PII-Abfluss. Nutzerdaten fliessen absichtlich in Prompts: Support-Tickets, CRM-Eintraege, Dokumente zur Zusammenfassung. Unter DSGVO und CCPA ist das Senden an einen externen Anbieter eine Datenverarbeitung, die Sie kontrollieren und nachweisen muessen. Agenten verschaerfen das — ein Agent mit RAG-Zugriff leakt, was immer er abruft.
2. +Credential-Leaks. Entwickler kopieren Stack Traces und Config-Dateien in Coding-Assistenten; RAG-Pipelines indexieren Repos mit Keys. Ein API-Key in einem Prompt ist ein an Dritte uebergebenes Credential — und Prompts werden protokolliert, also bleibt er bestehen.
3. +Prompt Injection. Nicht vertrauenswuerdige Inhalte — Webseiten, E-Mails, abgerufene Dokumente — tragen Anweisungen, die das Verhalten Ihres Modells kapern, Kontext exfiltrieren oder Tool-Aufrufe steuern.
4. +Tool-Call-Missbrauch. Agenten koennen Aktionen ausfuehren. Ein kompromittierter oder verwirrter Agent, der delete_records oder send_email aufruft, ist ein Sicherheitsvorfall mit API-Rechnung. Zu beschraenken, welche Tools ein Modell aufrufen darf, pro Route, ist Zugriffskontrolle.
5. +Schatten-KI. Der Traffic, von dem Sie nichts wissen: Teams, die Anbieter direkt anbinden, Tools mit eingebauten LLM-Aufrufen, MCP-Server, die sich mit wer-weiss-was verbinden. Man kann nicht redaktieren, was man nicht sieht.

Beachten Sie die Gemeinsamkeit: Alle fuenf leben im Anfragepfad. Genau deshalb gehoert das Sicherheits-Control auch dorthin.

Warum das Gateway der richtige Durchsetzungspunkt ist

Man koennte jede Bedrohung im Anwendungscode adressieren — vor jedem LLM-Aufruf eine Redaktions-Bibliothek aufrufen, in jedem Service nach Secrets scannen, in jeder Codebasis Injection-Heuristiken pflegen. Teams versuchen das. Es scheitert aus einem strukturellen Grund: Integration pro Aufruf bedeutet, dass jeder Codepfad ein potenzieller Bypass ist. Der neue Microservice, das Dritt-Framework, der Agent, den jemand an einem Freitag angebunden hat — jeder davon laeuft ungeschuetzt, bis sich jemand erinnert.

Ein Gateway kehrt den Default um. Der Traffic laeuft durch die Sicherheitsschicht, weil die Base-URL dorthin zeigt; eine Anfrage kann das Scanning so wenig ueberspringen wie DNS. Abdeckung wird eine Netzwerkeigenschaft statt ein Code-Review-Ergebnis. Egress-Firewall-Regeln koennen das Gateway dann zur einzigen Route zu den Anbieter-Endpunkten machen — aus "bitte ans Bereinigen denken" wird "unbereinigter Traffic ist unmoeglich".

Das ist dasselbe Argument wie der allgemeine Fall fuer ein AI Gateway, nur mit hoeherem Einsatz: Kostenerfassung auf einer Route zu vergessen kostet Daten; Redaktion auf einer Route zu vergessen ist ein meldepflichtiger Vorfall.

Die sechs Faehigkeiten, die ein Gateway "sicher" machen

Jeder Proxy kann Anfragen weiterleiten. Diese Faehigkeiten rechtfertigen das Wort sicher — behandeln Sie sie als Checkliste.

1. PII-Erkennung und -Redaktion — reversibel, nicht destruktiv

Grundausstattung ist die Erkennung von Namen, E-Mails, Telefonnummern, Adressen und IDs in Prompts — mit schnellem Pattern-Matching fuer strukturierte PII und ML-Modellen fuer unstrukturierte PII (ein Name in einem Support-Ticket passt auf keine Regex; siehe unseren Modellvergleich).

Der Unterschied liegt darin, was nach der Erkennung passiert. Destruktive Redaktion schuetzt Daten, bricht aber das Produkt — das Modell antwortet ueber [REDACTED], die Personalisierung stirbt. Ein sicheres Gateway macht reversibles Mask-and-Restore: Sarah Chen wird auf dem Hinweg zu [PERSON_a3f2], das Modell arbeitet mit dem Platzhalter, und der Originalwert kehrt in der Antwort zurueck. Der Anbieter sieht die Daten nie; der Nutzer merkt nichts.

Fragen Sie auch, wo die Erkennungsmodelle laufen. Ein "Privacy"-Gateway, das Ihre Prompts an eine Dritt-Erkennungs-API schickt, hat gerade einen zweiten Egress-Kanal geschaffen.

2. Secret- und Credential-Scanning

PII-Modelle erkennen kein sk-proj-... und keinen Postgres-Verbindungsstring — Credential-Erkennung ist eine eigene Pattern-Disziplin (API-Keys, Bearer-Tokens, Cloud-Credentials, private Schluessel). Die meisten PII-fokussierten Tools lassen sie komplett aus — genau falsch herum fuer entwicklerlastigen Traffic wie Coding-Assistenten, wo geleakte Credentials der schwerwiegendere Vorfall sind.

3. Prompt-Injection-Erkennung

Eingehendes Scanning schuetzt Ihre Daten; Injection-Erkennung schuetzt das Verhalten Ihres Modells vor adversarialen Anweisungen in nicht vertrauenswuerdigen Inhalten. Kein Detektor faengt alles — betrachten Sie dies als eine Schicht, gepaart mit Tool-Beschraenkungen fuer Defense in Depth.

4. Tool-Call-Beschraenkungen

Fuer Agenten-Traffic sollte das Gateway durchsetzen, welche Tools ein Modell auf welcher Route aufrufen darf — eine Allowlist am Engpass, keine Konvention im Agenten-Framework. Injection-Erkennung senkt die Wahrscheinlichkeit einer Kaperung; Tool-Beschraenkungen begrenzen den Schaden, wenn eine gelingt.

5. Audit-Trail

Compliance heisst nachweisen, was passiert ist — nicht behaupten. Jede Anfrage braucht einen Eintrag: was erkannt wurde, was redaktiert wurde, welche Richtlinie ausgeloest hat, wann, fuer wen — mit Payload-Logging, das nicht selbst zur PII-Haftung wird. Wenn der Auditor fragt, wie Kundendaten in KI-Features geschuetzt sind, ist die Antwort eine Abfrage, kein Dokumentations-Notfall.

6. Datenresidenz und Aufbewahrungskontrolle

Das Gateway sieht alles, also muss es selbst vertrauenswuerdig sein: wo es laeuft (EU-Hosting, wenn die DSGVO gilt), was es speichert (Payload-Logging sollte optional sein) und ob es einen Zero-Retention-Modus fuer regulierte Workloads gibt.

Gateway vs. Guardrail-Bibliothek vs. Enterprise-DLP

Drei Tool-Kategorien beanspruchen LLM-Sicherheit, und sie sind nicht austauschbar. Eine Guardrail-Bibliothek (LLM Guard, Guardrails AI) bietet tiefes, anpassbares Scanning — aber es ist Code, den Ihr Team einbettet, hostet und auf jedem Pfad aufrufen muss. Enterprise-DLP (Nightfall, Strac) deckt E-Mail, Slack und Storage breit ab, behandelt LLM-Traffic aber als Nebensache: keine reversible Redaktion, kein Verstaendnis fuer Streaming-Wire-Formate, kein Tool-Call-Konzept. Das Gateway besetzt die Mitte: weniger Scanner-Breite als eine Guardrail-Bibliothek, deutlich tieferes LLM-Verstaendnis als DLP — und als einziges der drei setzt es auf Netzwerkebene durch.

Konkrete Tools aus allen drei Kategorien vergleichen wir im LLM-Security-Tools-Vergleich.

Ein sicheres LLM-Gateway evaluieren: die Fragen, die zaehlen

• +Ist die Redaktion reversibel, oder bricht der Schutz die Personalisierung?
• +Erkennt es Secrets und Credentials, oder nur klassische PII?
• +Wo laufen die Erkennungsmodelle — in der Infrastruktur des Gateways oder ueber einen Dritt-API-Aufruf?
• +Kann es Tool-Call-Beschraenkungen fuer Agenten-Traffic durchsetzen?
• +Erfuellt der Audit-Trail Ihr Compliance-Framework — pro Anfrage, exportierbar, mit protokollierten Redaktionsentscheidungen?
• +Was passiert, wenn das Gateway ausfaellt — fail open (Verfuegbarkeit, stille Leaks) oder fail closed (Schutz, Ausfall)? Ist das Verhalten pro Route konfigurierbar?
• +Wie hoch ist die zusaetzliche Latenz mit vollem Scanning, bei p99, gemessen auf Ihren Payload-Groessen?
• +Koennen Sie den Quellcode lesen und selbst hosten, wenn Ihre Anforderungen strenger werden?

Wie Grepture hilft

Grepture ist ein AI Gateway, das als Sicherheitsschicht begann und nach aussen wuchs — das zeigt sich in den Defaults. Jede Anfrage durch den Proxy wird mit 50+ Regex-Mustern plus lokal gehosteten KI-Modellen gescannt (Ihre Prompts verlassen Greptures Infrastruktur fuer die Erkennung nie), mit nativem Mask-and-Restore, Secret-Scanning ueber 30+ Credential-Typen, Prompt-Injection-Erkennung, Tool-Beschraenkungen pro Route und einem Audit-Trail pro Anfrage. Der verwaltete Dienst ist EU-gehostet in Frankfurt mit Zero-Retention-Modus; der Proxy-Kern ist Open Source und selbst hostbar.

Es ist ausserdem ein vollstaendiges Gateway — Fallback-Routing, Kostenerfassung, Tracing, Prompt-Management — die Sicherheitsschicht kommt also nicht als weiteres Einzeltool daher. Der kostenlose Tarif deckt 1.000 Anfragen/Monat ab — genug, um zu sehen, was wirklich in Ihrem LLM-Traffic steckt. Die meisten Teams sind ueberrascht.

Wichtigste Erkenntnisse

• +LLM-Traffic ist ein Egress-Kanal mit fuenf verschiedenen Risiken: PII-Abfluss, Credential-Leaks, Prompt Injection, Tool-Call-Missbrauch und Schatten-KI — alle leben im Anfragepfad.
• +Das Gateway ist der richtige Durchsetzungspunkt, weil Abdeckung eine Netzwerkeigenschaft wird: keine Integration pro Aufruf, kein vergessener Codepfad, kein ungeschuetzter Agent.
• +"Sicher" heisst sechs Faehigkeiten: reversible PII-Redaktion, Secret-Scanning, Injection-Erkennung, Tool-Beschraenkungen, Audit-Trail und Residenz-/Aufbewahrungskontrolle. Fehlende sind Bypass-Routen.
• +Guardrail-Bibliotheken und DLP ergaenzen ein Gateway, ersetzen es aber nicht — das eine ist eingebetteter Code, den man aufrufen muss, das andere versteht LLM-Traffic kaum.
• +Evaluieren Sie nach Fehlerverhalten, Erkennungs-Lokalitaet und Reversibilitaet — die Fragen, die Anbieter nicht auf Pricing-Seiten schreiben.