Shadow-KI-Erkennung & Sicherheitslage-Management für KI-Agenten (AI-SPM)

Beschäftigte fügen Daten in kostenlose Chatbots ein, installieren KI-Browser-Erweiterungen, verbinden Copilots per OAuth mit Postfächern und starten Agenten und MCP-Server, die niemand registriert hat. Die Shadow-KI-Erkennung findet diese Assets in Identitäts-, Netzwerk-, Endgeräte- und SaaS-Telemetrie; AI-SPM bewertet anschließend jedes KI-Asset und seine nicht-menschliche Identität, markiert überprivilegierte Agentenzugriffe und setzt die Nutzungsrichtlinie durch. Ergebnis: ein aktuelles Inventar statt einer Umfrage und weniger unbemerkte Datenabflüsse.

Problem & Nutzen

• Heute: Die KI-Einführung ist schneller als die Governance. Sicherheitsteams erfahren von Werkzeugen aus Rechnungen, Nutzerumfragen oder Vorfällen. Agenten laufen unter persönlichen Tokens oder gemeinsam genutzten Dienstkonten mit weitreichenden Berechtigungen, und niemand ist für sie zuständig. Klassische CASB-/SaaS-Discovery-Kataloge hinken dem Tempo neuer KI-Apps hinterher.
• KI-Nutzen: Einstufung von Long-Tail-Domains und -Apps als „KI“, Zuordnung von Agenten und MCP-Servern zu Verantwortlichen und Berechtigungen, Priorisierung der wenigen Assets, auf die es wirklich ankommt, und Untersuchung in natürlicher Sprache, etwa „Welche Agenten können HR-Daten lesen?“.
• Nutzenbeleg: Herstellerumfragen berichten von weit verbreiteter nicht genehmigter KI-Nutzung; als Richtwert behandeln und die eigene Ausgangslage messen [1][5]. Eine allgemeingültige ROI-Zahl gibt es nicht.
• Abgrenzung zu Nachbarn: SEC-010 schützt eine bekannte LLM-App zur Laufzeit; SEC-022 ist der Dokumentations- und Compliance-Workflow der KI-Verordnung; SEC-013 ist die telemetriegetriebene Erkennungs- und Kontrollschicht, die beide speist.

Varianten

• Shadow-KI-Erkennung (SaaS und Browser): welche GenAI-Websites, Plug-ins und Erweiterungen genutzt werden, von wem und mit welchen Daten.
• Agenten- und Nicht-menschliche-Identitäten-Lage: Inventar von Agenten, Service Principals, API-Schlüsseln, OAuth- Apps und MCP-Servern; Prüfung auf geringste Rechte und Zuständigkeit.
• Cloud-AI-SPM: Fehlkonfigurationen verwalteter KI-Dienste (Bedrock, Azure OpenAI/Foundry, Vertex AI), offen erreichbare Modell-Endpunkte, öffentliche Vektorspeicher, zu weit gefasste Rollen.
• Entwicklung / Code-Ebene: KI-SDK-Nutzung, fest eingebaute Schlüssel und nicht genehmigte MCP-Server, gefunden in Repositories und CI.
• KMU: vorhandene Kontrollen von IdP / Microsoft 365 / Google Workspace (App-Einwilligung, DLP, Webfilter) plus eine kurze KI-Richtlinie nutzen.
• Öffentlicher Sektor: dasselbe Muster mit Vorgaben zu Datenresidenz und souveränem Hosting sowie einer Dienstvereinbarung mit Betriebs-/Personalrat.

So funktioniert es

1. telemetry (IdP/OAuth, proxy/DNS, endpoint, SaaS, cloud, repos)
2. AI-asset detection (domain/app/model/MCP classifier + signature catalogue)
3. entity resolution (app ↔ owner ↔ non-human identity ↔ data touched)
4. posture and risk scoring (data sensitivity, scopes, autonomy, vendor terms, region)
5. graph of agent
6. tool
7. data permissions (blast radius, toxic combinations)
8. policy engine (sanction / block / coach / require approval / revoke token)
9. ticket + owner attestation + evidence to governance register

• Erkennung: überwiegend Regeln und Kataloge bekannter KI-Dienste, ergänzt durch Klassifikatoren (Textklassifikator / kleines LLM), die unbekannte Domains, Erweiterungs-Manifeste und OAuth-App-Beschreibungen als KI einstufen.
• Graphanalyse: Ein Identitäts-/Berechtigungsgraph zeigt, welcher Agent welche Daten und Werkzeuge erreichen kann; Abfragen im Stil von Angriffspfaden finden „Agent mit E-Mail-Versand plus Dateilesezugriff plus externem Webzugriff“.
• LLM-Assistent: fasst Befunde zusammen, entwirft die Ansprache der Verantwortlichen und beantwortet Untersuchungsfragen; er darf ohne Freigabe keinen Schreibzugriff auf Durchsetzungsmaßnahmen haben.
• Mensch-in-der-Schleife (Human-in-the-Loop): Die Sicherheitsverantwortlichen genehmigen neue zugelassene Werkzeuge, Risikoakzeptanzen und jede automatische Sperre über vorab vereinbarte Kategorien hinaus; Fachverantwortliche bestätigen Agenten regelmäßig.

Datenaufbereitung

Die „Daten“ sind hier Telemetrie, keine Dokumente: IdP- und OAuth-Freigabe-Logs (Entra ID, Okta, Google Workspace), Proxy-, DNS- und Firewall-Logs, Endgeräte-Inventare, SaaS- und Cloud-Verwaltungskonsolen sowie Code-Repositories. In einem KMU liegen diese im M365- oder Google-Admin-Center, in der Firewall und in einem Endgeräte-Werkzeug; sie werden selten miteinander korreliert.

Typische Lücken: keine zentrale Log-Aufbewahrung (Firewall-Logs werden nach Tagen überschrieben), fehlende Zuordnung von Assets zu Verantwortlichen, nicht verwaltete Geräte und private Smartphones, gemeinsam genutzte oder Dienstkonten ohne benannte Verantwortliche und keine schriftliche KI-Richtlinie als Maßstab (siehe GUIDE-007).

Schritte zur Vorbereitung: 1. Anmelde-, OAuth-Einwilligungs- und Proxy-/DNS-Logs einschalten und aufbewahren (90 Tage sind ein praktikabler Anfang). 2. Ein erstes Inventar zugelassener Werkzeuge und Verantwortlicher aufbauen; Dienstkonten und Tokens bereinigen. 3. Datenklassen festlegen und bestimmen, was in welches Werkzeug darf (PREP-024), und Überfreigaben bereinigen, bevor Agenten Zugriff erhalten (PREP-023). 4. Verantwortliche je Abteilung erfassen (PREP-004).

Werkzeuge: die Protokollfunktionen der vorhandenen Identitätsplattform, ein SIEM oder Log-Collector (Wazuh, Graylog), Tabellen für das erste Register. Grober Aufwandsanteil: etwa 30 Prozent, vor allem Log-Zugriff und Bereinigung der Zuständigkeiten; zur Bereitschaftsprüfung siehe GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg A — die Erkennungsfunktionen stecken bereits in den Identitäts-, Endgeräte- und Web-Gateway-Produkten, die KMU einsetzen (Entra/Defender, Google Workspace, Okta), und der Prozess ist Standard; ein selbst gebauter Katalog würde sich daher nicht lohnen.
• Großunternehmen: Weg A — Shadow-KI-Erkennung ist eine Standardfunktion der IT-Sicherheit; ausgereifte CASB-/SSPM-/AI-SPM-Produkte decken sie ab, und den Signaturkatalog für KI-Apps selbst aufzubauen und zu pflegen lohnt sich selten (Weg B/C nur für agentenspezifische Graphanalyse obendrauf).
• Öffentlicher Sektor: Weg A — ein in der EU gehostetes oder On-Premises-Produkt wählen, das bereits in einem Beschaffungsrahmen enthalten ist; die Telemetrie enthält Beschäftigtendaten und sollte deshalb in einer souveränen Umgebung bleiben.

Weg A — Kaufen (Standardsoftware)

• Identitätszentriert: Okta (Identity Security Posture Management mit Erkennung von KI-Agenten), Microsoft Entra (Agent ID, App-Governance) mit Microsoft Defender und Purview, Google-Workspace- Administrationskontrollen, CyberArk und SailPoint für nicht-menschliche Identitäten.
• Endgeräte-/netzwerkzentriert: CrowdStrike Falcon (Shadow-KI-Erkennung), Palo Alto Networks (Prisma AIRS, AI Access Security), Zscaler, Netskope und Cloudflare (Sichtbarkeit und Kontrolle von KI-Apps über Gateway/CASB).
• Dediziertes AI-SPM / KI-Sicherheit: Wiz AI-SPM, Microsoft Defender for Cloud AI posture, Orca, Prisma Cloud, Cyera und Varonis für den Datenkontext; Start-ups wie Noma Security, Zenity, Lasso Security, Prompt Security (jetzt SentinelOne), Witness AI und Aim Security (jetzt Cato Networks); die Anbieterlandschaft konsolidiert sich schnell. EU-eigene Spezialisten sind selten: auf EU-Hosting, Log-Aufbewahrung und Betriebsrats-Funktionen achten.
• A wählen, wenn: Sie bereits einen IdP, EDR oder SASE-Stack betreiben; die Erweiterung ist dann der schnellste Weg.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Datenquellen: Microsoft Graph (OAuth-Freigaben, Service Principals, Anmelde-Logs), Okta System Log API, Google Workspace Admin SDK, Cloud-Inventar-APIs (AWS Config, Azure Resource Graph, GCP Asset Inventory), GitHub-Codesuche nach SDK-/MCP-Konfigurationen.
• Klassifikation und Triage: ein in der EU gehostetes LLM (Mistral oder Claude/GPT/Gemini in EU-Regionen) mit strukturierten Ausgaben, um unbekannte Apps einzustufen und OAuth-Berechtigungen zusammenzufassen; Ablage in einem SIEM (Microsoft Sentinel, Splunk, Elastic) und einem Graphspeicher.
• B wählen, wenn: Sie eigene Verknüpfungen über Ihre Telemetrie brauchen oder eine schlanke KMU-Variante.

Weg C — Selbst betreiben (Open Source)

• Telemetrie: Zeek/Suricata, OpenSearch/Wazuh, osquery oder Fleet für Endgeräte, Steampipe/CloudQuery für das Inventar, Neo4j/Memgraph für den Berechtigungsgraphen.
• Cloud-Sicherheitslage: Prowler und Cartography decken Cloud- und Identitätsgraphen ab; einige Prüfungen für KI-Dienste gibt es, die Abdeckung schwankt.
• KI-spezifisch: offene Scanner für MCP-Server und Agentenkonfigurationen (z. B. Invariant Labs mcp-scan, Cisco MCP Scanner) und OWASP-Ressourcen zur Einstufung von Risiken; ein kleines lokales LLM (Llama, Qwen, Mistral small, ≤8B) für die Klassifizierung.
• Hardware: HW1 (CPU-Server) genügt; ein LLM zur Klassifizierung ist optional auf HW2.

Weg D — Eigenes Training

Lohnt sich selten. Ein feingetunter Domain-Klassifikator für „Ist dieser Datenverkehr oder diese App GenAI?“ kann sehr großen Netzen helfen, die Telemetrie nicht an Anbieter senden können; die Trainingsdaten sind Ihre eigenen gelabelten Proxy- und DNS-Logs.

Stand der Technik (2026)

• Der Fokus hat sich von Chatbots auf Agenten verschoben: Anbieter inventarisieren heute Agenten, MCP-Server und deren nicht-menschliche Identitäten, nicht nur GenAI-Websites. Okta kündigte die Agentenerkennung in ISPM an, und Microsoft führte Entra Agent ID für Agenten-Identitäten ein [2][3].
• Konvergenz: AI-SPM verschmilzt mit CSPM/DSPM (Cloud), ITDR/ISPM (Identität) und SASE/CASB (Netzwerk); zu erwarten sind auf lange Sicht KI-Funktionen in bestehenden Plattformen statt einer eigenen Kategorie.
• Rahmenwerke: OWASP Top 10 für LLM-Anwendungen und die OWASP-Arbeiten zu Bedrohungen durch agentische KI, MITRE ATLAS und NIST AI RMF liefern das Risikovokabular und die Zuordnung von Maßnahmen [4][6].
• Grenzen: Verschlüsselte oder lokale Nutzung (Modelle auf dem Gerät, private Smartphones) entgeht der Netzwerktelemetrie; Signaturkataloge hinken neuen Apps hinterher; in zugelassene SaaS-Produkte eingebettete KI-Funktionen lassen sich schwer von der Host-App trennen; Risikobewertungen sind anbieterspezifisch und nicht vergleichbar; das Verhalten von Agenten ist nicht deterministisch, daher sind Berechtigungen, nicht die Absicht, die verlässliche Kontrolle. Sperren ohne zugelassene Alternative treibt die Nutzung in den Untergrund.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (Telemetrie + Graph + kleines LLM): SEC-005 (Anomalieerkennung bei Identitäten), SEC-001 (SOC- Triage), SEC-020 (Zugriffsprüfungen und geringste Rechte) nutzen dieselben Identitäts-Logs und denselben Graphen.
• Laufzeitschutz: SEC-010 Guardrails für hier entdeckte Apps; SEC-017 Datenerkennung/KI-DLP entscheidet, welche Daten welches KI-Asset erreichen dürfen; SEC-016 scannt bösartige Modell- und MCP-Pakete.
• Governance: SEC-022 nutzt das Inventar für die Einstufung nach der KI-Verordnung; SEC-009 verwendet es als ISO-27001-/NIS2-Nachweis; AGENT-025 behandelt Flottenbeobachtung und Bewertung selbst gebauter Agenten.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis Wochen für die Aktivierung in einer vorhandenen Plattform; meist nach Nutzer oder Asset bepreist, oft als Zusatzlizenz.
• Weg B: 1–3 Monate für Konnektoren, Bewertung und ein Dashboard.
• Weg C: 2–4 Monate plus laufende Katalogpflege.
• Kennzahlen: Anteil der KI-Assets mit benanntem Verantwortlichen; Verhältnis nicht zugelassener zu zugelassenen Assets; Zeit bis zur Entdeckung einer neuen KI-App oder eines neuen Agenten; Agenten mit überhöhten Rechten (Anzahl, Trend); veraltete Tokens, die widerrufen wurden; Ereignisse mit sensiblen Daten in Richtung nicht zugelassener KI; Richtlinienausnahmen, die über ihr Ablaufdatum hinaus offen sind.

Menschen & Veränderung

Beginnen Sie mit Geschäftsführung und IT-Sicherheit: Sie legen die KI-Richtlinie fest (GUIDE-007) und entscheiden, ob die Erkennung zu Sperren oder zu Beratung führt. Binden Sie die Datenschutzbeauftragte bzw. den Datenschutzbeauftragten früh ein, denn Anmelde-, Proxy- und Endgeräte-Logs sind personenbezogene Daten; eine Datenschutz-Folgenabschätzung (DSFA) ist wahrscheinlich, wenn Logs im großen Umfang mit namentlich bekannten Beschäftigten verknüpft werden (GUIDE-005).

Betriebsrat: ja. Das Werkzeug protokolliert, welche KI-Dienste einzelne Personen nutzen, ist also objektiv zur Verhaltensüberwachung geeignet und löst die Mitbestimmung nach §87 Abs. 1 Nr. 6 BetrVG aus; §90 Abs. 1 Nr. 3 verlangt frühzeitige Information, und §80 Abs. 3 erlaubt eine/n KI-Sachverständige/n. Schließen Sie eine Betriebsvereinbarung (GUIDE-004), die die Analyse auf die Ebene der KI-Assets beschränkt, individuelle Leistungsbewertung ausschließt und die Aufbewahrung der Logs regelt. In Behörden hat der Personalrat dieselbe Rolle.

Kommunizieren Sie vor dem Einschalten: warum, was protokolliert wird, was nicht. Positionieren Sie das Werkzeug als „erst beraten, dann sperren“ und bieten Sie zugelassene Alternativen an, sonst wechseln Beschäftigte auf private Geräte. Wählen Sie die IT und eine Fachabteilung als Pilotgruppe. Typische Sorgen sind Überwachung und der Verlust nützlicher Werkzeuge; begegnen Sie ihnen mit Transparenz und einem schnellen Freigabeweg für neue Werkzeuge. Fördern Sie die KI-Kompetenz (Art. 4 KI-Verordnung) mit kurzen Schulungen dazu, was in welches Werkzeug eingefügt werden darf (GUIDE-006, GUIDE-008). Menschen entscheiden über Sperren und Risikoakzeptanzen.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): Die Kontrolle selbst ist ein minimales Risiko (KI-Kompetenz, Art. 4). Sie unterstützt Betreiberpflichten wie Inventar und Aufsicht nach Art. 26 und Art. 4. Vorsicht (Art. 5): Setzen Sie sie nicht ein, um Emotionen von Beschäftigten abzuleiten oder Verhaltensprofile einzelner Personen zu bilden; Funktionen zur Mitarbeiterüberwachung, die Beschäftigte profilieren, könnten in den Hochrisiko-Bereich (Anhang III, Beschäftigung) oder in verbotenes Terrain fallen. Halten Sie die Analyse auf der Ebene von Assets und Identitäten [7].
• DSGVO: Logs verknüpfen Personen mit Inhalt und Zeitpunkt der KI-Nutzung; es handelt sich daher um personenbezogene Daten und Beschäftigtenüberwachung. Erforderlich sind eine Rechtsgrundlage (Art. 6 Abs. 1 lit. f mit Interessenabwägung), Transparenz, Datenminimierung, eine DSFA bei systematischer Überwachung, Aufbewahrungsfristen und in Deutschland die Mitbestimmung des Betriebsrats (§87 Abs. 1 Nr. 6 BetrVG). Standardmäßig pseudonymisierte, aggregierte Berichte bevorzugen.
• NIS2 / DORA / ISO 27001: Asset-Inventar und Lieferkettenkontrollen sind vorgeschrieben; die Erkennung von KI-Assets liefert den Nachweis [8].
• Risiken und Gegenmaßnahmen: zu häufiges Sperren (zugelassene Werkzeuge bereitstellen), falsche Einstufung (menschliche Prüfung), das Erkennungswerkzeug selbst mit weitreichendem Lesezugriff (geringste Rechte, Auftragsverarbeitungsvertrag (AVV) mit dem Anbieter, EU-Hosting) und Anbieterbindung (Inventar in offenen Formaten exportieren).

Erste Schritte

1. Eine kurze KI-Nutzungsrichtlinie und eine Liste zugelassener Werkzeuge veröffentlichen; einen Verantwortlichen für das KI-Inventar benennen.
2. OAuth-Freigaben und Service Principals aus Ihrem IdP abrufen und jede KI-App und jeden Agenten mit Berechtigungen auflisten.
3. Die Sichtbarkeit von KI-Apps in Ihrem vorhandenen Gateway/CASB/EDR 30 Tage lang nur im Überwachungsmodus aktivieren.
4. Nach Datensensibilität und Berechtigungen ordnen; die zehn wichtigsten Befunde widerrufen oder anpassen und zugelassene Alternativen anbieten.
5. Den Überwachungsumfang mit der bzw. dem Datenschutzbeauftragten und dem Betriebsrat abstimmen, dann vierteljährliche Bestätigungen durch die Verantwortlichen einrichten.

Quellen

1. Okta — Identity Security Posture Management — https://www.okta.com/products/identity-security-posture-management/
2. Microsoft — Microsoft Entra Agent ID overview — https://learn.microsoft.com/entra/agent-id/
3. Microsoft — Defender for Cloud AI security posture management — https://learn.microsoft.com/azure/defender-for-cloud/ai-security-posture
4. OWASP — Top 10 for LLM Applications / GenAI Security Project — https://genai.owasp.org/
5. CrowdStrike — Falcon platform and shadow AI visibility — https://www.crowdstrike.com/
6. NIST — AI Risk Management Framework — https://www.nist.gov/itl/ai-risk-management-framework
7. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
8. Directive (EU) 2022/2555 (NIS2) — https://eur-lex.europa.eu/eli/dir/2022/2555/oj
9. MITRE ATLAS — https://atlas.mitre.org/