Warum euer Security-Stack Shadow AI nicht sieht

Was Shadow AI genau ist

Shadow AI ist jede Nutzung eines AI-Tools, eines Modells oder eines Agenten in einer Organisation, die für Security und IT nicht sichtbar ist. Die Kategorie umfasst mehr als „Mitarbeitende kopieren Dinge in ChatGPT". Dazu gehören im Browser eingebettete Assistenten (Notion AI, Gemini in Workspace, Copilot in Edge), IDE-Plugins (Cursor, Continue, GitHub Copilot Chat), native Desktop-Apps (Claude Desktop, ChatGPT Desktop), agentische Werkzeuge, die MCP-Server aufrufen und Aktionen ausführen, sowie eingebettete AI-Funktionen in SaaS, die standardmäßig aktiviert sind.

Der McKinsey Global Survey on the State of AI 2025 berichtet, dass 88 Prozent der Organisationen AI inzwischen in mindestens einer Geschäftsfunktion einsetzen, nach 78 Prozent im Jahr 2024. Diese Zahl bildet die freigegebene Nutzung ab. Der nicht freigegebene Anteil ist strukturell unsichtbar, und genau das ist das Problem.

Warum der bestehende Security-Stack blind ist

Die meisten Unternehmen verlassen sich für Traffic-Sichtbarkeit auf drei Schichten, und jede hat bei AI einen spezifischen blinden Fleck.

CASB sieht die SaaS, nicht die AI

Cloud Access Security Broker erkennen, welche SaaS-Anwendungen Mitarbeitende nutzen. Sie ordnen eine Verbindung zu api.openai.com dem Anbieter „OpenAI" zu. Was sie nicht sehen: welche Modellvariante genutzt wurde, welche Tool-Calls in der Anfrage steckten, ob MCP-Server beteiligt waren oder was tatsächlich im Prompt stand. Aus Sicht eines CASB ist „ChatGPT" eine freigegebene Cloud-Anwendung. Aus Sicht der Sicherheit ist ChatGPT mit Websuche plus drei MCP-Servern plus Datei-Upload ein völlig anderes Bedrohungsprofil.

DLP sieht verschlüsselte Bytes, keine Prompts

Data-Loss-Prevention-Werkzeuge leben davon, Payloads zu inspizieren. AI-Traffic ist HTTPS. Ohne TLS-terminierenden Proxy sieht DLP nichts. Mit einem solchen Proxy kann DLP Prompt-Inhalte lesen, aber erst, nachdem jeder Prompt durch einen zentralen Prüfpunkt geleitet wurde, was Latenz erzeugt, nutzerbezogene Zuordnung erfordert und ein neues Exfiltrationsziel schafft. Die meisten Unternehmen gehen diesen Schritt aus rechtlichen und betrieblichen Gründen nicht.

Firewalls sehen Ziele, keine Absicht

Netzwerk-Firewalls können api.openai.com oder generativelanguage.googleapis.com blockieren. Die Entscheidung ist binär: erlauben oder sperren, auf Domain-Ebene. Es gibt keinen eingebauten Mechanismus, um ChatGPT für den Kundensupport zu erlauben und für die Rechtsabteilung zu sperren, oder OpenAI für Chat zu erlauben und dessen Websuche zu blockieren. Domain-Sperren versagen außerdem, sobald AI auf eine eigene Subdomain oder einen selbst gehosteten Endpunkt im Firmennetz umzieht.

Browser-Erweiterungen sehen einen Browser

AI-Security-Erweiterungen im Browser (LayerX und ähnliche) überwachen, was in dem Browser passiert, in dem sie installiert sind. Alles in nativen Apps, IDE-Plugins oder jedem weiteren Browser ohne die Erweiterung entgeht ihnen. In einem typischen Engineering-Team ist das der Großteil der AI-Oberfläche.

Die Folge: Das moderne AI-Traffic-Profil rutscht durch jede Schicht. Der CASB weiß, dass es OpenAI-Traffic gibt. Das DLP kann ihn nicht lesen. Die Firewall soll auf der falschen Granularität entscheiden. Die Browser-Erweiterung deckt eine von drei oder vier AI-Oberflächen ab.

Die Shadow-AI-Angriffsfläche 2026

Fünf Kategorien unbeobachteten AI-Traffics, die heute außerhalb des typischen Security-Stacks liegen:

1. Im Browser eingebettete Assistenten

Jeder große Browser bringt mindestens eine AI-Integration mit. Edge hat Copilot, Chrome hat Gemini, Arc hat einen eigenen Assistenten, Brave integriert Leo. Jeder davon liest die Seite, auf der die Nutzerin gerade ist. Keiner meldet das dem Security-Stack als „AI-Aktivität".

2. IDE-Plugins und Coding-Agents

Cursor, Continue, GitHub Copilot Chat, Codeium, Claude Code, Aider. Die meisten indizieren beim ersten Öffnen das gesamte Repository. Viele haben Tool-Call-Fähigkeiten (Dateien schreiben, Shell ausführen, Netzwerk), abgesichert nur durch schwache Bestätigungsdialoge. Die CVE-Historie für 2025 enthält CurXecute (CVE-2025-54135, CVSS 9.8) und eine RCE über Pull Requests in GitHub Copilot (CVE-2025-53773, CVSS 9.6), beide über indirekte Prompt Injection durch Repository-Inhalte.

3. Native AI-Desktop-Apps

Claude Desktop, ChatGPT Desktop, Gemini Desktop, dazu ein langer Schwanz anbieterspezifischer Clients. Sie laufen außerhalb des Browsers, browserbasierte Sicherheitswerkzeuge sehen sie also nicht. Sie authentifizieren sich unabhängig vom Unternehmens-SSO. Und sie haben oft Zugriff auf das Dateisystem.

4. MCP-Server

Das Model Context Protocol macht LLM-Clients zu Orchestratoren, die Gmail lesen, in Jira schreiben, Salesforce abfragen und Shell-Befehle ausführen können. Ein Mitarbeiter installiert einen MCP-Server in etwa neunzig Sekunden, ganz ohne IT-Freigabe. Der Wirkungsradius ist alles, worauf dieser MCP-Server Zugriff hat, und das ist oft „alles, was dieser Nutzer in jeder verbundenen SaaS lesen kann".

5. Eingebettete AI in SaaS

Notion AI, Slack AI, Linear AI, Loom AI, jedes CRM mit „AI Insights". In vielen Tenants sind sie standardmäßig aktiv und streamen Nutzerdaten an den AI-Unterauftragnehmer des SaaS-Anbieters, typischerweise OpenAI oder Anthropic. Der Datenpfad lautet: eure Daten, euer SaaS-Anbieter, dessen AI-Subprozessor, zurück. Der CASB sieht den ersten Sprung und hört dort auf zu schauen.

Was echte Shadow-AI-Sichtbarkeit voraussetzt

Ehrliche Sichtbarkeit hat drei Eigenschaften.

Sie läuft auf Anwendungsebene, auf dem Endpoint. Netzwerkkontrollen können ChatGPT-mit-Tool-X nicht von ChatGPT-mit-Tool-Y unterscheiden. SaaS-Kontrollen sehen eingebettete AI-Subprozessoren nicht. Browser-Kontrollen verpassen native Apps. Der einzige Ort, an dem jede AI-Anfrage unabhängig von Werkzeug und Oberfläche sichtbar ist, ist das Gerät, das die Anfrage stellt, kurz bevor das Betriebssystem sie ans Netzwerk übergibt.

Sie erkennt AI-Traffic, nicht nur Ziele. Eine Liste bekannter Anbieter-Domains ist das absolute Minimum und bricht in dem Moment, in dem ein selbst gehostetes Modell oder ein neuer Anbieter auftaucht. Ein echter Detektor klassifiziert Traffic anhand von Payload-Mustern als AI oder nicht, unabhängig vom Ziel.

Sie liefert die Granularität, auf die es ankommt. „War die Anfrage an OpenAI gerichtet" reicht nicht. Die relevanten Fragen lauten: Welche Anwendung hat die Anfrage gestellt, welche Werkzeuge waren darin deklariert, war ein MCP-Server beteiligt, enthielt die Antwort einen Tool-Call, den der lokale Agent dann ausgeführt hat. Alles Gröbere lässt genau die blinden Flecken bestehen, die uns hierher gebracht haben.

Genau um diese architektonische Verschiebung ist Patronus Protect gebaut: eine AI-Firewall im Netzwerkpfad auf dem Endpoint, die jede Anfrage in einstelligen Millisekunden klassifiziert, mit Sicht auf MCP-Calls, Tool-Calls und den konkret genutzten Anbieter samt Modell, über jede App, jeden Browser, jede IDE und jeden nativen Client auf der Maschine hinweg. Ohne Cloud-Routing, ohne Überwachung einzelner Personen.

Vergleich: wo der bestehende Stack versagt

AI-Oberfläche	CASB	DLP	Firewall	Browser-Ext.	On-Device-AI-Firewall
ChatGPT im Browser	✓	teilweise	✓ (alles sperren)	✓	✓
Cursor / Copilot in der IDE	teilweise	✗	teilweise	✗	✓
Claude Desktop	✗	✗	teilweise	✗	✓
Tool-Call eines MCP-Servers	✗	✗	✗	✗	✓
LLM-Tool-Call in der Anfrage	✗	✗	✗	teilweise	✓
Selbst gehostetes lokales LLM	✗	✗	✗	✗	✓
Eingebettete AI in SaaS	teilweise	✗	✗	✗	✓

Wie ein ehrliches Shadow-AI-Inventar 2026 aussieht

Ein konkreter Startpunkt, für den Sie nichts Neues kaufen müssen:

• Nehmen Sie fünf Engineering- und fünf andere Laptops. Protokollieren Sie zwei Wochen lang jede ausgehende HTTPS-Verbindung nach Ziel und Prozess. Manuell oder per Skript, beides funktioniert.

• Gleichen Sie die Ziele mit den veröffentlichten API-Endpunkten der großen AI-Anbieter ab. OpenAI, Anthropic, Google, Mistral, Cohere, Hugging Face und der lange Schwanz. Sie werden mindestens drei bis fünf Anbieter finden, von deren Nutzung niemand wusste.

• Prüfen Sie für jeden AI-aktiven Prozess, ob er Shell- oder Dateisystemzugriff hat. Cursor und Claude Desktop haben beides, standardmäßig. Dokumentieren Sie den Wirkungsradius.

• Listen Sie die auf jeder Maschine konfigurierten MCP-Server auf. Die meisten Nutzer werden es Ihnen nicht sagen können. Die Konfiguration liegt üblicherweise als JSON-Datei im Konfigurationsverzeichnis der Anwendung.

• Inventarisieren Sie Browser-Erweiterungen im Team. AI-Erweiterungen installieren sich still über die Browser-Synchronisierung des Unternehmens und werden selten auditiert.

Das Ergebnis dieser Übung ist eine Ausgangsbasis. Welches AI-Security-Werkzeug Sie am Ende auch einsetzen, es muss daran gemessen werden, ob es die Oberfläche sieht, die das Audit zutage gefördert hat.

Häufige Fragen

Ist Shadow AI nur ein Problem der Produktivitätswerkzeuge? Nein. Dasselbe Muster zeigt sich im Finanzbereich (Analysten nutzen privates ChatGPT für Tabellenarbeit mit echten Kundendaten), in der Rechtsabteilung (Entwürfe in Claude, bevor sie ins offizielle Werkzeug wandern) und im Personalwesen (ChatGPT für die Vorauswahl). Die Exposition ist alles, was die jeweilige Person lesen kann.

Löst ein TLS-terminierender Proxy das Problem? Teilweise. Ein Proxy verschafft Payload-Sichtbarkeit für den Traffic, der über ihn läuft, zum Preis von Latenz, nutzerbezogenem Logging und einem neuen hochwertigen Angriffsziel. Traffic, der den Proxy umgeht (VPN, DoH, seitlich installierte Apps), sieht er nicht, und lokale LLM-Aktivität überhaupt nicht.

Und agentische AI im Besonderen? Agentische AI vervielfacht das Problem. Ein autonomer Agent mit Werkzeugzugriff führt Aktionen aus, die der Nutzer nicht direkt freigegeben hat. Das relevante Protokoll ist nicht „was hat der Nutzer getippt", sondern „welche Werkzeuge hat der Agent aufgerufen". Tool-Call-Sichtbarkeit ist das neue Audit-Primitiv. Die meisten Security-Stacks haben es nicht.

Wie hält es ein On-Device-Ansatz mit dem Datenschutz? Richtig gebaut protokolliert er standardmäßig keine Prompt-Inhalte. Die Sichtbarkeit liegt auf der Ebene von Prozess, Ziel und Tool-Call-Metadaten. Keine Prompt-Payloads verlassen das Gerät, es sei denn, eine ausdrückliche Richtlinie verlangt es. Das ist die architektonische Haltung von Patronus Protect.

Ist das ein reines Konzernproblem? Nein. Einzelentwickler und kleine Teams sind bereits Ziel, besonders über MCP-Server und IDE-Plugins. Die Shadow-AI-Oberfläche skaliert nach unten, die Sichtbarkeitswerkzeuge müssen mitskalieren.