Der Aufstieg der Schatten-KI

Wenn Schatten-IT das sündige Vergnügen der SaaS-Ära war, ist Schatten-KI der Zuckerrausch von GenAI: nicht genehmigte KI-Modelle, Tools und autonome Agenten, die still und heimlich in Geschäftsabläufe integriert werden – oftmals ohne Genehmigung, Protokollierung oder Kontrolle. Sie sind schnell, sie sind nützlich und sie können beißen. 

Der Bericht 2025 GenAI von Netskope zeigt, dass Unternehmen mittlerweile durchschnittlich fast sechs GenAI-Apps nutzen. Das oberste Quartil kommt sogar auf über 13 Apps, während insgesamt mehr als 300 verschiedene GenAI-Anwendungen im Einsatz sind. Zudem wurde im Vergleich zum Vorjahr ein Anstieg der an GenAI-Apps gesendeten Daten um mehr als das Dreißigfache gemessen. Der KI-Bericht von Menlo Security weist auf einen Zuwachs von 68 % bei „Shadow GenAI“ hin, wodurch aus „hilfreichen“ Anwendungen gefährliche Risiken werden. Laut dem Cisco Readiness Index 2025 fehlt rund 60 % der Unternehmen das Vertrauen in ihre Fähigkeit, nicht genehmigte KI-Tools zu identifizieren, was die Notwendigkeit einer kontinuierlichen Überwachung unterstreicht. Gartner bringt dies mit GenAI-Datenprogrammen in Verbindung, die außer Kontrolle geraten sind.

Die Schatten-KI breitet sich über Unternehmen und Funktionen hinweg aus und birgt echte Risiken für die Offenlegung von Daten und die Unternehmensführung – insbesondere, wenn Mitarbeiter ihre eigene KI mitbringen.

Dieser Artikel ist ein praktischer, telemetrieorientierter Leitfaden zur Erkennung und Beherrschung von Schatten-KI. Wir ordnen die Erkennungen dem MITRE ATLAS, den OWASP Top 10 für LLM-Apps und dem NIST AI RMF zu und gehen auf die Protokolle ein, die Sie sammeln sollten (CloudTrail, CloudWatch, Endpunkt, App-Protokolle und Model Context Protocol/MCP-Telemetrie). Wir zeigen Ihnen auch Abfragen im Stil von Sumo Logic, die Sie heute in Ihr SIEM einfügen können.

Was ist Schatten-KI?

Als Schatten-KI wird jede unbefugte Nutzung von KI-Diensten, KI-Tools und dem agentischen Klebstoff (Plug-ins/Tools, MCP-Server, Bedrock-Agenten, LangChain-Tools usw.) bezeichnet, die Produktionsdaten und -systeme berühren kann – oftmals außerhalb der Sichtweite der Sicherheitssysteme. 

Der KI-Zug ist bereits abgefahren. Unternehmen befinden sich nun in einer Zwickmühle: Wenn sie KI-Tools verbieten, setzen sie Anreize für Schatten-KI. Mitarbeiter haben den Wert, den KI in allen Lebensbereichen bietet, längst erkannt. Ein pauschales Nutzungsverbot drängt die Anwendung lediglich in den Schatten. Es ist das KI-Äquivalent zur klassischen Schatten-IT, aber auf Steroiden. Denn KI verarbeitet Daten nicht nur; sie lernt aus ihnen, halluziniert bisweilen abwegige Ergebnisse, hat Zugriff auf hochsensible Systeme und plaudert Geheimnisse manchmal so ungeniert aus wie ein beschwipster Onkel auf einer Familienfeier.

Warum dieser plötzliche Anstieg? Grund dafür ist die demokratisierende Kraft der KI – Tools sind mittlerweile so leicht zugänglich, dass selbst Laien ohne technisches Hintergrundwissen einen Agenten zur Aufgabenautomatisierung erstellen oder einen Copilot nutzen können, um wie ein Profi zu programmieren. Doch ohne entsprechende Aufsicht entstehen unternehmensweite Sicherheitslücken – von Datenlecks bis hin zu Compliance-Albträumen. 

In naher Zukunft rechne ich mit Post-Incident-Meetings, in denen Führungskräfte sagen werden: „Ich wusste gar nicht, dass diese Anwendung KI nutzt“ oder „Wer hat autorisiert, KI auf diese Weise einzusetzen?“. Um Licht ins Dunkel zu bringen, müssen Sie die KI-Strategie Ihres Teams aktiv mitgestalten und Innovationen unterstützen, diese jedoch mit Kontrollmechanismen und Governance flankieren, ohne dabei zu viele Reibungsverluste zu verursachen. 

Wenn Sie bereits weit genug fortgeschritten sind, um AI Red Teaming oder Penetrationstests durchzuführen, sammeln Sie Bonuspunkte. Arbeiten Sie eng mit diesen Testern zusammen, um die Log-Telemetrie während ihrer Angriffsversuche zu erfassen. Wenn es ihnen gelingt, einzudringen, können Sie auf Basis dieser Daten Erkennungsregeln erstellen, um künftiges gegnerisches Verhalten oder KI-Missbrauch sofort abzufangen.

Frameworks zur Verankerung Ihres Programms

AI TRiSM

AI TRiSM steht für Artificial Intelligence Trust, Risk, and Security Management. Es wurde von Gartner entwickelt und beschreibt ein Framework, das sicherstellen soll, dass KI-Systeme über ihren gesamten Lebenszyklus hinweg vertrauenswürdig, compliant und sicher sind. Im Klartext stellt Trust die Frage: Können Sie erklären, wie die KI Entscheidungen trifft? Ist sie fair, zuverlässig und frei von Verzerrungen (Bias)? Risk befasst sich mit der Frage, was schief gehen könnte. Denken Sie an Datenlecks, Halluzinationen, Adversarial Hacks oder regulatorische Probleme. Security befasst sich damit, wie Sie das Modell, die Daten und die Infrastruktur vor Angriffen, Missbrauch oder unbefugtem Zugriff schützen.

NIST AI RMF 1.0 + Generatives KI-Profil (AI 600-1) 

Das AI Risk Management Framework von NIST Das NIST AI Risk Management Framework (AI RMF) fungiert als Ihr Governance-GPS mit Kernfunktionen wie Map (Risiken identifizieren), Measure (Risiken quantifizieren), Manage (Risiken mindern) und Govern (alles überwachen). Wenden Sie dieses Framework auf Schatten-KI an, indem Sie die unbefugte KI-Nutzung in Ihrer Umgebung kartieren (Mapping) und anschließend die Risiken mithilfe von Kennzahlen wie Datensextpositionsraten messen, während Sie gleichzeitig die Incident-Response-Anforderungen für KI-Systeme einhalten.

MITRE ATLAS 

Dies ist Ihr Adversarial Playbook für KI-Systeme – vergleichbar mit MITRE ATT&CK, aber speziell auf Bedrohungen für Machine Learning zugeschnitten. Es bildet Taktiken wie Data Poisoning (bei dem Akteure Trainingsdaten manipulieren) oder Model Evasion (das Überlisten der KI zu Fehlentscheidungen) ab. Nutzen Sie ATLAS, um Risiken durch Schatten-KI zu bewerten, indem Sie Ihre Logs mit dessen Matrizen abgleichen – zum Beispiel, um ungewöhnliche API-Aufrufe zu identifizieren, die auf eine Evasion-Technik in einem unbefugten „Copilot“ hindeuten könnten.

OWASP Top 10 für LLM-Apps (2025 Aktualisierung)

Dieses Dokument listet Schwachstellen auf, die speziell für Large Language Models (LLMs), wie z.B. Prompt Injection (raffinierte Eingaben, die das Modell kapern) oder die Offenlegung sensibler Daten (Weitergabe von personenbezogenen Daten in den Ausgaben). In Schatten-KI-Szenarien könnten Mitarbeiter diese unbeabsichtigt auslösen – beispielsweise ein Marketingteam, das eine nicht genehmigte LLM-App nutzt, die anfällig für Overreliance (blindes Vertrauen in halluzinierte Ergebnisse) ist, was zu fatalen Geschäftsentscheidungen führen kann.

Was sollte protokolliert werden (und warum)?

Cloud-/Modell-APIs 

Beginnen Sie damit, sich in API-Protokolle von Diensten wie AWS Bedrock einzuklinken (eine Brutstätte für Schatten-KI-Experimente). Überwachen Sie zum Beispiel converse- und converse_stream-Aufrufe. Verfolgen Sie Metriken wie Input/Output-Token, Latenz und Aufrufe pro Minute. 

Die meisten Cloud-Anbieter verfügen über dokumentierte Telemetriedaten. Zum Beispiel hat man mit AWS und Bedrock folgende Instrumentierung:

• CloudTrail Management/Data Events für InvokeModel/Converse/ConverseStream und Agents (InvokeAgent). Diese sind hervorragend geeignet, um Identitäten, Modell-IDs und regionsübergreifende Anomalien zu identifizieren.
• CloudWatchAgents-Metriken: Invocations (Aufrufe), Token Counts (Token-Anzahl), Time-to-First-Token (TTFT), Throttles (Drosselungen) sowie Client- und Serverfehler. Diese Daten sind ideal, um die Block-Raten von Guardrails zu überwachen und Ausreißer zu identifizieren, die auf Kostenexplosionen oder Missbrauch hindeuten könnten.
• Invocation Logging (Eingaben/Ausgaben) nach CloudWatch Logs/S3– wichtig für Forensik und Red-Team-Prompts (unter strikter Beachtung der PII-Governance).

Sumo Logic liefert eine Bedrock-App, die CloudTrail + CloudWatch + Invocation Logs in Dashboards und Abfragen zusammenfügt.

Unabhängig vom Modell benötigen Sie keinen schwerfälligen, proprietären Stack, um die GenAI-Nutzung zu überwachen. APIs im OpenAI-Stil liefern bereits die relevanten Telemetriedaten (Latenz, Fehler, Token-Anzahl, Moderationsergebnisse). Wenn Ihre Entwickler eigene KI-Funktionen implementieren, sollten Sie die SDK-Aufrufe instrumentieren. Umschließen Sie diese beispielsweise mit einem kleinen Python-„Agent“ (Wrapper), geben Sie strukturierte Events aus und leiten Sie diese an Ihre bevorzugte SIEM- oder Observability-Plattform weiter. Die Telemetrie umfasst üblicherweise die Aufrufrate, Fehlerraten, Eingabe- und Ausgabe-Token-Anzahlen sowie (optional) stichprobenartige Prompts/Antworten. Leiten Sie JSON-Events über einen HTTPS-Collector an Ihr SIEM weiter. (Die im Jahr 2026 gereiften GenAI Semantic Conventions von OpenTelemetry können diese Felder standardisieren, falls Sie Trace- oder Span-Kontexte benötigen; dies ist jedoch optional.)

Unbefugte Agenten erkennen

Agenten (diese autonomen KI-Macher) kommunizieren bevorzugt direkt über APIs. Um hier die Kontrolle zu behalten, sollten Sie Log-Muster nutzen, um ungewöhnliche Verhaltensweisen zu markieren, wie etwa die Verwendung nicht autorisierter API-Keys oder Zugriffe aus unerwarteten Geolocationen. Verknüpfen Sie diese Erkenntnisse mit MITRE ATLAS, indem Sie Alarme für Taktiken wie „ML Supply Chain Compromise“ einrichten – zum Beispiel, wenn Logs Downloads von zwielichtigen Model-Hubs dokumentieren. Erfassen Sie auf Endpunkten, in CLIs oder Proxys die Shell-History sowie den ausgehenden DNS/HTTP-Traffic. So identifizieren Sie ungenehmigte Aufrufe an öffentliche LLMs oder Agent-Backends (z. B. api.openai.com, api.anthropic.com, *.hf.space, *.perplexity.ai, *.deepseek.com).

MCP-Prüfung (Model Context Protocol)

MCP standardisiert die Verbindung von LLM-Anwendungen mit Tools, Ressourcenund Aufforderungen über JSON-RPC. Das ist Gold wert für Audits: Protokollieren Sie tools/list, tools/call, resources/read, prompts/get, Benutzergenehmigungen sowie Correlation IDs zwischen Client und Server. Die neueste Spezifikation weist explizit auf Logging, Capability Negotiation und Sicherheitsaspekte hin – nutzen Sie diese konsequent

Schatten-KI in der Telemetrie: drei Muster aus der Praxis

Es ist wichtig, an dieser Stelle zu betonen, dass die Grenze zwischen Schatten-KI und Insider-Bedrohungen sehr schnell verschwimmen kann. Manchmal treiben Mitarbeiter Innovationen mit KI voran und sind sich der potenziellen Sicherheitsrisiken schlichtweg nicht bewusst; in anderen Fällen werden sie selbst Opfer böswilliger Akteure, die KI für ihre Zwecke missbrauchen. Diese Muster und Erkennungsmethoden unterstützen Ihr Team dabei, Risiken zu minimieren – unabhängig von der Absicht, die hinter den Aktivitäten steht.

1. Muster – Prompt-to-Tool Pivot (OWASP LLM07/LLM08; ATLAS: Prompt-Injection)

Eine harmlos aussehende Aufforderung veranlasst den Agenten, hochriskante Tools aufzurufen (z .B. Secrets lesen, Aktionen ausführen). Sie sehen eine normale Chat-Anfrage unmittelbar gefolgt von sensiblen tools/call oder Bedrock Agent-Aktionen.

Was Sie protokollieren und überwachen müssen

• MCPtools/call-Aufrufe zu sensiblen Tools (Secrets, Produktions-APIs) ohne passenden Business-Kontext oder fehlendes User-Approval-Flag
  
• BedrockInvokeAgent-Spikes oder die Erstellung neuer Action Groups durch „First-Seen”-Identitäten (UEBA).
  

2. Muster – Cost/DoS via Token Flood (OWASP LLM04; ATLAS: Resource Exhaustion).

Ein manipulierter Prompt oder eine Schleife verursacht unkontrollierte Tokens oder wiederholte Versuche.

Was Sie protokollieren und überwachen müssen

• CloudWatch InputTokenCount/OutputTokenCount-Ausreißer pro Identität/Modell; steigende InvocationThrottles.
  
• Invocation Logging, das sich ausweitende Kontextfenster anzeigt (plötzliche Vervierfachung der Input-Größe).
  

3. Muster – Unerlaubte GenAI-Nutzung (Schatten-KI-„Klassiker“)

Die Endpunkte kommunizieren von Unternehmensnetzwerken aus mit Verbraucher-KI-APIs und fügen die Ergebnisse dann in Unternehmenssysteme ein.

Was Sie protokollieren und überwachen müssen

• Egress/DNS für bekannte LLM-Domains durch Identitäten, die nicht auf einer Allowlist stehen; Tastatur-Makros oder Copy-Buffer (Zwischenablage), die in Helpdesk-Untersuchungen auftauchen. Branchenumfragen zeigen, dass Teams oft die Sichtbarkeit fehlt, welche KI-Dienste aktiv sind – Ihre Logs schließen diese Lücke.

Sumo-Logic-ähnliche Erkennungen, die Sie einfügen können

Bedrock-API-Nutzung durch neue Identitäten (Recon/Enumeration) → ATLAS TA0002; OWASP LLM10

Diese Cloud-SIEM-First-Seen-Regel, die aus unserem Bedrock-Defender-Leitfaden adaptiert wurde, schlägt an, wenn ein neuer Benutzer beobachtet wird, der bestimmte Bedrock-API-Aufrufe in Ihrer AWS-Umgebung tätigt.

Cross-Region InvokeModel-Aufrufe über langlebige Keys (Account-Missbrauch) → ATLAS Initial Access; OWASP LLM10.

Diese Suchanfrage identifiziert die potenzielle Wiederverwendung von Access Keys, um Bedrock-Ressourcen in mehr als einer Region zu instanziieren:

Guardrail/Trace-Anomalien auf Bedrock-Agenten (OWASP LLM06, LLM04)

Die folgende Abfrage prüft auf ungewöhnliche Fehlerraten oder Drosselungsaktivitäten von Bedrock-Agenten, die auf einen möglichen Missbrauch von Agenten hinweisen:

Datenabfluss über Schatten-KI (unsanktionierte LLM-Endpunkte)

Die folgende Abfrage durchsucht Proxy- und Firewall-Protokolle nach Verbindungen zu nicht genehmigten LLM-Endpunkten. Falls gewünscht, erstellen Sie eine Nachschlagetabelle der Benutzer, die eine Verbindung zu diesen Endpunkten herstellen dürfen, und fügen Sie den Pfad der Nachschlagetabelle hinzu:

MCP-Audit: Hochriskante Tool-Aufrufe ohne Genehmigung (OWASP LLM07/LLM08)

Angenommen, Sie geben Anwendungsprotokolle wie die folgenden aus:

Abfrage:

(Basierend auf der JSON-RPC-Spezifikation und den Server-Konzepten von MCP; Instrumentierung der Endpunkte tools/list/call, resources/read, prompts/get sowie der Benutzerfreigaben.) 

ChatGPT-Überwachungsfallstudie

Eine der Stärken von Sumo Logic ist seine Vielseitigkeit. Während wir schlüsselfertige Apps und Erkennungsmechanismen anbieten, liegt der wahre Wert darin, wie Kunden die Plattform erweitern. Um das zu veranschaulichen, habe ich Bill Milligan, einen unserer führenden Professional Services Engineers, gebeten, ein aktuelles Projekt vorzustellen. Er unterstützte einen Kunden dabei, dessen Nutzung von OpenAIs ChatGPT lückenlos zu überwachen – von der Log-Ingestion bis hin zu umsetzbaren Erkenntnissen.

Die Herausforderung des Kunden: Kann Sumo Logic den Austausch von ChatGPT-Prompts tracken, um potenzielle Insider-Bedrohungen oder sogar frühe Anzeichen für psychische Belastungen zu identifizieren, die basierend auf dem Gesprächskontext potenziell zu Gewalt am Arbeitsplatz führen könnten?

1. Schritt – Datenerfassung

Unternehmenskunden von OpenAI können die ChatGPT Compliance API nutzen, um auf detaillierte Logs und Metadaten zuzugreifen, einschließlich Benutzereingaben, Systemnachrichten, Ausgaben, hochgeladener Dateien und GPT-Konfigurationsdaten. Allerdings gibt es derzeit (noch!) keinen vorgefertigten Cloud-to-Cloud-Connector oder eine Katalog-App für diesen Feed.

Bill löste dies mit dem Universal API Collector von Sumo Logic, der jede Datenquelle mit einem API-Endpunkt erfassen kann. Der Collector unterstützt zudem JPath, was es Ihnen ermöglicht, spezifische JSON-Felder (z. B. $.user.id, $.message.text) zu extrahieren und sie direkt als suchbare Felder in Sumo Logic zuzuordnen.

2. Schritt – Aufbau eines einfachen Parsers

Sobald die Daten erfolgreich über die OpenAI API einflossen, nutzte Bill die leistungsstarke integrierte Parsing-Sprache von Sumo Logic. Sie ermöglicht es Kunden, Zeitstempel zu identifizieren, Metadaten-Werte wie Produkt und Hersteller zuzuweisen sowie die Nachrichten auf vielfältige Weise zu zerlegen und zu transformieren. Erfreulicherweise können Parser direkt in der Benutzeroberfläche mit historischen Daten entwickelt und getestet werden, was die Iteration schnell und transparent macht.

Der „Parser“ analysiert die Rohprotokolle während der Weiterleitung an Cloud-SIEM und extrahiert dabei die relevanten Felder zusammen mit dem Hersteller, dem Produkt und der Ereignis-ID.

3. Schritt – Mapping auf unser Schema oder Datenmodell

Parsing und Mapping sind in Sumo Logic zwei voneinander getrennte Schritte. Nach dem Parsing erstellte Bill einen Custom Mapper, um die Felder an das Datenmodell von Sumo Logic anzupassen. Zudem verkettete er mehrere Prompt/Response-Paare zu einem einzigen Konversationsfeld (Beschreibung), um die Keyword-Erkennung zu erleichtern. 

Pro-Tipp: Standardmäßig begrenzt ein Sumo Logic Tenant Log-Nachrichten auf 64 KB. Da diese Konversationen sehr umfangreich werden können, war die Erhöhung dieses Limits auf 256 KB der entscheidende Kniff, um ein unnötiges Abschneiden der Logs zu vermeiden.

Wenn ein „Log Mapper“ Hersteller, Produkt und Ereignis-ID (Event ID) abgleicht, mappt er die vom Parser extrahierten Felder auf einen normalisierten Datensatz, bevor dieser von der Regel-Engine analysiert wird.

4. Schritt – Schreiben einer benutzerdefinierten Regel

Abschließend implementierte Bill eine Custom Match Rule, um auf sensible Schlüsselwörter zu überwachen. Die Regeln sind auf Entitäten (Benutzer) ausgerichtet, um Rauschen zu reduzieren, und mit MITRE-Tags versehen, um den Kontext zu schärfen. Gemäß den Best Practices werden Regeln zuerst im Prototype Mode bereitgestellt, bevor sie live gehen. Dies ermöglicht es den Regeln, gegen jede Entität (in diesem Fall Benutzer) zu feuern, ohne die Alarm-Triage der Sicherheitsanalysten zu überfluten.

Dies ist ein Beispiel für einen Regelausdruck für eine „Match“-Regel – eine der sechs leistungsstarken Regelarten, die in Cloud-SIEM geschrieben werden können.  

Durch das Hinzufügen von MITRE-Tags zu seiner benutzerdefinierten Regel stellte Bill sicher, dass die resultierenden Signale beim Auslösen einen aussagekräftigen Kontext lieferten. Da Sumo Logic Signale und Verhaltensweisen automatisch mit einzelnen Entitäten verknüpft, konnte diese Regel mit anderen kombiniert werden, um die Aktivitäten eines Benutzers zu einem hochpräzisen, handlungsrelevanten Alarm zu eskalieren.

Zwar mag der Arbeitsablauf auf den ersten Blick komplex erscheinen, jedoch ist es dank der Aufteilung in klare Schritte sehr einfach, benutzerdefinierte Protokollquellen zu erfassen und selbst die fortgeschrittensten Anwendungsfälle zu bewältigen.

Fazit

Der Durchschnitt der Unternehmen betreibt heute eine überraschende Anzahl an Gen-AI-Apps, viele davon unautorisiert. Erwarten Sie mehr davon, nicht weniger. Schatten-IT und ihr riskanter Cousin, Schatten-KI: die heimliche Kehrseite, auf der Teams ungeprüfte Tools (oder kostenlose KI-Chats) einsetzen, ohne ein Wort an die IT zu verlieren – was Risiken für Datenlecks und massive Verzerrungen birgt. 

Die Lösung? Ihre Logs sind die Informanten: Überwachen Sie Netzwerkflüsse und Anwendungsnutzung in Sumo Logic-Dashboards, um Schatten-KI frühzeitig aufzudecken. Aufklären statt diktieren – machen Sie aus „Rogues“ Verbündete durch kontrollierte AI Sandboxes. Benötigen Sie eine Orientierung? Nutzen Sie Cloud Proxy/CASB-Logs, um die KI-Nutzung zu erfassen, wenden Sie Governance nach dem AI TRiSM-Modell an und erstellen Sie SIEM-Erkennungen für riskante Kombinationen (z. B. sensible Datenklassen → unautorisierte KI-Domains; plötzliche Spitzen bei Agent-Tool-Calls). Hier geht es weniger darum, jegliche KI zu blockieren, sondern vielmehr darum, das Unbekannte durch Observability und Kontrolle zu ersetzen.

Erfahren Sie mehr darüber, wie Sie eine KI-Sicherheitsrichtlinie erstellen.