So finden Sie die KI-Agenten, die Ihre Mitarbeiter schon nutzen

Um die KI-Agenten zu finden, die Ihre Mitarbeiter bereits nutzen, sollten Sie an drei Stellen suchen, bevor Sie eine Richtlinie schreiben: auf dem Laptop (Agent-Konfigurationsordner und Listening Ports), im Netzwerk (Traffic zu den APIs der Modell-Anbieter) und beim Identity Provider (OAuth-Einwilligungen und API-Keys). Microsofts Defender for Endpoint führt mittlerweile ein Inventar der KI-Agenten auf verwalteten Geräten; die Support-Matrix, zuletzt aktualisiert im Oktober 2026, listet 60 davon für Windows. Dieser Leitfaden zeigt, wie Sie denselben Scan mit oder ohne Microsoft-Tooling durchführen.

Der Anbieter, der das Inventar verkauft, schlägt gleichzeitig Alarm. „Unfortunately, frontier models, regardless of their origin, cannot be trusted,“ schrieb Hayete Gallot, verantwortlich für Microsofts Security-Geschäft, am 19. Oktober 2026 in einem Microsoft-Blogbeitrag, wie TechCrunch berichtete. Über die Agent-Erkennung von Defender schreibt derselbe Bericht, sie „can find up to 60 types of agents that employees bring into the workplace, including Claude Code, Codex, and OpenClaw.“ Die Support-Matrix selbst vom 7. Oktober 2026 listet 60 Agenten für Windows, die beiden Zahlen passen also zusammen.

Warum unterscheiden sich Schatten-KI-Agenten von Schatten-KI-Chat?

Ein Chatbot in einem Browser-Tab beantwortet Fragen. Ein Agent auf einem Laptop liest Dateien, führt Befehle aus und ruft andere Systeme mit den Zugriffsberechtigungen des Mitarbeiters auf. Beim Chat verlassen Daten das Unternehmen über das, was jemand in ein Textfeld kopiert. Bei einem Agenten verlassen Daten das Unternehmen auch über die Tools des Agenten, ohne dass jemand etwas kopiert, weshalb eine Chat-Richtlinie hier nicht ausreicht.

Der OpenClaw Hardening Guide der Cloud Security Alliance vom 31. März 2026 zitiert Token Security: „approximately 22 percent of employees among its enterprise customer base were running OpenClaw, overwhelmingly without IT knowledge or approval.“

Der gleiche Leitfaden stellt fest: „OpenClaw binds its gateway to 0.0.0.0:18789 by default.“ Diese Adresse bedeutet, dass jede Netzwerkschnittstelle genutzt wird, sodass andere Maschinen im selben Netzwerk das Gateway des Agenten erreichen können, nicht nur der Laptop, auf dem er läuft. Ein persönlicher Assistent eines Mitarbeiters wird so zu einem nicht registrierten Dienst in Ihrem Netzwerk, mit eigenen Credentials und ohne die Kontrollen, die Sie für nicht-menschliche Identitäten anwenden.

Wo hinterlassen KI-Agenten Spuren auf einem Laptop?

Die meisten KI-Agenten speichern einen Konfigurationsordner im Home-Verzeichnis des Benutzers. Diese Konfiguration listet die Tools (MCP-Server), die der Agent aufrufen darf. Das Finden der Ordner zeigt Ihnen, wer welchen Agenten nutzt. Das Lesen der MCP-Konfiguration zeigt, auf welche Daten jeder Agent zugreifen kann. Die folgenden Pfade stammen aus der Dokumentation der jeweiligen Hersteller.

Der CSA-Leitfaden gibt für OpenClaw denselben Rat: Die Endpoint-Detection „should be configured to identify running OpenClaw processes, listening WebSocket ports (default 18789), and the presence of the ~/.clawdbot or ~/.openclaw directory structures.“ Jedes EDR kann nach Ordnernamen und Listening Ports suchen, sodass der erste Scan kein neues Produkt erfordert.

Schritt 1: Endpunkte nach Agent-Ordnern und Ports scannen

Führen Sie eine EDR- oder MDM-Abfrage über alle verwalteten Laptops für die Ordnernamen in der Tabelle und für jeden Prozess aus, der auf Port 18789 lauscht. Exportieren Sie den Host, den Benutzer und das Datum der letzten Änderung jedes Ordners. Ein Ordner, der diese Woche bearbeitet wurde, gehört wahrscheinlich zu einem aktiven Agenten; einer, der seit dem Frühjahr unberührt ist, eher zu einem vergessenen Test.

Wenn Sie Microsoft Defender for Endpoint nutzen, übernimmt dessen Agent-Inventar vieles davon für Sie, allerdings mit zwei Einschränkungen aus Microsofts eigener Dokumentation. Die Seite zum Runtime-Schutz ist noch als „(Preview)“ markiert. Und laut Support-Matrix basiert die Erkennung auf Aktivität: „Installing an agent doesn’t by itself guarantee that the agent appears in the local AI agent inventory.“ Ein installierter, aber am Tag der Prüfung inaktiver Agent wird nicht angezeigt.

Unserer Erfahrung nach sollten Sie die Ergebnisse nach Benutzer und nicht nach Host sortieren. Ein Entwickler betreibt oft drei Agenten; das Gespräch muss daher mit der Person und nicht mit dem Laptop geführt werden.

Schritt 2: Proxy- und DNS-Logs auf Modell-APIs prüfen

KI-Agenten kommunizieren mit Modell-Anbietern. Suchen Sie in Ihren Proxy- oder DNS-Logs nach den API-Hosts der Anbieter, zum Beispiel api.anthropic.com, welche in den Netzwerkanforderungen von Claude Code für API-Anfragen gelistet sind, sowie api.openai.com, und listen Sie die internen Hosts auf, die diese aufrufen. Ein Host mit stetigem API-Traffic außerhalb der Bürozeiten deutet auf einen Agenten hin, nicht auf eine tippende Person.

Browser-Chat-Apps greifen auf dieselben Anbieter zu. Behandeln Sie einen Treffer daher als Hinweis, nicht als Beweis, und gleichen Sie ihn mit Schritt 1 ab. Eine Lücke bleibt: Ein Agent, der auf selbstgehostete Modelle wie Ollama auf demselben Laptop zeigt, tätigt keine externen API-Aufrufe. Für diesen Agenten ist Schritt 1 das einzige Netz.

Schritt 3: OAuth-Einwilligungen und Spesenberichte prüfen

KI-Agenten benötigen Credentials, und Credentials hinterlassen Spuren. Prüfen Sie, welchen Drittanbieter-Apps Mitarbeiter in Ihrem Identity Provider zugestimmt haben, und fragen Sie in der Finanzabteilung nach Kreditkarten- und Spesenpositionen von KI-Anbietern. Ein API-Key, der über eine private Karte bezahlt und als Auslage erstattet wurde, ist ein starkes Indiz für einen nicht genehmigten Agenten.

• Microsoft Entra ID: Enterprise apps > All applications > [app] > Permissions, dann den Tab User consent, laut Microsoft. Das Widerrufen dieser Einwilligungen erfordert Graph oder PowerShell; im Portal geht das nicht.
• Google Workspace: Admin console > Security > Access and data control > API controls, dann die Liste „Accessed apps“, die alle Apps auflistet, die auf Google-Daten zugegriffen haben.

Unserer Ansicht nach ist dies der günstigste Schritt und derjenige, den Teams oft auslassen. Eine Einwilligung (Consent) für einen Agenten ist auch ein Token, den jemand stehlen kann, was das Risiko darstellt, das wir bei gestohlenen Agent-Session-Tokens behandelt haben.

Schritt 4: MCP-Server inventarisieren, nicht nur die Agenten

Der Agent ist der Motor; die MCP-Server sind seine Hände. Das Risiko liegt darin, womit jeder Agent verbunden ist: einem Code-Repository, einem CRM, einem E-Mail-Konto. Listen Sie die MCP-Server aus jeder in Schritt 1 gefundenen Konfigurationsdatei auf und bewerten Sie diese nach den Daten, die sie exponieren. Ein Coding-Agent mit nur einem lokalen Dateiserver ist ein anderes Problem als einer, der mit der Kundendatenbank verdrahtet ist.

Die Microsoft-Matrix hat eine eigene Spalte „Discovers MCP“. Prüfen Sie auch, woher jeder Server stammt: Ein MCP-Server oder Skill, der aus einem öffentlichen Marketplace installiert wurde, birgt das Supply-Chain-Risiko, das wir bei Agent-Skill-Marketplaces beschrieben haben.

Wie sollten Sie mit den gefundenen Agenten verfahren?

Registrieren, einschränken und protokollieren Sie sie; beginnen Sie nicht mit einem Verbot. Unserer Meinung nach verschiebt ein Verbot die Agenten auf private Laptops, wo Sie gar nichts mehr sehen, und die Personen, die sie am meisten nutzen, sind oft diejenigen, die Sie behalten wollen.

Satya Nadella fasste das Prinzip in einem Blogbeitrag in einem Satz zusammen, den TechCrunch zitiert: „we need to separate the supply of intelligence from the authority over it.“ In der Praxis bedeutet das, dass jeder registrierte Agent eine eigene Identität und nur die Berechtigungen erhält, die seine Aufgabe erfordert, und jede Schreibaktion hinter einem Genehmigungsschritt außerhalb des Modells steht.

Die eigenen Kontrollen von Microsoft folgen derselben Linie. Laut TechCrunch hat Microsoft „added features that limit agents’ access to data and systems, and dynamically adjust their agent permissions based on the task,“ einschließlich „requiring human approval if an agent appears to be making risky decisions.“ Sie können dasselbe ohne Microsoft aufbauen: eine Allowlist für Schreibaktionen für Agenten mit Webzugriff und Guardrails für Coding-Agenten mit Shell-Zugriff.

Der erste Scan passt auf eine Seite:

• Eine Endpoint-Abfrage nach Agent-Ordnern und Port 18789.
• Eine Proxy- oder DNS-Suche nach API-Hosts der Modell-Anbieter.
• Eine Überprüfung der Einwilligungen in Entra ID oder Google Workspace sowie der Spesenpositionen.
• Eine Liste der MCP-Server pro Agent, sortiert nach den Daten, auf die sie zugreifen.

Führen Sie diesen Prozess dann alle 30 Tage erneut durch. Es kommen laufend neue Agenten hinzu, und die 60 aus Microsofts Oktober-Matrix bleiben nicht die letzte Zahl.

Weiterführende Lektüre

• KI-Agenten als nicht-menschliche Identitäten absichern
• Wann Sie keinen KI-Agenten einsetzen sollten
• Prompt Injection lässt sich nicht patchen