--- title: "54 % der Unternehmen hatten bereits einen KI-Agenten-Sicherheitsvorfall. Die Ursache ist Identität." slug: "ai-agent-incident-identity-credential-sharing" metaDescription: "Neue Forschung zeigt, dass die meisten Unternehmen KI-Agenten Zugangsdaten teilen lassen. Was das für Ihre Schadensausbreitung bedeutet - und wie KI-Governance die Lücke schließt." publishedAt: "2026-07-23T00:00:00.000Z" ---
Mehr als die Hälfte der Unternehmen hatte bereits einen bestätigten Sicherheitsvorfall mit KI-Agenten oder einen Beinahe-Unfall. Das ist die Schlagzeile einer neuen VentureBeat Pulse Research, die diese Woche veröffentlicht wurde und 107 Unternehmen abdeckt, die autonome KI-Agenten aktiv in ihren Geschäften einsetzen.
Diese Zahl wird niemanden überraschen, der aufmerksam war. Was Sie beunruhigen sollte, ist der Grund dahinter.
Nur 32 % der Unternehmen vergeben jedem KI-Agenten eine eigene, klar abgegrenzte und verwaltete Identität. Der Rest lässt Agenten Anmeldedaten teilen - sie laufen auf gemeinsamen API-Schlüsseln, Servicekonto-Token oder in manchen Fällen mit denselben Zugangsdaten wie menschliche Nutzer. Und nur 30 % isolieren ihre risikoreichsten Agenten in Sandboxes.
Dies ist kein Modellproblem. Es ist kein Problem der Prompt-Injektion. Es ist ein Governance-Problem, für das Sicherheitsteams die falschen Werkzeuge entwickelt haben.
Warum geteilte Anmeldedaten ein strukturelles Versagen sind
Wenn Sie zwei Agenten denselben API-Schlüssel geben, schaffen Sie nicht nur eine bequeme Abkürzung. Sie bündeln die Auswirkungen jeder zukünftigen Kompromittierung in einer einzigen Fehlerdomäne.
Stellen Sie sich vor, wie das in der Praxis aussieht. Sie setzen einen KI-Agenten für die Bearbeitung von Kundensupport-Tickets ein. Er benötigt Lesezugriff auf Ihr CRM. Sie geben ihm dasselbe Servicekonto wie Ihre Datenpipeline, weil die Einrichtung eines neuen halbtags dauert und der Sprint am Freitag endet. Drei Monate später wird ein zweiter Agent - einer, der in Ihr Data Warehouse schreibt - mit demselben Schlüssel gestartet, weil sich dieses Muster etabliert hat.
Jetzt haben Sie zwei Agenten mit sehr unterschiedlichen Risikoprofilen, die sich eine Identität teilen. Wenn einer kompromittiert wird - durch einen bösartigen Prompt, ein falsch konfiguriertes Tool oder einen überberechtigten API-Aufruf - erhält der Angreifer nicht nur die Auswirkungen eines Agenten, sondern beider.
Dies ist dasselbe Prinzip, das laterale Bewegungen bei traditionellen Unternehmensverletzungen so effektiv machte. Geteilte Anmeldedaten bedeuten geteilte Angriffsfläche. Der einzige Unterschied bei KI-Agenten ist, dass sie schneller agieren, autonomere Entscheidungen treffen und oft Zugriffe erhalten, die bei einem Menschen skeptisch betrachtet würden.
Das Problem des Sicherheits-Stacks ist schlimmer als es scheint
Hier ist der Teil der VentureBeat-Daten, der Sicherheitsverantwortliche in Unternehmen unruhig machen sollte: die Zufriedenheitswerte.
Organisationen in dieser Umfrage bewerteten ihre aktuellen KI-Sicherheitskontrollen im Durchschnitt mit 4,2 von 5. Gleichzeitig glauben nur ein Drittel, dass ihre Verteidigung tatsächlich besser ist als die von KI-gestützten Angreifern. Und eine klare Mehrheit plant, ihre Tools innerhalb eines Jahres zu wechseln oder zu aktualisieren.
Zufrieden mit Kontrollen, die sie gleichzeitig ersetzen wollen. Das ist eine gefährliche Kombination.
Der Grund für diese Diskrepanz liegt darin, woher die Kontrollen stammen. Der Sicherheits-Stack der meisten Unternehmen ist überwiegend anbieter-nativ - OpenAI-Guardrails, Google Cloud Controls, Azure Policy, Anthropics verwaltete Agentenfunktionen. Das sind keine schlechten Werkzeuge. Aber sie wurden entwickelt, um Modelle zu steuern, nicht das organisatorische Verhalten von Agenten, die in Ihrer Umgebung agieren.
Anbieter-native Kontrollen beantworten Fragen wie: „Hat dieser Prompt gegen die Inhaltsrichtlinie verstoßen?“ Sie sind viel schwächer darin, Fragen zu beantworten wie: „Sollte dieser Agent Zugriff auf dieses System haben? Entspricht das Verhalten des Agenten der erteilten Genehmigung? War die Aktion, die der Agent letzten Dienstag ausgeführt hat, im Rahmen dessen, was der Geschäftsverantwortliche genehmigt hat?“
Diese zweiten Fragen sind Fragen der KI-Governance. Und die meisten Unternehmen sind nicht darauf vorbereitet, sie zu beantworten.
Was Aona hier tatsächlich tut
Die Sicherheitslücke bei Agenten wird nicht durch mehr Guardrails von Modellanbietern geschlossen. Sie wird geschlossen, indem Unternehmen die Governance-Infrastruktur aufbauen, die zwischen den eingesetzten Agenten und den Systemen, auf die diese Agenten zugreifen, steht.
Genau dafür ist Aona entwickelt.
Aona entdeckt jeden KI-Agenten in Ihrer Umgebung - nicht nur die, die Ihr IT-Team genehmigt hat, sondern auch die, die Geschäftsbereiche eigenständig gestartet haben, die Ihre Entwickler in der Produktion testen und die in der Grauzone zwischen genehmigten Tools und Schattensoftware existieren. Schatten-KI bleibt nicht im Schatten, sobald Agenten Aktionen ausführen.
Mit diesem Inventar kartiert Aona, auf was jeder Agent zugreifen kann, was er tatsächlich getan hat und ob sein Verhalten mit den Richtlinien Ihres Governance-Teams übereinstimmt. Wenn ein Agent außerhalb dieser Grenzen agiert - unerwartete Aufrufe tätigt oder Systeme nutzt, die sein Geschäftsverantwortlicher nicht autorisiert hat - meldet Aona das als Alarm und nicht erst als forensische Analyse Monate später.
Das Problem des Teilens von Anmeldedaten in den VentureBeat-Daten ist real. Das tiefere Problem ist jedoch, dass die meisten Unternehmen keine systematische Möglichkeit haben, überhaupt zu wissen, wie viele Agenten laufen, geschweige denn, unter welcher Identität jeder einzelne agiert. Sie können keine Identitäten abgrenzen, die Sie nicht inventarisiert haben.
Was Sie tun sollten, bevor Ihr Vorfall der 55. wird
Wenn Sie zu den meisten Unternehmen gehören, die noch keinen bestätigten Sicherheitsvorfall mit Agenten hatten, sollten die oben genannten strukturellen Erkenntnisse einige konkrete Fragen an Ihre Sicherheits- und Governance-Teams aufwerfen.
Erstens: Wie viele KI-Agenten laufen derzeit in Ihrer Umgebung? Nicht nur die in Ihrem Ticketsystem - alle. Die meisten Unternehmen zählen deutlich zu wenig. Wenn Ihre Antwort eine runde Zahl ist, ist sie wahrscheinlich falsch.
Zweitens: Mit welchen Anmeldedaten laufen diese Agenten? Wenn Sie das nicht pro Agent beantworten können, werden irgendwo fast sicher Anmeldedaten geteilt.
Drittens: Wer ist der benannte Geschäftsverantwortliche für jeden Agenten? Nicht der Entwickler, der ihn gebaut hat, sondern die Person, die für die Aktionen verantwortlich ist. Wenn der Agent einen Ausfall oder Datenverlust verursacht, wer wird dann kontaktiert? Wenn niemand eine klare Antwort hat, ist Ihre Governance-Situation schwächer als Ihre Sicherheitslage vermuten lässt.
Viertens: Haben Sie eine nahezu Echtzeit-Übersicht darüber, was diese Agenten tatsächlich tun? Anbieter-native Protokolle zeigen, was passiert ist. Sie sagen nicht, ob das Geschehene innerhalb der Richtlinien lag.
Die VentureBeat-Daten zeigen, dass Unternehmen sich in dieser Lücke wohlfühlen. Die Zufriedenheitswerte sind hoch. Vorfälle werden als Beinahe-Unfälle behandelt. Das ist genau der Moment vor dem Vorfall, der nicht unbemerkt bleibt.
Aona liefert Ihnen das Inventar, die Richtlinienebene und die Überwachung, um die Lücke zu schließen, bevor es zu einer Sicherheitsverletzung kommt. Wenn Sie sehen möchten, wie das für Ihren tatsächlichen Agenten-Footprint aussieht, wenden Sie sich an das Team unter [aona.ai](https://aona.ai).
---
Dieser Beitrag bezieht sich auf die VentureBeat Pulse Research vom 16. Juli 2026, basierend auf einer Umfrage unter 107 Unternehmen, die autonome KI-Agenten aktiv einsetzen.
