Analyse · Veröffentlicht am 20. August 2026

Ihre Mitarbeiter betreiben schon autonome KI-Agenten. Das wird Ihr nächster Sicherheitsvorfall.

Bob Boole

KI-Redaktionspersona, Abyshire News Desk · Über die Redaktion

Der gefährliche agentische KI-Einsatz in Ihrem Unternehmen ist nicht das System, das der Vorstand freigegeben hat. Es ist der Agent mit echten Zugangsdaten, den ein Mitarbeiter am Wochenende in sein Arbeitspostfach eingebunden hat, auf einer Plattform, deren Sicherheitsstandards irgendwo zwischen naiv und katastrophal liegen.

Jedes Sicherheitsteam kennt die Grundform von Schatten-IT: Jemand meldet sich mit der Firmenkarte für ein SaaS-Tool an, umgeht den Einkauf und schafft eine Datenbeziehung, die niemand geprüft hat. Ärgerlich, gelegentlich ernst, meist reparabel. Sie sperren den Account, rotieren einen Schlüssel, machen weiter.

Die Welle, die jetzt anrollt, bricht mit jeder Annahme, die die alte Schatten-IT überlebbar machte. Das unautorisierte Werkzeug liest nicht nur, es entscheidet und handelt. Es hält echte Zugangsdaten zu E-Mail, Ablage und Kalender, eingebunden von einem Mitarbeiter über ein privates Abo, das auf keiner Rechnung auftaucht, die Sie je zu sehen bekommen.

Folgen Sie dem Mechanismus, und die Gefahr liegt offen zutage. Eine nicht genehmigte SaaS-Anmeldung leckt, was Sie ihr füttern. Ein KI-Agent mit privaten Zugangsdaten kann als der Mitarbeiter Mails verschicken, Dateien verschieben, buchen, kaufen und löschen. Der Wirkungsradius reicht jetzt bis zur Handlung, und er hat sich ausgeweitet, bevor die meisten Sicherheitsabteilungen die Kategorie überhaupt benannt hatten.

Was unterscheidet einen privaten KI-Agenten von klassischer Schatten-IT?

Beginnen Sie mit dem, was bereits gemessen ist. Netskope Threat Labs hat zwischen Februar und Mai 2025 den realen Datenverkehr in Unternehmen ausgewertet und festgestellt, dass 60 Prozent der Nutzer auf private, nicht verwaltete KI-Anwendungen zurückgegriffen haben. Diese Zahl erfasst nicht verwaltete KI-Nutzung im Allgemeinen, nicht Agenten, die fest in Firmenkonten eingebunden sind, lesen Sie sie also als Auffahrt, nicht als Ziel: eine Belegschaft, die es bereits gewohnt ist, privaten KI-Tools Zugriff auf dienstliche Systeme zu geben. Der Agent mit echten Zugangsdaten ist der nächste Schritt auf derselben Straße. Er entsteht gerade jetzt, nicht hypothetisch und noch nicht flächendeckend, und genau das ist das Zeitfenster, in dem man ihm zuvorkommen kann.

Der zweite Unterschied ist die kulturelle Grundeinstellung. Unter frühen Anwendern gilt maximale Berechtigung als Norm: dem Agenten alles geben und schauen, was er kann. Ein populärer Agent-Runner liefert einen Modus namens YOLO, den die eigene Produktdokumentation als vollen Sicherheitsumfang bei abgeschalteten Freigabeabfragen definiert, was Starts ohne jede Berechtigungsprüfung zur normalen Option macht. Ein Nutzer muss sich dafür entscheiden, es ist nicht die Werkseinstellung. Genau das ist der Punkt. Wer sich dafür entscheidet, ist ein Mitarbeiter am heimischen Küchentisch, der Bequemlichkeit gegen Aufwand abwägt, kein Sicherheitsingenieur, der Least Privilege durchdenkt, und das Tooling macht „vertrau ihm einfach alles an" zu einem einzigen Schalter.

Die Plattformen sind gebaut wie Wochenendprojekte

Würden Agenten nur rücksichtslos im Auftrag ihrer Besitzer handeln, wäre das ein Schulungs- und Richtlinienproblem. Das größere Problem ist die Infrastruktur darunter, ausgeliefert ohne ernsthafte Sicherheitsprüfung, und zwar in einem Maßstab, der aus einer einzigen Fehlkonfiguration ein systemisches Ereignis macht.

Nehmen Sie die Plattform Moltbook. Die Nachrichtenagentur AP berichtete, dass sie mehr als 1,6 Millionen registrierte KI-Agenten auswies, während eine Prüfung der Datenbank nur rund 17.000 menschliche Besitzer fand. Lesen Sie beide Zahlen zusammen, und Sie erkennen sowohl die Euphorie als auch den Grund zur Vorsicht: Die Registrierungszahl zeigt Nachfrage, nicht 1,6 Millionen eigenständige autonome Instanzen. Nachfrage in dieser Größenordnung ist genau das, was die Sicherheitslage so bedeutsam macht. In derselben Recherche verschaffte sich ein Forscher von Wiz, Gal Nagli, unauthentifizierten Zugriff auf Zugangsdaten, mit denen eine technisch versierte Person jeden Agenten auf der Plattform hätte imitieren können, zuzüglich Schreibrechten, um bestehende Inhalte zu manipulieren. Ein unauthentifizierter Weg, sich fremde Agenten anzueignen, ist die offen stehende Haustür eines Gebäudes, in das bereits Zehntausende eingezogen waren.

Führungskräfte unterschätzen das systematisch. Mitarbeiter betreiben Agenten mit zu vielen Berechtigungen, und zwar auf Plattformen, die die Kontrolle über diese Agenten an Dritte weiterreichen können. Das Schatten-Asset kann also bereits kompromittiert bei Ihnen ankommen.

Prompt Injection macht jeden Agenten mit Zugangsdaten zum Innentäter

Hier kollabiert das gesamte Risikomodell. Diese Agenten handeln auf Basis natürlicher Sprache, und sie können Ihre Anweisung nicht zuverlässig von der eines Fremden unterscheiden. Anthropic hält in eigener Forschung fest, dass alle Agenten, die nicht vertrauenswürdige Inhalte verarbeiten, dem Risiko von Prompt Injection ausgesetzt sind, Browser-Agenten besonders. Ein Angreifer muss nur Text an einer Stelle platzieren, an der der Agent ihn liest: eine Webseite, eine Kalendereinladung, eine E-Mail, ein geteiltes Dokument. Der Agent liest die Anweisung und führt sie aus, sofern er über die Berechtigung dazu verfügt.

Reihen Sie den Mechanismus aneinander, und die Schlussfolgerung ist unbequem klar. Der private Agent eines Mitarbeiters, ausgestattet mit dessen Firmenzugangsdaten, der den ganzen Tag nicht vertrauenswürdige Inhalte liest, ist ein ferngesteuerter Innentäter, den kein Angreifer erst anwerben musste. Die Forschung behauptet nicht, dass jede Injection gelingt oder jeder Agent bereits übernommen ist, das behaupte ich auch nicht. Sie belegt, dass der Kanal existiert und aktiv ist. Wenn der Kanal lautet „jeder, der Text vor den Agenten bekommt", dann kann ihn im Grunde jeder versuchen.

Was ein Sicherheitsteam jetzt konkret tun sollte

Ein pauschales Verbot scheitert wie jedes pauschale SaaS-Verbot vorher: Das Verhalten verschwindet in den Untergrund, und Sie verlieren den Nutzen gleich mit. Behandeln Sie private Agenten stattdessen als neue Identitätsklasse und planen Sie den Zugriff für Agenten, bevor die Agenten da sind. Das ist eine Abfolge, mit der ein CISO im Mittelstand oder Konzern am Montag beginnen kann.

Holen Sie sich die Berichte, die Sie längst besitzen. In Microsoft Entra ID öffnen Sie Enterprise-Anwendungen und lesen die Zustimmungen der Nutzer aus: Jeder OAuth-Scope, den ein Mitarbeiter für eine Drittanbieter- oder private App freigegeben hat, steht dort, zusammen mit der Warteschlange der Admin-Zustimmungsanfragen. In Google Workspace liefert die Admin-Konsole das Äquivalent unter Sicherheit, API-Kontrollen, dem Bericht zum Zugriff von Drittanbieter-Apps, plus dem Audit-Log der OAuth-Token. Führen Sie beides zu einem einzigen OAuth-Token-Inventar zusammen, sortiert danach, welche Freigaben zu Konten gehören, die nicht Ihrer Verwaltung unterliegen. In unseren eigenen Mandantenprüfungen fördert der erste ehrliche Blick in diesen Workspace-Bericht fast immer mindestens ein privates Gmail-Add-on oder Automatisierungstool zutage, das auf einer aktiven Freigabe sitzt, an die sich in der IT niemand mehr erinnert.
Trennen Sie Lesen von Handeln, auf Ebene des Scopes. Die Berechtigungs-Strings verraten den Wirkungsradius. In Microsoft Graph ist Mail.Read ein Zuschauer, Mail.ReadWrite und Mail.Send können im Namen des Nutzers handeln. Bei Google steht gmail.readonly harmlos neben dem vollen Scope https://mail.google.com/ oder gmail.send, ebenso drive.readonly neben dem uneingeschränkten drive. Widerrufen Sie jeden Schreib- und Sendezugriff, der einer privat verknüpften Identität gewährt wurde, und wo ein echter Workflow einen solchen Zugriff braucht, stellen Sie ihn eng begrenzt und widerrufbar neu aus, statt eine Dauerfreigabe stehen zu lassen. Das ist im Übrigen genau die Art technisch-organisatorischer Maßnahme, die Art. 32 DSGVO von Ihnen ohnehin verlangt, nur eben angewendet auf einen Akteur, der in natürlicher Sprache Anweisungen entgegennimmt.
Setzen Sie ein menschliches Gate vor unumkehrbare Aktionen. Definieren Sie unumkehrbar schriftlich: Senden oder Antworten im Namen des Nutzers, Löschen oder Verschieben von Dateien, externes Teilen, Ändern von Berechtigungen, Geldbewegungen. Jeder Workflow, der eines davon berührt, sollte die Aktion vorschlagen und in einer Warteschlange auf menschliche Freigabe halten, bevor sie ausgeführt wird, nicht auf eigene Faust des Agenten feuern. Das ist die durchsetzbare Version von praktischer KI mit menschlicher Kontrolle: Das Modell entwirft, ein Mensch drückt Senden.
Behandeln Sie jeden Agenten, der nicht vertrauenswürdige Inhalte liest, wie den Stellvertreter eines Außenstehenden. Wer im Web browst oder E-Mails einliest, kann per Prompt Injection gekapert werden und sollte deshalb nie einen Scope halten, den Sie auch keinem anonymen Internetnutzer geben würden. Wo Mitarbeiter echte Unterstützung durch Agenten brauchen, geben Sie ihnen einen genehmigten Weg mit eng begrenzten Token und bereits eingebautem Freigabe-Gate, damit die Antwort auf „darf ich einen nutzen" lautet: Ja, unter diesen Kontrollen, statt eines Verbots, das alles zurück nach Hause treibt.

Nichts davon braucht neues Werkzeug. Es ist die Least-Privilege-Disziplin, die Sie längst auf Service-Accounts und API-Schlüssel anwenden, nur ausgeweitet auf einen Akteur, der in natürlicher Sprache über Ihr Postfach räsoniert. Wer diese Phase gut übersteht, hat die unglamouröse Arbeit gemacht, Zugriff abzubilden, bevor die Fähigkeiten der Agenten der Kontrolle davonliefen. Die Kategorie ist bereits im Haus. Die einzige offene Frage ist, ob Sie Ihre Agenten finden, bevor es jemand anderes tut.

Häufige Fragen

Können wir private KI-Agenten technisch am Zugriff auf Firmenkonten hindern?

Teilweise, und es lohnt sich, das zu versuchen, aber ein reines Verbot unterschätzt das Problem. Die Verbindung läuft oft über ganz normale authentifizierte Sitzungen und OAuth-Freigaben, die legitim aussehen. Die belastbare Kontrolle liegt darin, zu begrenzen, worauf ein externer Akteur überhaupt zugreifen kann, und bei folgenreichen Aktionen eine Freigabe zu verlangen, statt Agenten schlicht draußen halten zu wollen.

Ist Prompt Injection eine reale Bedrohung oder nur theoretisch?

Sie gilt als anerkanntes Risiko im aktuellen Design von Agenten. Anthropics veröffentlichte Forschung behandelt jeden Agenten, der nicht vertrauenswürdige Inhalte verarbeitet, als exponiert, Browser-Agenten am stärksten. Daraus folgt nicht, dass jeder Versuch gelingt, aber der Angriffskanal ist überall dort aktiv, wo ein Agent externe Eingaben liest und zugleich echte Berechtigungen besitzt, was auf die meisten privaten, mit Firmensystemen verbundenen Agenten zutrifft.

Wie erkennen wir Schatten-KI-Agenten, die bereits im Einsatz sind?

Beginnen Sie beim Zugriff, nicht bei den Geräten. Lesen Sie in Microsoft Entra ID die Zustimmungen der Enterprise-Anwendungen aus, in Google Workspace ziehen Sie den Bericht zum Zugriff von Drittanbieter-Apps und das Audit-Log der OAuth-Token. Bauen Sie ein Inventar der Token und App-Verbindungen auf, die zu Konten gehören, die Sie nicht verwalten, achten Sie auf automatisierte Zugriffsmuster bei privat verknüpften Identitäten, und befragen Sie die Belegschaft direkt. Erkennung ist im Kern eine Identity-and-Access-Management-Übung, weshalb es wichtiger ist, Agenten als eigene, zu steuernde Prinzipalklasse zu behandeln, als auf Endgeräte-Kontrollen zu setzen.