Dein KI-Agent hat einen Login. Kannst du beweisen, was er angefasst hat?
Stell deinem Security-Team heute Morgen eine einfache Frage: Welche KI-Agenten erreichen unser Finanzsystem? Die meisten antworten in Sekunden. Frag dann, ob sie beweisen können, was diese Agenten letzten Dienstag um 14:07 tatsächlich angefasst haben. Diese Stille ist die Geschichte.
Der Q4-2026-Pulse-Report von JumpCloud, eine Umfrage unter 250 IT-Entscheidern in den USA und Großbritannien, gibt dieser Stille eine Zahl: 72% berichten von einer mittleren bis großen Lücke zwischen dem, worauf ihre KI zugreifen darf, und dem, was sie beweisen können, dass sie darauf zugegriffen hat. Nur 4% sehen keine relevante Lücke. Und 99% der Befragten gaben an, sie seien zuversichtlich, KI-Aktivitäten auditieren zu können, während nur 37% tatsächlich darauf vorbereitet waren.
Zuversicht ist kein Nachweis. Das bestätigt sich in unserer Kundenarbeit jeden Tag.
Die drei Lücken, für die niemand budgetiert
Der Report fasst das Problem als drei überlappende Fehlstellen zusammen, und dieses Framing gehört in eure nächste Vorstandspräsentation.
Die Identitätslücke. 55% der Organisationen nutzen oder testen bereits Agenten, die Systeme, Berechtigungen, Datensätze oder Workflows verändern können. Von diesen haben nur 41% ihre Agenten vollständig in dieselben Identity-and-Access-Management-Richtlinien integriert, die für menschliche Mitarbeitende gelten. Die anderen 59% verwalten Agenten teilweise oder mit separaten Richtlinien und Werkzeugen. Und in 63% der Agenten-Umgebungen sind weiterhin geteilte Service-Accounts und langlebige API-Keys im Einsatz, also genau das, was eine Zuordnung sechs Wochen später unmöglich macht.
Die Nachweislücke. 72% können nicht vollständig rekonstruieren, was eine KI angefasst hat. Nur 34% können vollständig belegen, wie die KI mit sensiblen Daten interagiert hat. In den vergangenen zwölf Monaten meldeten 92% mindestens einen KI-bezogenen Vorfall oder eine Exposition, und 36% untersuchten einen Verdacht, ohne je zu erfahren, worauf die KI zugegriffen hatte.
Die Bereitschaftslücke. Nur 20% der Organisationen erreichen die höchste Stufe der Auditierbarkeitsreife. 64% liegen im Mittelfeld: Die Kontrollen existieren, aber die Abdeckung ist ungleichmäßig, und die Löcher zeigen sich erst im Audit oder nach einem Vorfall. 30% berichten von Shadow AI, die sie nicht vollständig überwachen können, und nur 14% prüfen KI-Berechtigungen kontinuierlich oder automatisiert.
Zusammen gelesen ist die Schlussfolgerung unbequem. Die Kontrollen sind meist da. Was fehlt, ist Abdeckung: Kontrollen, die am freigegebenen Tool enden und die angebundenen Systeme nie erreichen, die Mitarbeitende abdecken und Agenten überspringen.
Warum das schwerer ist als normales IAM
Ein Agent ist mit Absicht ein schlecht erzogener Nutzer. Er handelt im Namen von jemandem, hält Credentials, die die Aufgabe überleben, greift über Ticketing, CRM, Finanzen, Endpoint-Management und Identität hinweg und verändert sein Verhalten, wenn sich Prompt oder Modell ändern. Die Belege darüber, was er getan hat, liegen an drei Orten gleichzeitig: in der Konsole des KI-Tools, in dem System, das er angefasst hat, und im Directory, das die Identität hält. Eine einzelne Aktion zu rekonstruieren heißt, alle drei zu verknüpfen, und die meisten Organisationen haben diesen Join noch nie gemacht.
Der Report zeigt außerdem: Organisationen betreiben im Schnitt 2,7 KI-Tools, die jeweils in rund drei Kategorien von Unternehmenssystemen reichen, und jede dritte Organisation sagt, KI könne die IAM-Schicht selbst erreichen. Diese Zahl sollte die Diskussion stoppen. Ein Agent, der IAM erreicht, ist kein Produktivitätstool. Er ist ein administrativer Principal mit einem Chatfenster.
Die Autonomiefrage hat eine Zahl
46% der Organisationen erlauben risikoreiche Agentenaktionen automatisch. Nur 18% verlangen eine menschliche Freigabe, bevor der Agent handelt. Wenn dein Agent eine Rechnung bezahlen, einen Key rotieren oder ein Passwort zurücksetzen kann, ohne dass ein Mensch im Weg steht, hast du genau den Teil des Prozesses automatisiert, in dem früher das Urteilsvermögen saß.
Wir plädieren nicht für Freigabemüdigkeit bei jedem Klick. Wir plädieren dafür, dass risikoreich eine schriftliche Definition bekommt, und dass diese Definition dort kodiert wird, wo die Aktion passiert, nicht in einer Policy-PDF, die während eines Vorfalls niemand liest.
Was reife Teams tatsächlich tun
Der Report schließt mit einem vierstufigen Agentic-IAM-Lifecycle: jeden Agenten entdecken, auch die, von denen die IT nie erfahren hat; jeden mit Zweck, Geltungsbereich und einem namentlich benannten menschlichen Owner registrieren; Zugriffe richtig dimensionieren, sodass sie mit der Arbeit ablaufen; und kontinuierlich governancen, weil Agentenberechtigungen schneller driften, als Quartalsreviews greifen.
Die meisten Teams bleiben bei Stufe eins stehen, manchmal bei zwei. Hier ist die Version, die wir mit Kunden fahren, in der Reihenfolge, die am schnellsten Nachweise liefert.
- Inventarisiere Agenten wie SaaS. Zieh jeden OAuth-Grant, API-Key und Service Principal und ordne zu, welche zu einem Agenten gehören und welcher Mensch ihn besitzt. Kein Owner, kein Zugriff.
- Beende geteilte Accounts. Ein Agent auf einem geteilten Service-Account lässt sich niemandem zuordnen. Gib jedem Agenten eine eigene Identität und kurzlebige Credentials, dann beginnt die Nachweislücke in derselben Woche zu schließen.
- Definiere risikoreich im Code. Zahlungen, Rechteänderungen, Datenexporte, Schreibzugriffe in Produktion. Alles auf dieser Liste bekommt ein deterministisches Gate, nicht die Meinung eines Modells, ob es okay aussieht.
- Schicke Agentenaktivität in das SIEM, das du schon hast. Die Konsole des KI-Anbieters ist kein Audit-Trail. Halte Belege dort, wo deine Ermittler ohnehin nachsehen.
- Prüfe kontinuierlich, nicht quartalsweise. Automatisiere die Rechteprüfung und behandle eine Agenten-Berechtigungsänderung wie eine Firewall-Änderung: protokolliert, geprüft, umkehrbar.
Nichts davon verlangt am ersten Tag eine neue Plattform. Es verlangt, Agenten als zweite Identitätspopulation mit derselben Disziplin zu behandeln, die du Menschen gegenüber angewendet hast, und das vor dem Vorfall zu tun, nicht während der Untersuchung.
Das Fazit für dein Team
Die unbequeme Zahl in diesem Report ist nicht 72%. Es ist 99% gegen 37%: die Lücke zwischen dem Vertrauen der Führung und der tatsächlichen Vorbereitung. Vertrauen ohne Logs, Scopes und benannte Owner ist ein Risiko, denn es hält das Problem von der Roadmap fern, bis ein Auditor oder ein Angreifer es findet.
Fang diese Woche mit einer konkreten Frage an: Nimm deinen privilegiertesten Agenten, benenne seinen Owner laut und versuche, seine letzten zehn Aktionen aus deinen eigenen Logs zu rekonstruieren. Wenn es klappt, bist du dem Markt voraus. Wenn nicht, weißt du genau, wohin das nächste Quartal Sicherheitsarbeit geht, und du hast eine Zahl, mit der du es begründen kannst.
Deutlich besser als die Erkenntnis mitten in einem Breach.