Auf Ihren Endpoints laufen KI-Agenten, die Sie nicht sehen können

Was ist Schatten-KI auf Endpoints?

Schatten-KI auf dem Endpoint bezieht sich auf lokale KI-Software, LLMs und MCP-Serverintegrationen (Model Context Protocol), die von Mitarbeiter:innen ohne Beschaffungsprozess, Security-Review oder Identity-Governance direkt auf der Hardware bereitgestellt werden. Während Browser-basierte KI Datenleckrisiken birgt, interagieren Endpoint-KI-Agenten im Hintergrund über MCP-Server direkt mit lokalen Dateisystemen und SaaS-Systemen.

Das Risiko betrifft nicht mehr nur Agenten, die sich über Browser verbinden. Jetzt können alle Mitarbeiter:innen auf dem eigenen Laptop mehrere KI-Agenten starten. Es ist so einfach, dass es nicht mehr nur technischen Rollen vorbehalten ist. Jede:r kann das. 

Diese Agenten arbeiten superschnell, bedeuten jedoch das reinste Identity-Chaos: keine zentrale Identity-Durchsetzung, keine Berechtigungsbereiche, kein Audit-Trail, keine Zugriffsüberprüfung. 

Wie MCP-Server die Endpoint-Angriffsfläche erweitern

KI-Agenten agieren nicht allein. Um etwas Nützliches zu tun, benötigt ein Agent eine Möglichkeit, verschiedene Systeme zu erreichen, und das bedeutet heute fast immer den MCP-Server. Er ist das Bindeglied zwischen einem Agenten und allem, worauf er zugreifen kann.

Es sind nur wenige Klicks erforderlich, um diese Agenten über einen MCP-Server mit den sensibelsten Anwendungen Ihres Unternehmens zu verbinden. Der Agent befindet sich auf dem Gerät, führt jedoch Aufrufe aus, die direkt Ihr CRM, Ihre SaaS-Apps, Ihre Cloud-Infrastruktur und mehr erreichen.

Die OWASP Foundation dokumentiert „MCP-Tool-Poisoning“ als kritischen Angriffspunkt und merkt an, dass ein von Angreifer:innen kontrollierter oder kompromittierter MCP-Server Tool-Metadaten zur Laufzeit ändern kann, da Tool-Beschreibungen in der Regel nur bei der ersten Verbindung überprüft werden. Sobald die Verbindung hergestellt ist, werden modifizierte Tool-Definitionen in das Kontextfenster des Modells geladen, um die Ausführung zu kapern und Daten zu exfiltrieren.

Kann Ihr Security-Team diese Agenten samt ihren verantwortlichen Personen bei einem Vorfall benennen und sagen, auf welche Anwendungen und Daten sie zugreifen können? Viele können das nicht.

Und wenn Sie das nicht wissen, können Sie auch die erste Frage im Konzept für den sicheren Einsatz von Agenten in Unternehmen nicht beantworten: Wo sind meine Agenten?

Angesichts der Vielzahl der in Unternehmen eingesetzten Geräte potenziert sich das Risiko schnell.

Wie unüberwachte KI-Agenten Sicherheitskontrollen im Unternehmen umgehen

Lokale KI-Agenten umgehen die Sicherheitskontrollen des Unternehmens, indem sie ungeprüfte MCP-Verbindungen nutzen, die Berechtigungen menschlicher Benutzer:innen ohne eigene Agentenidentitäten erben, dauerhaften Standing Access aufrechterhalten und Tool-Modifikationen zur Laufzeit ausführen – und das alles, ohne zentrale IT-Audit-Logs zu generieren.

Alle diese Schwachstellen haben dieselbe Ursache: mangelnde Endpoint-Transparenz. Wenn Security-Teams KI-Agenten oder die MCP-Server, mit denen sie sich verbinden, nicht sehen können, versagen Standard-Frameworks für Identity and Access Management (IAM). 

Hier sind die fünf wichtigsten Methoden, mit denen Agenten Ihre Kontrollen umgehen können.

1. MCP-Server verbinden Agenten ohne Ihr Wissen mit Geschäftssystemen

MCP-Server, die auf sensible Systeme zugreifen, lassen sich relativ einfach erstellen und verbinden. Um sie zu nutzen, muss man lediglich einen einzigen Befehl im Terminal ausführen. Ein nicht genehmigter Endpoint-Agent lässt innerhalb weniger Minuten mit Ihren Anwendungen (z. B. Ihrem Snowflake-Tenant) verbinden. Dieser KI-Agent bewegt sich nun innerhalb Ihres sensibelsten Systems. Er kann jede für ihn zugängliche Tabelle abfragen, ohne dass Sie es genehmigen müssen oder überhaupt wissen.

Die Aussicht auf Produktivität verleitet Ihre Mitarbeiter:innen dazu, diese Server mit KI-Agenten zu verbinden, ohne über die Folgen für die Sicherheit nachzudenken.  

Wenn Sicherheitsmaßnahmen nicht Schritt halten können, bleiben kritische Verbindungen unüberwacht und ungeprüft. Das bedeutet, dass eine Verbindung zu Ihren sensibelsten Daten auf unbestimmte Zeit bestehen bleiben kann, ohne dass jemand dafür verantwortlich ist, worauf sie zugreift, und ohne Protokolle zur Überprüfung, wenn schließlich etwas schiefgeht. Das ist eine Sicherheitsverletzung, die einfach nur auf den geeigneten Moment wartet.

2. Daten werden zwischen Systemen übertragen, die nie zentral überprüft wurden

Ein Agent verschiebt Daten, wenn er der Meinung ist, dass sie für die ihm übertragene Aufgabe nützlich sind. Ihre Datenklassifizierung, Speicherregeln oder Anzeigeberechtigungen lässt er außen vor. Niemand hat diese Entscheidung genehmigt. Es gibt keine Richtlinie, die regelt, worauf der Agent zugreifen kann. Am Ende ist er mit mehreren Systemen gleichzeitig verbunden. Genau diese Kombination ist das Risiko. 

Ein Agent, der Kundendaten lesen kann, kann möglicherweise auch E-Mails an beliebige Personen senden. Das sind weitreichende Berechtigungen, durch die Ihre Agenten mehr Daten sehen, als sie für die eine bestimmte Aktion benötigen. Das Ergebnis: Ein einziger kompromittierter Prompt genügt, um eine schwerwiegende Sicherheitsverletzung auszulösen.

3. Agenten agieren über den Zugriff einer anderen Person und besitzen keine eigene Identität

Agenten authentifizieren sich bei Systemen in der Regel über einen OAuth-Grant oder einen API-Key, der in der Konfigurationsdatei des MCP-Servers gespeichert ist. Sobald er Zugriff hat, können Sie nicht mehr verlässlich bestimmen, ob eine Aktion von der eigentlichen Person oder dem in ihrem Namen handelnden Agenten stammt. Sie sind über dieselbe Identität miteinander verbunden. Wenn also etwas schiefgeht, können Sie die erste Frage nicht beantworten: War das die eigentliche Person oder der Agent?

Ein Beispiel: Der Agent einer Mitarbeiterin aus der Buchhaltung aktualisiert über Nacht einen Datensatz für eine Lieferantenzahlung. Das Log zeigt, dass die Änderung über die Anmeldedaten der Mitarbeiterin erfolgte. Es lässt sich aber nicht feststellen, ob die Mitarbeiterin oder ihr Agent sie vorgenommen hat und ob sie überprüft wurde.

Um zu klären, wer gehandelt hat, müssen Logs aus jedem System abgerufen werden, auf das der Agent zugegriffen hat, und Zeitstempel manuell abgeglichen werden, wobei die verwendeten Formate nie für eine gegenseitige Kommunikation entwickelt wurden. Die Rekonstruktion einer einzigen Aktion sollte nur Minuten dauern, erfordert aber tagelangen Aufwand, wenn mehrere voneinander getrennte Systeme involviert sind.

4. Agenten fordern nur einmal eine Berechtigung an und erhalten Standing Access

Bis vor wenigen Monaten waren die meisten von uns noch misstrauisch gegenüber dem, was KI-Agenten taten. Wir stoppten und prüften jedes Mal, wenn ein Agent zusätzliche Berechtigungen benötigte oder eine System-API aufrufen wollte. Jetzt lassen wir sie autonom laufen. Agentenbasierte Tools bieten automatische Modi, in denen der Agent über Tool-Aufrufe selbstständig weiterarbeitet, mit Zulassungs- und Ablehnungsregeln, die Sie einmalig konfigurieren.

Ein Beispiel: Ein Mitarbeiter weist dem eigenen Agenten eine komplexe, lang andauernde Aufgabe zu und konfiguriert diese so, dass sie automatisch ausgeführt wird. Irgendwann auf diesem Weg entscheidet der Agent selbstständig, dass das Ändern von Datensätzen in Salesforce oder Snowflake der richtige Weg ist, um die Aufgabe zu erledigen. Und er tut dies auch. Der Mitarbeiter hat diese spezifische Aktion nie genehmigt und bemerkt möglicherweise nicht einmal, dass sie stattgefunden hat. Niemand überprüft die Änderung, bis etwas ausfällt oder fehlerhaft aussieht.

5. Der MCP-Server gewährt Agenten Zugriff, den Sie nicht kontrollieren

Ein MCP-Server stellt Ihrem Agenten eine Liste von Tools zur Verfügung, inklusive einer Beschreibung dazu, wann und wie sie verwendet werden sollen. Die Beschreibungen werden dabei von der Person verfasst, die diesen Server geschrieben, also nicht von Ihren IT- und Security-Teams. Ihre Benutzer:innen sehen einen Namen in einem Menü und klicken auf „Genehmigen“, ohne zu prüfen, wer den Server erstellt hat oder was darauf ausgeführt wird.

Und die Beschreibungen sind nicht festgelegt. Wenn die für den MCP-Server verantwortliche Person eine Beschreibung bearbeitet, eine Berechtigung ändert oder ein Tool hinzufügt, übernimmt Ihr Agent dies automatisch, ohne erneute Genehmigung, ohne Überprüfung. Was am Montag lief, ist nicht zwangsläufig das, was am Freitag läuft.

Ein Beispiel: Eine Mitarbeiterin fügt ein Tool für ihren Agenten hinzu. Die für den MCP-Server verantwortliche Person stellt ein Update bereit, das dessen Verhalten ändert. Wenn sich der Agent das nächste Mal verbindet, übernimmt er die neue Funktion ohne Warnung oder eine zweite Genehmigung.

Wie Security-Teams mit Okta for AI Agents Schatten-KI auf Endpoints erkennen und absichern können

Sie können einen Agenten, den Sie noch nie gesehen haben, nicht in seinem Handlungsspielraum einschränken, überprüfen oder widerrufen, und Sie können keinem Agenten vollständig vertrauen, den Sie nicht selbst per Identity Governance verwalten. 

Okta for AI Agents wurde entwickelt, um diese Lücke zu schließen.

1. Endpoint-Erkennung: Erkennung aller Agenten und MCP-Server, die auf dem Endpoint ausgeführt werden

Okta lässt sich in bestehende Endpoint-Sensoren integrieren, die jetzt mit CrowdStrike Falcon EDR verfügbar sind, um KI-Agenten und verbundene MCP-Server zu erkennen. Dazu sind keine zusätzlichen Endpoint-Agenten erforderlich. Damit wird die Erkennungsabdeckung von Okta auf Agenten ausgedehnt, die außerhalb des Browsers ausgeführt werden und ansonsten nicht durch OAuth-Zustimmungen sichtbar würden. Okta Verify ist die nächste Quelle, die wir online bereitstellen, damit die Endpoint-Erkennung nicht von einem bestimmten EDR-Tool abhängt. Unterstützung für weitere EDR-Plattformen ist geplant.

2. Registrierung als vollwertige Identitäten: Zentrale Directory-Registrierung

Agenten werden in Universal Directory neben Ihren anderen nicht-menschlichen Identitäten, KI-Agenten und sogar menschlichen Identitäten registriert. Jeder Agent erhält eine eindeutige Identität. Damit können Sie festlegen, worauf dieser Agent zugreifen kann, und erhalten einen vollständigen Audit-Trail.

3. Identitätszuordnung und -korrelation: Verknüpfung von Agenten mit menschlichen verantwortlichen Personen

Erkannte Agenten werden mit dem jeweiligen authentifizierten menschlichen Account verknüpft, sodass Security-Teams an einem Ort vollständige Transparenz über menschliche und nicht menschliche Entitäten erhalten. Diese Zuordnung bleibt auch bei Änderungen gewahrt: Wenn verantwortliche Personen die Rolle wechseln oder das Unternehmen verlassen und Unteragenten in einer Delegierungskette eingerichtet werden, bleibt der Verantwortungskontext korreliert und geht nicht verloren.

4. Laufzeit-Autorisierung: Durchsetzung von Richtlinien am Ausführungspunkt

Setzen Sie die Zugriffsrichtlinie mit dem Agent Gateway bei jeder Ausführung eines Tool-Aufrufs durch, nicht nur einmalig bei der Einrichtung. Agenten besitzen nur kurzlebige Token anstelle von Standing Credentials, und der Zugriff kann am Gateway sofort widerrufen werden, ohne auf die nächste Zugriffsüberprüfung warten zu müssen, die eventuelle Änderungen erkennt.

5. Fortlaufende Governance für den Zugriff: Zugriffsüberprüfungen und Zugriffsentzug

Führen Sie regelmäßige Zugriffsüberprüfungen durch, die neben menschlichen Identitäten auch Agenten umfassen, damit Security-Teams gegenüber Auditor:innen nachweisen können, dass der Zugriff jedes Agenten überprüft und genehmigt wurde. Und wenn ein Agent abschweift oder kompromittiert wird, deaktiviert ihn ein Not-Aus-Schalter und unterbindet jeden weiteren Zugriff auf verbundene Systeme, mit denen er interagiert.

Wie Sie die Kontrolle über Ihre Unternehmens-KI übernehmen

Lesen Sie das Konzept für den sicheren Einsatz von Agenten in Unternehmen, um mehr darüber zu erfahren, wie Sie Ihre Unternehmens-KI sicher skalieren können.

Verfügbarkeit: Die Funktion Shadow AI Agent Discovery for Endpoints ist für Kund:innen von Identity Security Posture Management und Okta for AI Agents über die CrowdStrike Falcon EDR-Integration jetzt im Early Access verfügbar. Wenn Sie CrowdStrike bereits ausführen, ist der vorhandene Sensor die Quelle und es gelangen keine neuen Elemente auf den Endpoint.

Dieses Dokument dient nur zu allgemeinen Informationszwecken. Die hier enthaltenen Informationen stellen keine Rechts-, Datenschutz-, Sicherheits-, Compliance- oder Geschäftsberatung dar. Es liegt in Ihrer Verantwortung, sich mit Blick auf die Sicherheit, den Datenschutz, die Compliance und das Business beraten zu lassen. Jegliche Erwähnung zukünftiger Produkte, Funktionen, Funktionalitäten oder Zertifizierungen in diesem Blog dient ausschließlich zu Informationszwecken. Es handelt sich nicht um Zusagen zur Bereitstellung und sollte nicht als Grundlage für Kaufentscheidungen herangezogen werden. © Okta, Inc. und/oder Partner 2026.