Der Aufstieg der Schatten-AIT

Wenn Schatten-IT das schuldige Vergnügen der SaaS-Ära war, sind Schatten-AIT 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 GenAI-Bericht 2025 von Netskope zeigt, dass Unternehmen heute im Durchschnitt fast sechs GenAI-Apps verwenden – das oberste Quartil verwendet über 13, und sie verfolgen insgesamt über 300 verschiedene GenAI-Apps. Sie haben auch einen über 30-fachen Anstieg der an GenAI-Apps gesendeten Daten im Vergleich zum Vorjahr gemessen. Der KI-Bericht von Menlo Security weist auf einen 68%igen Anstieg von Shadow GenAI hin, wodurch „hilfreich“ zu gefährlich wird. Laut dem Bereitschaftsindex 2025 von Cisco fehlt es ca. 60 % der Unternehmen an Vertrauen in die Identifizierung nicht zugelassener KI-Tools, was die Notwendigkeit der Überwachung betont. Gartner bringt dies mit aus dem Ruder gelaufenen GenAI-Datenprogrammen in Verbindung.

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-AIT. 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 sind Schatten-AIT?

Als Schatten-AIT 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 hat den Bahnhof verlassen, und die Unternehmen befinden sich in der misslichen Lage, dass sie Schatten-KIs fördern, wenn sie keine KI-Tools zulassen. Die Mitarbeiter haben erlebt, welchen Wert die KI für alle Aspekte unseres Lebens hat, und ihnen zu sagen, dass sie nicht genutzt werden kann, drängt ihre Nutzung nur in den Schatten. Es ist das KI-Äquivalent zur Schatten-IT, aber auf Steroiden, denn die KI verarbeitet nicht nur Daten, sie lernt daraus, halluziniert wilde Ergebnisse, hat Zugang zu den sensibelsten Systemen und plaudert manchmal Geheimnisse aus wie ein beschwipster Onkel bei einem Familientreffen.

Warum der Anstieg? Schieben Sie es auf die demokratisierende Kraft der KI – die Tools sind jetzt so zugänglich, dass sogar Menschen ohne technische Kenntnisse einen Agenten zur Aufgabenautomatisierung oder einen Copiloten zur Programmierung wie Profis einsetzen können. Aber ohne Aufsicht entstehen in den Unternehmen blinde Flecken – von Datenlecks bis hin zu Alpträumen bei der Einhaltung von Vorschriften. 

In naher Zukunft erwarte ich, dass Führungskräfte nach einem Vorfall sagen werden: „Ich wusste nicht, dass diese Anwendung eine KI verwendet.“ Oder „Wer hat die Verwendung von KI auf diese Weise genehmigt?“. Um Licht ins Dunkel zu bringen, müssen Sie sich in die KI-Strategie des Teams einbringen, Innovationen fördern, aber auch Kontrollen und Governance um sie herum einrichten, ohne zu viel Reibung zu erzeugen. 

Wenn Sie reif genug sind, um KI-Red Teams oder Penetrationstests durchzuführen, erhalten Sie Bonuspunkte. Arbeiten Sie mit diesen Prüfern zusammen, um die Protokoll-Telemetriedaten während ihrer Tests zu erfassen. So können Sie, wenn sie eindringen, Erkennungen erstellen, um zukünftiges feindliches Verhalten oder KI-Missbrauch zu erfassen.

Rahmenwerke zur Verankerung Ihres Programms

AI TRiSM

AI TRiSM steht für Artificial Intelligence Trust, Risk, and Security Management. Das von Gartner entwickelte Rahmenwerk soll sicherstellen, dass KI-Systeme während ihres gesamten Lebenszyklus vertrauenswürdig, konform und sicher sind. Im Klartext bedeutet dies, dass Trust (Vertrauen) fragt: „Können Sie erklären, wie die KI Entscheidungen trifft? Ist sie fair, zuverlässig und unbefangen?“ Risk (Risiko) will wissen: „Was könnte schiefgehen?“ Denken Sie an Datenlecks, Halluzinationen, gegnerische Hacks oder regulatorische Probleme. Security (Sicherheit) befasst sich mit Folgendem: „Wie kann man das Modell, die Daten und die Infrastruktur vor Angriffen, Missbrauch oder unberechtigtem Zugriff schützen?“

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

Das KI-Risikomanagement-Rahmenwerk von NIST ist Ihr Governance-GPS mit Kernfunktionen wie Planen (Risiken identifizieren), Messen (Risiken quantifizieren), Verwalten (Risiken mindern) und Regeln (alles überwachen). Wenden Sie es auf die Schatten-KI an, indem Sie die nicht genehmigte KI-Nutzung in Ihrer Umgebung abbilden und dann die Risiken anhand von Metriken wie der Datenexpositionsrate messen, während Sie die Anforderungen an die Reaktion auf Vorfälle für KI-Systeme befolgen.

MITRE ATLAS 

Dies ist Ihr gegnerisches Spielbuch für KI-Systeme, wie MITRE ATT&CK, jedoch zugeschnitten auf Bedrohungen durch maschinelles Lernen. Es zeigt Taktiken wie Data Poisoning (Manipulation von Trainingsdaten durch böswillige Akteure) oder Modellumgehung (Verleiten von KI zu falschen Entscheidungen) auf. Verwenden Sie ATLAS, um die Risiken der Schatten-KI zu bewerten, indem Sie Ihre Protokolle mit den entsprechenden Matrizen abgleichen. So können Sie beispielsweise ungewöhnliche API-Aufrufe erkennen, die auf eine Umgehungstechnik eines bösartigen Kopiloten hindeuten könnten.

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

Dieser Edelstein listet Schwachstellen auf, die speziell für große Sprachmodelle (LLMs) sind, wie beispielsweise Prompt-Injection (hinterhältige Eingaben, die das Modell missbrauchen) oder Offenlegung sensibler Daten (Durchsickern von personenbezogenen Daten in Ergebnissen). In Schatten-KI-Szenarien könnten Mitarbeiter diese unwissentlich auslösen – z. B. ein Marketingteam, das eine nicht genehmigte LLM-App verwendet, die anfällig für übermäßiges Vertrauen ist (blindes Vertrauen in halluzinatorische Ergebnisse) – dies führt zu schlechten Geschäftsentscheidungen.

Was sollte protokolliert werden (und warum)?

Cloud-/Modell-APIs 

Beginnen Sie damit, API-Protokolle von Diensten wie AWS Bedrock (eine Brutstätte für Schatten-KI-Experimente) abzugreifen. Ü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-Verwaltung/-Datenereignisse für InvokeModel/Converse/ConverseStream und Agenten (InvokeAgent). Ideal für Identität, Modell-IDs und regionsübergreifende Anomalien.
• CloudWatch-Agentenmetriken: Aufrufe, Token-Zahlen, Time-to-First-Token (TTFT), Drosselungen, Client/Server-Fehler – perfekt für Leitplanken-Blockierraten und Kosten-/Missbrauchsausreißer.
• Aufrufprotokollierung (Eingaben/Ausgaben) in CloudWatch Logs/S3– wichtig für Forensik und Red-Team-Anfragen (mit sorgfältiger Verwaltung personenbezogener Daten).

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

Unabhängig vom Modell benötigen Sie keinen schweren, proprietären Stack, um die Nutzung von GenAI zu überwachen. OpenAI-ähnliche APIs liefern bereits die Telemetriedaten, die Sie interessieren (Latenz, Fehler, Token-Zahlen, Moderationsergebnisse). Wenn Ihre Entwickler ihre eigenen KI-Funktionen entwickeln, instrumentieren Sie die SDK-Aufrufe. Verpacken Sie beispielsweise Ihre SDK-Aufrufe in einen kleinen Python-„Agenten“, geben Sie strukturierte Ereignisse aus und leiten Sie diese an jede von Ihnen verwendete SIEM-/Beobachtungsplattform weiter. Die Telemetriedaten umfassen in der Regel die Anrufrate, die Fehlerrate, die Anzahl der Eingabe- und Ausgabe-Token sowie (optional) die abgetasteten Eingabeaufforderungen/Antworten. Leiten Sie JSON-Ereignisse über einen HTTPS-Kollektor an Ihr SIEM weiter. (Die aufkommenden semantischen GenAI-Konventionen von OpenTelemetry können diese Felder standardisieren, wenn Sie einen Trace/Span-Kontext wünschen, aber das ist optional).

Unbefugte Agenten erkennen

Agenten (diese autonomen KI-Macher) lieben es, mit APIs zu chatten. Verwenden Sie Protokollmuster, um ungewöhnliches Verhalten wie etwa unerwartete API-Schlüssel oder Geolokalisierungen zu erkennen. Verknüpfen Sie dies mit MITRE ATLAS, indem Sie vor Taktiken wie „ML Supply Chain Compromise“ warnen – z. B. vor Protokollen, die Downloads von dubiosen Modell-Hubs anzeigen. Erfassen Sie auf dem Endpunkt/CLI/Proxy den Shell-Verlauf und den ausgehenden DNS/HTTP-Anfragen, um unzulässige Aufrufe öffentlicher LLMs oder Agent-Backends (z. B. api.openai.com, api.anthropic.com, *.hf.space, *.perplexity.ai, *.deepseek.com) abzufangen.

MCP-Prüfung (Model Context Protocol)

MCP standardisiert, wie sich LLM-Anwendungen mit Tools, Ressourcenund Aufforderungen über JSON-RPC verbinden. Das ist Gold wert für Audits: log tools/list, tools/call, resources/read, prompts/get, Benutzerfreigaben und Korrelations-IDs über Client und Server hinweg. In der neuesten Spezifikation wird ausdrücklich auf die Protokollierung, Aushandlung von Fähigkeiten und Sicherheitsaspekte hingewiesen – nutzen Sie diese.

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

Es ist wichtig, an dieser Stelle zu betonen, dass die Grenze zwischen Schatten-AIT und Insider-Bedrohungen sehr schnell verschwimmen kann. Manchmal innovieren Mitarbeiter mit KI und sind sich potenzieller Sicherheitsrisiken nicht bewusst, oder sie werden Opfer von bösartigen Akteuren, die KI einsetzen. Diese Muster und Erkennungen können Ihrem Team helfen, unabhängig von der Absicht, die hinter den Mustern steht.

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

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

Was Sie protokollieren und überwachen müssen

• MCPTools/Aufruf zu sensiblen Tools (Geheimnisse, Prod-APIs) ohne passenden Geschäftskontext oder Benutzergenehmigungskennzeichen
  
• BedrockInvokeAgent Spikes oder neue Aktionsgruppen Erstellung durch „First-Seen”-Identitäten (UEBA).
  

2. Muster – Kosten/DoS über Token Flood (OWASP LLM04; ATLAS: Ressourcenerschöpfung)

Eine manipulierte Eingabeaufforderung oder 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.
  
• Aufrufprotokollierung mit expandierenden Kontextfenstern (plötzliche viermal höhere Eingabegröße).
  

3. Muster – Unerlaubte GenAI-Nutzung (Schatten-AIT „klassisch“)

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

• Ausgehende DNS-Anfragen für bekannte LLM-Domänen durch Identitäten, die nicht in einer Erlaubnisliste stehen; Tastaturmakros/Kopierpuffer erscheinen in Helpdesk-Untersuchungen. Umfragen in der Branche haben gezeigt, dass die Mitarbeiter oftmals nicht wissen, welche KI-Dienste betrieben werden – Ihre Protokolle schaffen hier Abhilfe.

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

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

Diese Cloud SIEM First Seen Rule, angepasst an unsere Bedrock-Verteidigeranleitung, wird ausgelöst, wenn ein neuer Benutzer beobachtet wird, der bestimmte Bedrock-API-Aufrufe in Ihrer AWS-Umgebung verwendet.

Regionsübergreifende InvokeModel-Aufrufe mit langfristigen Zugangsschlüsseln (Account-Missbrauch) → ATLAS Initial Access; OWASP LLM10

Diese Suchabfrage identifiziert die mögliche Wiederverwendung von Zugriffsschlüsseln, 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. Wir bieten zwar schlüsselfertige Anwendungen und Erkennungen an, aber der eigentliche Wert ergibt sich daraus, wie die Kunden die Plattform erweitern. Zur Veranschaulichung habe ich Bill Milligan, einen unserer leitenden Professional-Services-Ingenieure, gebeten, von einem kürzlich durchgeführten Projekt zu berichten, bei dem er einem Kunden geholfen hat, seine Nutzung von ChatGPT (OpenAI) durchgängig zu überwachen – von der Protokollerfassung bis hin zu verwertbaren Erkenntnissen.

Die Herausforderung für den Kunden: Kann Sumo Logic den Austausch von ChatGPT-Eingabeaufforderungen verfolgen, um anhand des Konversationskontexts potenzielle Insider-Bedrohungen oder sogar frühe Anzeichen für psychische Probleme zu erkennen, die möglicherweise zu Gewalt am Arbeitsplatz führen könnten?

1. Schritt – Datenerfassung

Unternehmenskunden von OpenAI können die ChatGPT Compliance-API verwenden, um auf detaillierte Protokolle und Metadaten zuzugreifen, einschließlich Benutzereingaben, Systemmeldungen, Ausgaben, hochgeladene 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 dieses Problem mit dem Universal API Collector von Sumo Logic, der jede Datenquelle mit einem API-Endpunkt aufnehmen kann. Der Collector unterstützt auch JPath, sodass Sie bestimmte JSON-Felder (z. B. $.user.id, $.message.text) extrahieren und sie direkt in durchsuchbare Felder in Sumo abbilden können.

2. Schritt – Aufbau eines einfachen Parsers

Sobald die Daten erfolgreich aus der OpenAI-API eingingen, wandte sich Bill der leistungsstarken integrierten Parsing-Sprache von Sumo Logic zu. Damit können Kunden Zeitstempel identifizieren, Metadaten wie Produkt und Anbieter zuweisen sowie die Nachrichten auf verschiedene Arten aufteilen und umwandeln. Erfreulicherweise können Parser direkt in der Benutzeroberfläche mit historischen Daten entwickelt und getestet werden, und die macht die Iteration wiederum schnell und sichtbar.

Der „Parser“ analysiert Rohprotokolle, die an Cloud SIEM weitergeleitet werden, und extrahiert wesentliche Felder zusammen mit dem Anbieter, dem Produkt und der Ereignis-ID.

3. Schritt – Mapping auf unser Schema oder Datenmodell

Parsing und Mapping sind unterschiedliche Schritte in Sumo Logic. Nach dem Parsen erstellte Bill einen benutzerdefinierten Mapper, um die Felder an das Datenmodell von Sumo anzupassen. Außerdem hat er mehrere prompt/response-Paare in ein einziges Gesprächsfeld (Beschreibung) verkettet, um die Erkennung von Schlüsselwörtern zu erleichtern. 

Pro-Tipp: Standardmäßig beschränkt ein Sumo Logic-Mandant die Protokollnachrichten auf 64 KB. Da diese Konversationen recht umfangreich werden können, genügte die Anfrage, das Limit auf 256kb zu erhöhen, um ein unnötiges Abschneiden von Protokollen zu vermeiden.

Wenn ein „Log-Mapper“ mit dem Anbieter, dem Produkt und der Ereignis-ID übereinstimmt, ordnet er die vom Parser extrahierten Felder einem normalisierten Datensatz zu, bevor er von der Regelmaschine analysiert wird.

4. Schritt – Schreiben einer benutzerdefinierten Regel

Schließlich implementierte Bill eine benutzerdefinierte Abgleichsregel, um auf sensible Schlüsselwörter zu achten. Die Regeln sind auf Entitäten (Benutzer) beschränkt, um das Rauschen zu reduzieren, und werden mit MITRE-Tags für den Kontext abgestimmt. Unter Verwendung bewährter Verfahren werden die Regeln zunächst im Prototyp-Modus eingesetzt, bevor sie in Betrieb genommen werden. Auf diese Weise können die Regeln gegen jede beliebige Entität (in diesem Fall Benutzer) abgefeuert werden, ohne die Alarmtriage zu sprengen, die die Sicherheitsanalysten überwachen.

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.  

Indem er seiner benutzerdefinierten Regel MITRE-Tags hinzufügte, stellte Bill sicher, dass die resultierenden Signale, wenn sie ausgelöst wurden, einen sinnvollen Kontext enthielten. Da Sumo Logic Signale und Verhaltensweisen automatisch einzelnen Entitäten zuordnet, könnte diese Regel mit anderen kombiniert werden, um die Aktivität eines Benutzers in eine hochpräzise, umsetzbare Warnmeldung umzuwandeln.

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

In einer durchschnittlichen Organisation wird heute eine überraschend hohe Anzahl von Gen-AI-Apps eingesetzt – viele davon ohne Genehmigung. Erwarten Sie mehr davon, nicht weniger. Die Schatten-IT und ihre düstere Verwandte – die Schatten-AI: die heimliche Schattenwelt, in der Teams ungetestete Tools (oder kostenlose KI-Dienste) einsetzen, ohne die IT-Abteilung zu informieren, was zu Sicherheitslücken und Verzerrungen führen kann. 

Die Lösung? Ihre Protokolle sind der Spitzel: Überwachen Sie die Netzwerkflüsse und App-Nutzung in Sumo Logic-Dashboards, um Schatten frühzeitig zu entdecken. Aufklären, statt befehlen – machen Sie regelwidrige Nutzer zu Verbündeten, indem Sie Ihnen geregelte KI-Sandboxen bereitstellen. Brauchen Sie eine Orientierung? Verwenden Sie Cloud-Proxy/CASB-Protokolle, um die KI-Nutzung zu erfassen, eine KI TRiSM-ähnliche Governance anzuwenden und SIEM-Erkennungen für riskante Kombinationen zu erstellen (z. B. sensible Datenklassen → nicht genehmigte KI-Domains; plötzliche Spitzen bei Aufrufen von Agententools). Dabei geht es weniger darum, jegliche KI zu blockieren, sondern vielmehr darum, das Unbekannte durch das Beobachtbare und Gesteuerte zu ersetzen.

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