Agentische Schatten-KI kümmert der Name Super Intelligence nicht

Am 29. September 2026 unterzeichnete das Weiße Haus die Executive Order 14434 mit dem Titel „Inaugurating the Era of Super Intelligence“. Die Anordnung weist die US-Bundesbehörden an, in der offiziellen Kommunikation „Super Intelligence“ oder „SI“ statt „AI“ zu verwenden. Sie versucht, einen Begriff zu ändern. Sie definiert keine neue Technologie und schafft keine neue Risikokategorie. Es gibt also keine Schatten-Super-Intelligence, auf die man sich vorbereiten müsste.

Das Risiko, das bereits besteht, ist die agentische Schatten-KI: autonome Agenten, die ohne Freigabe oder Aufsicht laufen. Gemeint sind KI-Systeme, die in Ihrer Organisation arbeiten, ohne dass ein Mensch jede Aktion genehmigt, und die eigene Zugangsdaten besitzen, statt das Login einer Person zu nutzen. Einem solchen Agenten ist es egal, wie die US-Regierung ihn nennt. Der Agent hat weiterhin das OAuth-Token, und das Token funktioniert weiterhin, ob in den Unterlagen nun AI oder Super Intelligence steht.

Was die „Super Intelligence“-Anordnung tatsächlich ändert (nichts)

Die Executive Order 14434 ist eine Terminologievorgabe für die US-Exekutive. Sie weist Behörden an, in offiziellen, nicht gesetzlichen Dokumenten „Super Intelligence“ („SI“) statt „AI“ zu schreiben. Sie begründet keine Pflichten für private Unternehmen und sieht keine Sanktionen vor. Außerdem setzt sie ein 60-tägiges Verfahren in Gang, an dessen Ende eine neue gesetzliche Definition stehen könnte.

Präsident Trump unterzeichnete die Anordnung am 29. September 2026. Sie wurde am 2. Oktober im Federal Register veröffentlicht (91 Fed. Reg. 63129). Die maßgeblichen Bestimmungen:

• Abschnitt 1 legt die Politik fest: Soweit gesetzlich zulässig, verwendet die Exekutive „SI“ anstelle von „AI“ und wird die alten Begriffe in keinem einschlägigen Kontext „anerkennen“.
• Abschnitt 2(a) wendet die Regel auf offizielle Korrespondenz, öffentliche Kommunikation, Websites, Berichte, Strategiedokumente und andere nicht gesetzliche Dokumente an.
• Abschnitt 2(b) stellt klar, dass dieser Abschnitt keine Änderung bestehender Verordnungen, präsidialer Maßnahmen, Verträge, Fördermittelbescheide oder anderer historischer Dokumente verlangt.
• Abschnitt 3(a) definiert „SI“ durch Verweis auf die bestehende gesetzliche Definition von AI in 15 U.S.C. § 9401(3). Die Definition gilt, bis sie durch eine präsidiale Maßnahme oder ein Gesetz des Kongresses ersetzt wird.
• Abschnitt 3(b) gibt dem wissenschaftlichen Berater des Weißen Hauses 60 Tage Zeit, einen neuen Gesetzestext vorzuschlagen, der erst durch einen separaten Beschluss des Kongresses wirksam würde.
• Abschnitt 4(c) stellt fest, dass die Anordnung keine einklagbaren Rechte begründet.

Strenger Wortlaut, geringe Rechtswirkung

Die Sprache der Anordnung ist strenger als ihre Wirkung. Laut Abschnitt 1 wird die Exekutive den Begriff AI in keinem einschlägigen Kontext „anerkennen“. Dennoch verwendet die Anordnung selbst den Ausdruck „artificial intelligence“ und verankert ihre Definition von SI in 15 U.S.C. § 9401(3). Jede Pflicht gilt nur „soweit gesetzlich zulässig“ und nur für nicht gesetzliche Dokumente. Gesetze, Verordnungen, Verträge und Fördermittelbescheide sprechen also weiterhin von AI.

Abschnitt 3(a) sorgt dafür, dass SI genau das bedeutet, was AI heute bedeutet, und Abschnitt 4(c) begründet keine einklagbaren Rechte. Die Juristen von Arnold & Porter weisen darauf hin, dass die Anordnung keine Sanktions- oder Durchsetzungsbestimmung enthält. Der Post des Präsidenten vom 8. Oktober, der jeden, der „Artificial Intelligence“ sagt, zum „FEIND“ erklärt, ging weiter als die Anordnung. Die Anordnung nennt dafür keine Konsequenzen. Die Behörden ändern ihr Vokabular. Die Technologie und ihre Regulierung bleiben, wie sie waren.

Das ist der gesamte Geltungsbereich der Anordnung: eine Kommunikationsübung und eine Sprachregel für die eigenen Unterlagen einer einzigen Regierung. Den Agenten, die bereits mit Produktivsystemen verbunden sind und die Zugangsdaten besitzen, die sie bereits besitzen, ist es egal, welches Wort in diesen Unterlagen steht.

Was agentische Schatten-KI tatsächlich ist

Agentische Schatten-KI bezeichnet den nicht genehmigten oder unbeaufsichtigten Einsatz autonomer Agenten in einer Organisation. Diese Agenten planen Aktionen selbstständig und verketten sie, besitzen eigene Zugangsdaten und laufen, ohne dass ein Mensch jeden Schritt genehmigt. Anders als bei Schatten-IT oder allgemeiner Schatten-KI muss niemand an einer Tastatur sitzen, damit sie handeln.

Klassische Schatten-IT entsteht, wenn ein Mitarbeiter ein Tool einführt, etwa eine App zur Dateisynchronisierung oder ein Projektmanagement-Tool, ohne den Beschaffungsprozess zu durchlaufen. Allgemeine Schatten-KI, um die es in den meisten Beiträgen zur Governance geht, entsteht, wenn ein Mitarbeiter Daten in einen öffentlichen Chatbot einfügt. In beiden Fällen trifft eine Person im Moment eine Entscheidung, und beide tauchen früher oder später irgendwo auf: in einer Spesenabrechnung, einem SaaS-Nutzungsprotokoll, einem Eintrag im Browserverlauf.

Agentische Schatten-KI funktioniert anders. Ein Agent hinterlässt nur ein einziges Mal eine Spur. Jemand verbindet einen Slack-Bot, eine Integration für Vertriebstools oder ein Skript, das ein Code-Repository überwacht, und von da an handelt der Agent nach seinem eigenen Zeitplan. Er authentifiziert sich mit seinem eigenen API-Schlüssel, OAuth-Token oder Dienstkonto. Ein einmal ausgestelltes Token funktioniert so lange, bis jemand es widerruft. Es gibt also keine spätere menschliche Entscheidung, die jemand bemerken oder melden könnte.

Warum MCP das Problem vergrößert

Agenten, die auf dem Model Context Protocol (MCP) aufbauen, greifen auf Tools und Datenquellen mit den Zugangsdaten zu, mit denen die Integration konfiguriert wurde. Sie erben deren vollen Zugriff. Dieser Zugriff ist häufig weiter gefasst als die eine Aufgabe, für die der Agent gebaut wurde, und niemand überprüft den Berechtigungsumfang noch einmal, sobald die Integration funktioniert.

Manche Anbieter nennen diese Systeme „Shadow Agents“. Dieser Artikel verwendet durchgehend den Begriff „agentische Schatten-KI“. Beide Bezeichnungen beschreiben dasselbe Problem: autonome Agenten, die niemand inventarisiert hat und deren Zugangsdaten niemand überwacht.

Warum agentische Schatten-KI gefährlicher ist als Schatten-IT

Agentische Schatten-KI ist schwerer einzudämmen als Schatten-IT, weil Agenten schneller mit echten Systemen verbunden werden, als Organisationen Verantwortliche benennen, Zugangsdaten einschränken oder sie inventarisieren. Schatten-IT braucht eine Person, die das Tool weiter nutzt. Ein KI-Agent arbeitet weiter, auch wenn sein Ersteller längst etwas anderes macht.

Die Lücke zeigt sich in drei veröffentlichten Zahlen.

• JumpCloud hat festgestellt, dass 83 % der Organisationen mehr nicht-menschliche Identitäten (NHIs), also Dienstkonten, API-Schlüssel und Zugangsdaten von Agenten, verwalten als menschliche Benutzer. Nur 21 % verfügen über eine Zugriffs-Governance für diese Identitäten.
• Cyberhaven Labs verzeichnete zwischen Februar 2025 und Februar 2026 einen Anstieg um 509 % gegenüber dem Vorjahr bei der Nutzung endpunktbasierter KI-Agenten in Unternehmen. Allein Coding-Assistenten wuchsen um 357 %.
• Gartner prognostizierte im August 2025, dass bis Ende 2026 40 % der Unternehmensanwendungen aufgabenspezifische KI-Agenten enthalten würden, gegenüber weniger als 5 % im Jahr 2025.

Die Einführung beschleunigt sich, und die Governance erfasst nur einen kleinen Teil der beteiligten Identitäten. Die meisten Teams können die Frage „Worauf kann dieser Satz Zugangsdaten zugreifen?“ nicht auf Anhieb beantworten. Ohne diese Antwort kann niemand die Zugangsdaten einschränken, rotieren oder widerrufen.

Was eine Lücke kostet

Die Kosten eines Datenlecks beziffern das Problem in Dollar. Der Cost of a Data Breach Report 2026 von IBM veranschlagt die durchschnittlichen weltweiten Kosten eines Datenlecks auf 4,99 Millionen US-Dollar, ein Rekordwert und ein Anstieg um 12 % gegenüber dem Vorjahr. IBM ordnet diese Zahl nicht Agenten zu. Lesen Sie sie daher als Preis dieses Fehlermusters, nicht als Preis der agentischen Schatten-KI.

Zugangsdaten ohne Verantwortlichen sind derselbe Fehler, ob eine Person oder ein Agent sie besitzt. Der Unterschied liegt in der Erkennung. Eine Person, die ihren Zugriff missbraucht, hinterlässt ein Anmeldeereignis. Ein Agent mit einem gültigen Token erzeugt Datenverkehr, der wie Routineautomatisierung aussieht.

Klar gesagt: Organisationen bauen nicht-menschliche Identitäten (NHIs) auf und verbinden Agenten mit Produktivsystemen, lange bevor sie Verantwortlichkeiten dokumentieren, Berechtigungen konsequent einschränken und ein Monitoring einrichten.

Wie Agent Sprawl in Organisationen entsteht

Sieben Wege führen in gesteuerten Organisationen zu Agent Sprawl (dem Wildwuchs von KI-Agenten): Entwicklerwerkzeuge, Pilotprojekte ohne Ende, verwaiste Agenten, Feature-Flags von Anbietern, Low-Code-Plattformen, persönliche Agenten und Teams von Drittanbietern. Jeder dieser Wege endet mit einem Agenten, der Zugangsdaten besitzt, die kein zentraler Verantwortlicher erfasst hat.

1. Entwicklerwerkzeuge. Coding-Assistenten und lokal betriebene MCP-Server arbeiten mit den Repository-Tokens und Cloud-Schlüsseln, die bereits auf dem Rechner eines Entwicklers liegen. Sie laufen auf dem Endpunkt, deshalb führt keine SaaS-Admin-Konsole sie auf.
2. Ein Pilotprojekt, das nie endete. Ein Team richtet einen Agenten ein, um eine lästige Aufgabe zu erledigen. Er spart Stunden, Kollegen verlassen sich auf ihn, und niemand plant die Entscheidung, ihn freizugeben oder abzuschalten. Der Schlüssel, mit dem er erstellt wurde, behält seinen ursprünglichen Berechtigungsumfang.
3. Verwaiste Agenten. Die Person, die einen Agenten gebaut hat, wechselt die Rolle oder verlässt das Unternehmen, und der Agent läuft weiter. Die Deaktivierung ihres Verzeichniskontos widerruft nicht unbedingt die OAuth-Berechtigungen und API-Schlüssel, die sie erstellt hat. Prüfen Sie, wie sich jedes Ihrer Systeme verhält.
4. Ein Feature-Flag in einem vertrauenswürdigen Tool. Ein Anbieter liefert mit einem Routine-Update einen Agenten aus und aktiviert ihn für jeden Mandanten. Der Agent greift über Verbindungen auf Daten zu, die das Produkt bereits besitzt. Die hinterlegte Sicherheitsprüfung beschreibt das Produkt so, wie es vor einem Jahr war.
5. Low-Code-Plattformen für Agenten. Fachanwender stellen Agenten in Workflow-Plattformen zusammen, für die das Unternehmen bereits Lizenzen hat. Jede Verbindung des Agenten wird unter der Identität seines Erstellers angelegt. Der Administrator der Plattform sieht daher Apps, nicht die Zugangsdaten dahinter.
6. Ein persönlicher Agent. Ein Mitarbeiter verbindet einen Assistenten mit seinem Posteingang, Kalender oder Code-Repository und lässt ihn mit seinen eigenen Berechtigungen handeln. Diese Berechtigungen wurden für die gesamte Tätigkeit der Person erteilt, daher reicht der Agent viel weiter, als seine eine Aufgabe erfordert.
7. Teams von Drittanbietern und übernommene Teams. Eine Agentur, ein Berater oder ein neu übernommenes Unternehmen bringt Agenten mit, die bereits mit eigenen Zugangsdaten laufen. Diese Zugangsdaten durchlaufen nie Ihr Onboarding.

Zwei Vorfälle mit Zugangsdaten im Abstand von zehn Monaten

Zwei konkrete Vorfälle im Abstand von einem Jahr zeigen, was nicht gesteuerte Maschinen-Zugangsdaten tatsächlich kosten. In beiden Fällen war ein vergessenes OAuth-Token oder ein Zugriffsschlüssel mit einer KI-nahen Integration verbunden, ohne dass jemand es überwachte, bis ein Angreifer es zuerst fand.

Salesloft Drift, August 2025

Der Bedrohungsakteur UNC6395, den die Threat Intelligence Group von Google verfolgt, nutzte die Integration des KI-Chatbots Drift von Salesloft mit Salesforce aus, um OAuth-Access- und Refresh-Tokens abzugreifen. Drift verbindet sich mit der Salesforce-Instanz eines Kunden, um Vertriebsgespräche zu automatisieren. Diese Verbindung beruht auf einer dauerhaften OAuth-Berechtigung statt auf einer einmaligen Anmeldung.

Sobald UNC6395 funktionierende Tokens hatte, lief der Angriff automatisch, ohne menschlichen Eingriff: Die Gruppe nutzte sie, um Salesforce-Objekte direkt abzufragen und alle Zugangsdaten und Falldaten abzuziehen, die diese Tokens erreichen konnten.

Von dort aus zog der Angreifer AWS-Zugriffsschlüssel, Snowflake-Tokens, gespeicherte Passwörter und Daten aus Supportfällen aus verbundenen Umgebungen ab. Das Ziel war durchgehend die Datenexfiltration über einen vertrauenswürdigen, bereits autorisierten Kanal, nicht ein Einbruch durch die Vordertür. Ein Bedrohungsanalyst von Google sagte gegenüber Cybersecurity Dive, dass möglicherweise mehr als 700 Organisationen betroffen sein könnten. Cloudflare, Zscaler und Palo Alto Networks bestätigten, dass sie dazugehörten.

Klue, Juni 2026

Am 11. Juni 2026 nutzte ein Angreifer ein persönliches GitHub-Zugriffstoken, um nicht autorisierten Code in den Integrationsdienst von Klue einzuschleusen. Der Code sammelte die OAuth-Access- und Refresh-Tokens, die Kunden der App Klue Battlecards erteilt hatten. Mit diesen Tokens fragte der Angreifer die Salesforce-Mandanten der Kunden ab und exportierte Kontakte, Verkaufschancen, Angebote und Vertriebsnotizen.

Laut der Zusammenfassung der CrowdStrike-Untersuchung für Klue, zitiert von der NHI Management Group, war das Token „bereits zuvor kompromittiert“. Huntress beschreibt es als seit Langem ungenutzt, aber weiterhin aktiv. Klue sagte gegenüber TechCrunch, das Token sei 2022 für ein begrenztes Pilotprojekt an einen Dritten ausgestellt worden. Salesforce alarmierte Klue am 12. Juni, und Klue widerrief noch am selben Morgen die Tokens und rotierte die Zugangsdaten. Die Erpressergruppe Icarus bekannte sich zu dem Angriff.

Klue hat keine Opferzahl veröffentlicht. Bis zum 25. Juni hatten mindestens elf Unternehmen bestätigt, betroffen zu sein, darunter Huntress, Recorded Future, Tanium, Jamf, Gong, HackerOne, Snyk, OneTrust, Insurity und Sprout Social. Eine zweite Erpressergruppe behauptete, 195 Kunden getroffen zu haben. Diese Behauptung ist nicht bestätigt.

Was die beiden Vorfälle gemeinsam haben

Die Einstiegspunkte unterscheiden sich. Bei Klue war es ein veraltetes Token für die Versionsverwaltung. Die Quellen zu Drift beschreiben die Nutzung gestohlener OAuth-Tokens, nicht aber, wie sie beschafft wurden. Gemeinsam ist beiden Fällen die Angriffsfläche: nicht-menschliche Zugangsdaten mit dauerhaftem Zugriff auf Kundendaten, die bei einem Anbieter liegen und ohne Anmeldeereignis nutzbar sind. Datenverkehr mit einem gültigen Token sieht aus wie die Integration selbst.

Das Token von Klue blieb nach dem Ende eines Pilotprojekts etwa vier Jahre lang gültig. Die Tokens von Drift blieben gültig, bis jemand sie widerrief.

Risiken der agentischen Schatten-KI

Agentische Schatten-KI erzeugt fünf Risiken: offengelegte langlebige Zugangsdaten, Aktivitäten, die wie normaler Datenverkehr aussehen, Excessive Agency, die Verkettung von Zugangsdaten zwischen Agenten und Compliance-Lücken. Sie haben eine gemeinsame Ursache. Der Agent handelt selbstständig mit Zugangsdaten, die niemand inventarisiert, eingeschränkt oder überprüft hat.

Langlebige Zugangsdaten, die ihren Zweck überdauern

Ein Agent arbeitet so lange weiter, wie sein Schlüssel oder Token gültig ist, und nichts im Agenten erzwingt eine Überprüfung. Zugangsdaten aus Pilotprojekten werden selten rotiert und behalten oft den weiten Berechtigungsumfang, den sie während der Tests hatten.

Klue ist das deutlichste Beispiel. Nach Angaben des Unternehmens selbst war ein 2022 für ein begrenztes Pilotprojekt ausgestelltes Token noch gültig, als Angreifer es im Juni 2026 nutzten. Niemand hatte entschieden, es zu behalten. Niemand hatte aber auch entschieden, es außer Betrieb zu nehmen.

Aktivitäten, die wie normaler Datenverkehr aussehen

Ein Agent authentifiziert sich mit seinem eigenen API-Schlüssel oder OAuth-Token, daher gibt es kein menschliches Anmeldeereignis, das auffallen könnte. Seine Anfragen kommen von einer bekannten Integration, in regelmäßigen Abständen, über genehmigte APIs. Erkennungsregeln, die für gestohlene Benutzerpasswörter gebaut wurden, finden nichts, worauf sie anschlagen könnten.

Datenverluste über einen Agenten werden deshalb meist spät sichtbar. Das erste Signal ist oft eine Mitteilung des Anbieters oder eine ungewöhnliche Rechnung, nicht ein Alarm in Ihrem SIEM.

Excessive Agency

Agenten, die über MCP auf Tools und Daten zugreifen, erben die Berechtigungen des Dienstkontos, das hinter ihnen steht. Diese Berechtigungen werden meist für ein breites Spektrum an Aufgaben erteilt, nicht für die eine, die der Agent ausführt. Diese Lücke ist die Angriffsfläche.

OWASP führt dieses Muster in seinen Top 10 für LLM-Anwendungen als Excessive Agency (LLM06:2025, übermäßige Handlungsbefugnis). Ein Agent, der nicht vertrauenswürdige Inhalte liest, etwa eine E-Mail oder eine Webseite, kann dazu gebracht werden, Zugriffe zu nutzen, die er nie hätte haben dürfen. Eng gefasste Berechtigungen begrenzen, was eine erfolgreiche Injection erreichen kann.

Verkettung von Zugangsdaten zwischen Agenten

Wenn ein Agent einen anderen aufruft, erhält der nachgelagerte Agent oft die Zugangsdaten des vorgelagerten oder ein daraus abgeleitetes Token. Eine Kompromittierung des schwächsten Agenten öffnet dann alles, was der stärkste erreichen kann. Nicht registrierte Agenten verschärfen das Problem, weil niemand erfasst hat, welcher Agent welchem vertraut.

Compliance- und Audit-Lücken

Ein nicht inventarisierter Agent verarbeitet Daten außerhalb Ihrer Verzeichnisse und Kontrollen. Artikel 32 DSGVO verlangt „geeignete technische und organisatorische Maßnahmen“ zum Schutz personenbezogener Daten, und Zugangsdaten, für die niemand verantwortlich ist, lassen sich kaum als solche Maßnahme verteidigen. NIS2-Richtlinie, Artikel 21(2)(i) nennt Konzepte für die Zugriffskontrolle und das Asset-Management unter den vorgeschriebenen Risikomanagementmaßnahmen.

Agentische Schatten-KI steuern: 5-Schritte-Checkliste für Zugangsdaten

Die 5-Schritte-Checkliste für Agenten-Zugangsdaten steuert agentische Schatten-KI über die Zugangsdaten, mit denen Agenten arbeiten. Finden Sie jeden Agenten und seine Secrets, geben Sie jedem eine eigene Identität mit eng gefassten Berechtigungen, benennen Sie einen fachlichen und einen technischen Verantwortlichen, legen Sie Laufzeitgrenzen fest, und protokollieren, testen und widerrufen Sie dann nach einem festen Zeitplan.

Schritt 1. Agenten über ihre Zugangsdaten aufspüren

Agenten werden leicht übersehen, aber ihre Zugangsdaten hinterlassen Spuren in den Systemen, auf die sie zugreifen. Suchen Sie zuerst an diesen Stellen:

• OAuth-Berechtigungen und verbundene Apps in jeder SaaS-Admin-Konsole
• Dienstkonten und Service Principals in Ihrem Identity-Provider und Ihren Cloud-Konten
• Secret Stores, Repository-Variablen und CI/CD-Einstellungen
• Consumer-Listen von API-Gateways
• Endpunkte: installierte Assistenten, Browser-Erweiterungen und Konfigurationsdateien für das Model Context Protocol (MCP)

Erfassen Sie für jeden Agenten, worauf er zugreifen kann, welche Tools oder APIs er aufruft, welche Daten er liest oder schreibt und wer ihn aktiviert hat. Der erste Durchlauf wird unvollständig sein. Wiederholen Sie ihn nach einem festen Zeitplan, denn neue Agenten entstehen schneller, als vierteljährliche Überprüfungen sie erfassen.

Schritt 2. Jedem Agenten eine eigene, eng gefasste Identität geben

Ein Agent sollte nie hinter einem gemeinsam genutzten Konto oder dem persönlichen Login eines Mitarbeiters laufen. Erstellen Sie eine Identität pro Agent, die an seine Workload gebunden ist. Entfernen Sie dann die weitreichenden Berechtigungen, die der Agent während der Tests erhalten hat, sodass der Zugriff der einen Aufgabe entspricht, die er in der Produktion erfüllt.

Dieselbe Regel gilt für Agenten, die andere Agenten aufrufen. Jeder Agent authentifiziert sich selbst, und die Zugangsdaten eines Agenten werden nie an einen anderen weitergegeben.

In Passwork ist ein Dienstkonto ein nicht interaktives Konto, das für die Automatisierung gebaut ist. Ein Dienstkonto kann mehrere API-Tokens mit eng gefassten Berechtigungen enthalten, sodass jeder Agent und jede Pipeline ein eigenes Token erhält. Tresorrichtlinien legen fest, wer welchen Tresortyp verwaltet. Ein Tresor für Agenten-Zugangsdaten hat damit von Anfang an Unternehmensadministratoren. Das Rotieren von Zugangsdaten unterbricht nicht die Pipelines, die von dem Konto abhängen.

Testen Sie Dienstkonto-Tokens mit eng gefassten Berechtigungen und Tresorrichtlinien mit den Zugangsdaten Ihrer eigenen Agenten. Passwork kostenlos in Ihrer Infrastruktur testen.

Schritt 3. Einen fachlichen und einen technischen Verantwortlichen benennen

Für alle Zugangsdaten braucht es zwei Personen. Der fachliche Verantwortliche übernimmt die Verantwortung dafür, wozu der Agent dient und welches Risiko tragbar ist. Der technische Verantwortliche kümmert sich um den Zugriff zur Laufzeit, die Protokollierung und die Wartung. Ohne beide kann niemand sagen, ob bestimmte Zugangsdaten überhaupt noch existieren sollten.

Klue zeigt, was ein leeres Feld für den Verantwortlichen kostet. Nach Angaben des Unternehmens selbst war ein 2022 für ein begrenztes Pilotprojekt ausgestelltes Token noch gültig, als Angreifer es im Juni 2026 nutzten. Speichern Sie die Verantwortlichen, den Zweck und ein Überprüfungsdatum direkt bei den Zugangsdaten. Wenn ein Verantwortlicher die Rolle wechselt oder das Unternehmen verlässt, weisen Sie die Zugangsdaten im selben Ticket neu zu.

Schritt 4. Laufzeitgrenzen festlegen, bevor der Agent live geht

Halten Sie schriftlich fest, was der Agent tun darf und was er nie tun darf, und richten Sie die Tiefe der Prüfung nach seinem Grad an Autonomie aus. Ein Agent, der nur einen Kalender liest, braucht eine kurze Checkliste. Ein Agent, der Geld bewegt oder in externe Systeme schreibt, braucht eine formale Risikoprüfung und eine Freigabe.

Sobald der Agent läuft, setzen Sie Grenzen außerhalb seiner eigenen Reasoning-Schicht durch:

• einschränken, welche Tools er aufrufen kann, und prüfen, was in jeden Aufruf hineingeht und was herauskommt
• verhindern, dass Secrets und personenbezogene Daten über Uploads oder die Zwischenablage abfließen
• menschliche Freigabe für Zahlungen, Änderungen von Berechtigungen und Schreibzugriffe auf externe APIs verlangen

Wer jedes nicht genehmigte Tool verbietet, drängt die Arbeit nur aus dem Blickfeld. Bieten Sie einen genehmigten Weg an, der schneller ist als der Workaround, etwa eine interne Agentenplattform, in die diese Grenzen bereits eingebaut sind.

Schritt 5. Protokollieren, testen und außer Betrieb nehmen

Leiten Sie die Aktivitäten der Agenten an Ihr SIEM weiter. In Passwork erfasst das Aktivitätsprotokoll, wer Zugangsdaten gelesen oder geändert hat, und lässt sich an Syslog oder ein SIEM exportieren. Richten Sie Alarme ein, wenn ein Token von einer neuen Quelle oder in ungewöhnlichem Umfang genutzt wird.

Zwei Übungen zeigen, ob die Kontrollen funktionieren:

1. Rückverfolgungstest: Wählen Sie eine automatisierte Aktion aus und verfolgen Sie sie bis zu dem Menschen zurück, der sie autorisiert hat, und zu den Daten, die sie genutzt hat.
2. Widerrufsübung: Messen Sie, wie lange es dauert, den Zugriff eines Agenten auf allen Systemen zu sperren, die er erreicht.

Überprüfen Sie jeden Agenten an seinem Überprüfungsdatum. Achten Sie auf Berechtigungen, die seit dem Start gewachsen sind, rotieren Sie seine Zugangsdaten und nehmen Sie Agenten außer Betrieb, die keinen Zweck mehr haben. Die Threat Intelligence Group von Google gab Kunden nach dem Sicherheitsvorfall bei Drift denselben Rat: verbundene Integrationen überprüfen, dann deren Zugangsdaten widerrufen und rotieren.

Fazit

Die Bezeichnung hat sich am 29. September 2026 geändert. Das zugrunde liegende Risiko nicht. Agentische Schatten-KI, also ein autonomer Agent mit aktiven, nicht rotierten Zugangsdaten, für die niemand verantwortlich ist, war am Tag vor der Executive Order 14434 genauso gefährlich wie am Tag danach. Salesloft Drift und Klue haben das im Abstand von einem Jahr bereits zweimal bewiesen.

Beginnen Sie noch diese Woche mit dem ersten Schritt der Checkliste oben: einer vollständigen Bestandsaufnahme, welche Agenten welche Zugangsdaten besitzen. Nichts anderes auf der Liste funktioniert, solange diese Bestandsaufnahme fehlt, denn Sie können nichts einschränken oder rotieren, was Sie nicht gefunden haben. Es ist außerdem der eine Schritt, mit dem jedes Sicherheitsteam heute beginnen kann. Dafür muss es weder auf Budget noch auf eine neue Plattform warten, noch auf eine Überarbeitung der Richtlinien, angestoßen durch eine Anordnung der US-Regierung, die nichts mit den Zugangsdaten zu tun hat, die gerade jetzt in Ihrer Umgebung liegen.

Die Hygiene von Zugangsdaten für KI-Agenten beginnt genauso wie bei Mitarbeitern: Sie müssen wissen, welche Zugriffe bestehen, wer dafür verantwortlich ist und wann sie zuletzt rotiert wurden. Passwork kostenlos testen.

Häufig gestellte Fragen

Passwork 7.7: Sicherer Offline-Modus für Desktop- und Mobil-Apps

Passwörter funktionieren jetzt auch offline. Passwork 7.7 bietet sicheren Offline-Zugriff mit vollständiger Kontrolle durch Administratoren, organisationsweite Einstellungen für Dateianhänge und fünf neue rollenbasierte Onboarding-Leitfäden für eine reibungslosere Einführung.

PassworkPasswork Team

Passwork 7.6: Dienstkonten

Das neueste Passwork-Release bringt Dienstkonten mit API-Unterstützung für mehrere Tokens, gespeicherte Filter, eine mobile Weboberfläche und die automatische Leerung des Papierkorbs. Sehen Sie, was sich geändert hat.

PassworkPasswork Team

Was ist Schatten-KI: Die versteckte Bedrohung, die Unternehmen 670.000 US-Dollar pro Datenleck kostet

Schatten-KI kostet Unternehmen zusätzlich 670.000 US-Dollar pro Datenleck – und das meiste davon geht auf Zugangsdaten zurück, die in öffentliche LLMs eingefügt wurden. Erfahren Sie, wie Schatten-KI tatsächlich aussieht, warum sie schwerer zu stoppen ist als Schatten-IT und wie Sie sie steuern.

PassworkAlex Muntyan