Warum Firewall, Proxy und CASB lokale KI-Tools nicht sehen
Kurz gesagt
- Firewall, Proxy und CASB arbeiten am Netzwerkrand. Sie sehen Ziele, Domains und Datenmengen, keine Inhalte und keine Prozesse.
- Vier Dinge bleiben für alle drei unsichtbar: lokale Modelle, KI-Funktionen in Browser-Extensions und Desktop-Apps, der Inhalt verschlüsselter API-Aufrufe und Aktionen von Agents auf dem Gerät.
- Die Lücke lässt sich nicht mit mehr Regeln am Gateway schließen. Sie lässt sich nur auf dem Gerät schließen.
Was jede Kontrolle tatsächlich sieht
| Kontrolle | Sieht | Sieht nicht |
|---|---|---|
| Netzwerk-Firewall | Ziel-IP, Port, Datenvolumen, bei DPI die Domain (SNI) | Inhalt des Prompts, den Prozess, lokale Modelle, Agent-Aktionen |
| Web-Proxy mit TLS-Inspektion | URL und Inhalt für Traffic ohne Certificate Pinning | lokale Modelle, Geräte außerhalb des Proxys, gestreamte Antworten während der Übertragung |
| CASB | genutzte SaaS-Dienste, Konten, Uploads bei API-Anbindung | Prompt-Inhalte, Extensions, lokale Modelle, Terminal-Agents |
| EDR | Prozesse, Dateizugriffe, bekannte Malware-Muster | ob ein Prozess KI-Traffic erzeugt und was darin steht |
| Endpoint-KI-Erkennung | Prozess, Ziel und Inhalt vor der Verschlüsselung, lokale Modelle, Agent-Tool-Calls | nichts außerhalb des Geräts |
Jede Zeile hat ihren Zweck. Keine der ersten vier wurde gebaut, um zu beantworten, ob ein Mitarbeiter gerade eine Kundenliste in ein Sprachmodell einfügt.
Blinder Fleck 1: Lokale Modelle erzeugen keinen Traffic
Ollama, LM Studio, in die IDE eingebaute Modelle und lokal laufende Coding-Agents verarbeiten Prompts auf demselben Rechner. Es gibt keinen Netzwerkverkehr nach draußen, den eine Firewall sehen könnte. Der einzige sichtbare Effekt am Gateway ist der Modell-Download am Anfang, und der sieht aus wie jeder andere große Download.
Für die Datensicherheit ist das nur scheinbar unkritisch. Ein lokales Modell kann über Agents und MCP-Server auf Dateien und Systeme zugreifen, und die Ergebnisse gehen anschließend doch nach draußen, etwa in ein Ticket oder ein Repository. Die Analyse dessen, was das Modell zu sehen bekommt, kann nur auf dem Gerät stattfinden.
Blinder Fleck 2: KI steckt in Extensions und Apps, nicht in Domains
Die Domain-Liste war der erste Reflex vieler Teams: chatgpt.com, claude.ai, gemini.google.com sperren oder protokollieren. Das erfasst den Browser-Tab, aber nicht die Browser-Extension, die Seiteninhalte an einen Zusammenfassungsdienst schickt, nicht den Copilot in Office, nicht den Assistenten in der IDE, und nicht die KI-Funktion, die ein SaaS-Produkt im Hintergrund über eine eigene API aufruft.
Diese Aufrufe gehen an Domains, die auf keiner Liste stehen, oder an dieselben Domains, über die auch der freigegebene Dienst läuft. Am Netzwerkrand sind sie von normalem Anwendungsverkehr nicht zu unterscheiden.
Blinder Fleck 3: Verschlüsselung versteckt den Inhalt
KI-API-Aufrufe sind TLS-verschlüsselt. Eine Firewall sieht Bytes und ein Ziel. Ein Proxy mit TLS-Inspektion sieht den Inhalt, aber mit drei Einschränkungen:
- Apps mit Certificate Pinning akzeptieren das Proxy-Zertifikat nicht.
- Geräte außerhalb des Firmennetzes müssen den Proxy erzwungen nutzen, sonst läuft der Traffic daran vorbei.
- Antworten kommen als Server-Sent Events oder WebSocket-Frames. Wer den Stream erst am Ende prüft, hat die Daten schon durchgelassen.
Und selbst wenn der Proxy den Prompt liest, kann er nur zwei Dinge tun: durchlassen oder blockieren. Die Kundennummer im Prompt durch einen Platzhalter ersetzen und den Rest weiterschicken kann er nicht.
Blinder Fleck 4: Agents handeln auf dem Gerät
Ein Coding-Agent liest eine Konfigurationsdatei, ruft eine interne API auf, schreibt ein Ergebnis in ein Repository. Ein MCP-Server gibt einem Assistenten Zugriff auf Mail, Datenbank oder Shell. Diese Aktionen passieren als Prozess auf dem Gerät. Am Gateway erscheint höchstens der letzte Schritt, ein API-Aufruf, ohne Zusammenhang zu den vorherigen.
Die Frage "Liest dieser Agent gerade eine .env-Datei und schickt den Inhalt nach draußen?" lässt sich nur beantworten, wenn man beide Schritte sieht: die Quelle und den Sink. Das geht nur dort, wo der Agent läuft.
Was auf dem Gerät anders ist
Eine Komponente auf dem Endpoint sitzt im lokalen Netzwerkpfad, vor der Verschlüsselung. Sie sieht den Prozess, der den Traffic erzeugt, das Ziel und den Inhalt. Patronus Protect erkennt KI-Traffic dort am Verhalten, nicht an einer Domain-Liste: Muster in Anfragen und Antworten, Streaming-Signaturen, Prozess-Herkunft. Neue Tools werden erkannt, bevor jemand ihre Domain kennt. Wie das technisch funktioniert, beschreibt der Beitrag zur Erkennung über WebSockets, SSE und gRPC.
Weil die Prüfung vor der Verschlüsselung passiert, kann die Reaktion mehr als blockieren: schwärzen, protokollieren, zur Freigabe vorlegen. Und weil sie auf dem Gerät passiert, gilt sie auch im Homeoffice, ohne erzwungenen Proxy.
Was Firewall, Proxy und CASB weiter leisten
Nichts davon wird überflüssig. Die Firewall schützt das Netz, der Proxy setzt Web-Richtlinien durch, der CASB inventarisiert SaaS. Die Endpoint-Erkennung ergänzt genau die Ebene, für die diese Werkzeuge nicht gebaut wurden: den Inhalt einer KI-Interaktion und den Prozess, der sie auslöst.
Wenn du prüfen willst, was auf euren Geräten tatsächlich läuft: Patronus Monitor zeigt es kostenlos, ohne in den Traffic einzugreifen. Mehr zur Vorgehensweise steht auf der Seite zur Shadow-AI-Erkennung.
Quellen und Einordnung
- Die Beschreibung der Kontrollen folgt den üblichen Produktkategorien; herstellerspezifische Zusatzfunktionen wurden nicht bewertet.
- Zu Agents und MCP: MCP, die Angriffsfläche, die niemand absichert.
- Zu den blinden Flecken des bestehenden Stacks: Shadow AI: blinde Flecken im Security-Stack.
- Stand: 7. September 2026.
FAQ
Häufige Fragen
Warum erkennt unsere Firewall keine KI-Tools, die lokal auf Laptops laufen?
Weil eine Netzwerk-Firewall nur Traffic sieht, der den Laptop verlässt, und auch den nur als verschlüsseltes Ziel. Ein lokales Modell wie Ollama erzeugt keinen ausgehenden Traffic. Eine KI-Browser-Extension sieht aus wie normales HTTPS. Die Erkennung muss auf dem Gerät passieren, wo Prozess, Inhalt und Ziel noch sichtbar sind.
Reicht ein CASB, um Shadow AI zu finden?
Ein CASB findet SaaS-Dienste, die über den Proxy oder per API-Anbindung sichtbar sind. Er sieht, dass chatgpt.com aufgerufen wurde, aber nicht, was eingegeben wurde, und er sieht weder lokale Modelle noch Extensions noch Agents auf dem Gerät.
Hilft TLS-Inspektion am Proxy?
Für Cloud-Tools ohne Certificate Pinning ja, der Inhalt wird lesbar. Sie hilft nicht bei lokalen Modellen, nicht bei Geräten außerhalb des Firmennetzes ohne erzwungenen Proxy und nicht bei Streams, die während der Übertragung geprüft werden müssten. Und sie kann nur blockieren, nicht schwärzen.
Gibt es ein Werkzeug, das KI-Nutzung erkennt, bevor sie das Netzwerk erreicht?
Ja. Eine Komponente auf dem Endpoint, wie Patronus Protect, sitzt im lokalen Netzwerkpfad und klassifiziert KI-Traffic vor der Verschlüsselung und vor dem Gateway. Sie sieht Browser-Tools, Desktop-Apps, IDE-Assistenten, lokale Modelle und Agents, ohne Integration pro Tool.