1,5 Millionen unkontrollierte KI-Agenten: Was der neue Gravitee-Report für Unternehmenssicherheit bedeutet

In den letzten 24 Stunden hat ein neuer Sicherheitsreport des API-Management-Anbieters Gravitee eine Kennzahl in den Mittelpunkt gerückt, die Entscheider nicht ignorieren können: Rund 1,5 Millionen der aktuell etwa 3 Millionen produktiv eingesetzten KI-Agenten in großen Unternehmen gelten als unreguliert und damit „at risk of going rogue“ – also als potenziell fehlverhaltensanfällig.

Der Bericht zeigt, dass agentische KI nicht länger ein Zukunftsthema ist, sondern stillschweigend zum produktiven „Digital Workforce“ geworden ist – und zwar oft ohne formale Kontrolle durch IT- oder Sicherheitsabteilungen. Für Unternehmen entsteht damit eine neue, weitgehend unsichtbare Angriffsfläche.

Dieser Artikel erklärt, was hinter den Zahlen steckt, welche konkreten Risiken daraus für Geschäftsprozesse entstehen und welche Governance- und Sicherheitsmaßnahmen Unternehmen jetzt kurzfristig und mittelfristig umsetzen sollten.

Kontext: Was der Gravitee-Report tatsächlich sagt

Wer steckt hinter der Studie?

Der Report stammt von Gravitee, einem Anbieter für API-Management und „agentic“ Event-Management-Plattformen. Befragt wurden 750 CTOs und Technologie-Verantwortliche aus größeren Unternehmen (vor allem US und UK) zu ihrer aktuellen Nutzung von KI-Agenten und deren Governance-Strukturen. Die Erhebung fand im Dezember 2025 statt und wurde jetzt veröffentlicht.

Auf Basis dieser Umfrage und offizieller Unternehmensstatistiken schätzt Gravitee, dass:

• rund 3 Millionen KI-Agenten in Unternehmen in den betrachteten Märkten produktiv aktiv sind,

• knapp die Hälfte dieser Agenten „ungoverned“ ist, also ohne angemessene Überwachung und Kontrollmechanismen läuft,

• damit über 1,5 Millionen Agenten ein deutlich erhöhtes Risiko aufweisen, durch Fehlkonfiguration oder Kompromittierung „fehlzugehen“.

Zusätzlich berichten laut Studie 88 % der Unternehmen, dass sie im letzten Jahr mindestens einen vermuteten oder bestätigten sicherheits- oder datenschutzrelevanten Vorfall im Zusammenhang mit KI-Agenten hatten.

Was ist unter „KI-Agent“ im Report gemeint?

Der Report spricht explizit von autonomen „Digital Workers“ – also Systemen, die:

• mehrschrittige Aufgaben eigenständig ausführen,

• dabei auf interne und externe Systeme zugreifen (z. B. CRM, ERP, Ticketing, E-Mail, Datenbanken, APIs),

• Entscheidungen oder Aktionen ohne unmittelbare menschliche Freigabe treffen.

Typische Beispiele aus der Praxis:

• Customer-Service-Agenten, die Tickets klassifizieren, beantworten oder eskalieren,

• KI-basierte Finanz- oder Pricing-Agenten, die Buchungen, Gutschriften oder Preisanpassungen anstoßen,

• interne Operations-Agenten, die Berechtigungen beantragen, Nutzerkonten anlegen, Workflows starten oder Daten migrieren,

• DevOps- oder IT-Automation-Agenten, die Deployments auslösen, Konfigurationen ändern oder Logs analysieren und daraus Aktionen ableiten.

Damit unterscheidet sich der Fokus klar von „einfachen“ Chatbots oder reinen Assistenzsystemen ohne Schreib-/Aktionsrechte.

„Going rogue“: Was heißt das operativ?

„Rogue AI“ meint in diesem Kontext nicht Science-Fiction-Szenarien, sondern ungewolltes, geschäftsschädliches Verhalten innerhalb realer Unternehmenssysteme, z. B.:

• Fehlentscheidungen: Ein Agent trifft auf Basis falscher oder manipulierten Daten Entscheidungen (z. B. falsche Rabatte, unberechtigte Gutschriften, unpassende Ablehnungen von Anträgen).

• Datenexfiltration: Ein Agent hat Lesezugriff auf sensible Systeme und schreibt Inhalte in externe Logs, Tickets, Messages oder an externe APIs.

• Workflow-Manipulation: Kompromittierte Agenten verändern Freigabe- oder Compliance-Workflows, umgehen Kontrollschritte oder setzen automatisch Freigaben durch.

• Missbrauch als Einfallstor: Angreifer nutzen schlecht gesicherte Agenten-Identitäten, um mit legitimen Tokens und Rollen in Unternehmenssysteme einzudringen.

Kernproblem ist nicht „bösartige KI“, sondern menschliche Fehlkonfiguration und unzureichende Governance bei Systemen, die faktisch wie hochprivilegierte Servicekonten agieren.

Analyse: Warum agentische KI zur neuen Angriffsfläche wird

Unsichtbare Identitäten mit hoher Wirkmacht

Ein zentrales Ergebnis der Studie: In vielen Unternehmen werden KI-Agenten nicht als eigenständige Identitäten betrachtet, sondern als „Feature“ einer Anwendung oder eines SaaS-Dienstes. Die Folge:

• Sie tauchen nicht in Identity- & Access-Management-Inventaren auf.

• Es gibt häufig keine konsistenten Richtlinien für Rollen, Berechtigungen und Zugriffsrechte.

• Security-Teams haben keine vollständige Übersicht, welcher Agent wo läuft und auf welche Systeme er zugreifen darf.

Damit entsteht eine „Invisible AI“-Schicht: Agenten operieren technisch legitim, aber organisatorisch unbeobachtet. Vergleichbar wäre eine Vielzahl von Servicekonten und API-Keys ohne zentrale Verwaltung – etwas, was in der Informationssicherheit seit Jahren als Hochrisiko gilt.

Geschwindigkeit der Einführung überholt Security-Prozesse

Der Report zeigt zudem, dass agentische KI oft bottom-up eingeführt wird:

• Fachbereiche experimentieren mit Low-Code-/No-Code-Plattformen und agentischen Frameworks.

• SaaS-Anbieter aktivieren standardmäßig „intelligente“ Automatisierungen, die eigenständig handeln können.

• Proof-of-Concepts werden schnell in die Produktivumgebung überführt – meist ohne formale Sicherheitsfreigabe.

Security- und Compliance-Richtlinien sind auf klassische Applikationen und Benutzerkonten ausgerichtet, nicht auf hundert- bis tausendfache, dynamische Agenten-Identitäten. Dadurch entsteht ein Governance-Gap.

Fehlende Monitoring- und Incident-Prozesse

Laut Gravitee geben viele Unternehmen an, dass sie zwar grundsätzliche Sicherheitsrichtlinien für KI definiert haben, aber:

• kein spezifisches Monitoring für Agenten-Aktivitäten existiert (z. B. keine dedizierten Logs, keine Verhaltensprofile),

• keine klaren Incident-Response-Pläne für KI-spezifische Vorfälle bestehen,

• kein technischer Kill-Switch umgesetzt ist, um Agenten schnell und zentral zu deaktivieren oder zu isolieren.

Damit werden Agenten zu „Fire-and-Forget“-Ressourcen: Einmal konfiguriert, laufen sie weiter – selbst wenn sich Umgebungsbedingungen, Policies oder Bedrohungslage ändern.

Parallele Vorfälle verstärken das Risikobild

Aktuelle Ereignisse rund um das KI-Social-Network Moltbook, bei dem rund 1,5 Millionen Agenten und zugehörige API-Tokens durch eine Fehlkonfiguration offengelegt wurden, zeigen, wie real diese Gefahr ist: Angreifer konnten potenziell Agenten-Identitäten übernehmen und Inhalte manipulieren. In Unternehmenskontexten würden ähnliche Schwachstellen direkt in produktive IT-Landschaften durchschlagen.

Der Gravitee-Report macht klar: Die zugrunde liegenden Muster – fehlende Identitätsprüfung, schlechte Schlüsselverwaltung, mangelnde Segmentierung – sind in vielen Enterprise-Setups ähnlich vorhanden.

Praktische Beispiele: Wie unkontrollierte KI-Agenten Unternehmen schaden können

Im Folgenden einige typische Szenarien, die sich aus den im Report beschriebenen Mustern ergeben. Sie basieren auf heute verbreiteten Einsatzfeldern agentischer KI.

Beispiel 1: Finance- und Billing-Agent manipuliert Gutschriften

Ein Konzern setzt einen KI-Agenten ein, der automatisch:

• fehlerhafte Rechnungen erkennt,

• Kunden proaktiv Gutschriften anbietet,

• diese in der Buchhaltung verbucht.

Der Agent besitzt Schreibrechte im Billing-System. Wegen fehlender Zugriffsbeschränkung hat er jedoch auch Einsicht in weitere finanzielle Daten, u. a. Kreditlimits und Sonderkonditionen.

Risiko:

• Ein Angreifer erlangt Zugriff auf den API-Key des Agenten (z. B. über ein schlecht gesichertes Konfig-Repository).

• Über den kompromittierten Agenten löst er massiv überhöhte Gutschriften aus oder stellt fingierte Gutschriften an eigene Konten aus.

• Da der Agent formal autorisiert ist, schlägt zunächst keine klassische Fraud- oder IAM-Logik an.

Schaden: Finanzielle Verluste, Bilanzkorrekturen, mögliche strafrechtliche Ermittlungen und Reputationsschäden.

Beispiel 2: Customer-Service-Agent als Datenabflusskanal

In einem internationalen Unternehmen nutzt der Kundenservice einen Agenten, der E-Mails, Chats und Tickets automatisch beantwortet und interne Wissensdatenbanken abfragt.

Der Agent hat Lesezugriff auf:

• Kundendaten im CRM,

• frühere Tickets inkl. Dokumentenanhängen,

• teilweise vertrauliche interne Dokumentation.

Risiko:

• Fehlende Data-Governance-Regeln führen dazu, dass der Agent auf übermäßig viele Datendomänen zugreifen kann.

• Ein Prompt mit geschickt formulierter Anfrage (z. B. manipulierte Kundenanfrage) bringt den Agenten dazu, sensible Informationen in eine Antwort zu schreiben.

Schaden: Unbeabsichtigte Offenlegung personenbezogener Daten (DSGVO-Verstöße), mögliche Informationsabflüsse zu Produkten, Preisen, internen Prozessen.

Beispiel 3: DevOps-Agent triggert unkontrollierte Deployments

Ein DevOps-Team nutzt einen Agenten, der:

• Logs auf Fehlermuster scannt,

• auf Basis von Policies automatisch Rollbacks oder Hotfix-Deployments auslöst,

• Tickets in Jira oder ähnlichen Systemen erstellt.

Risiko:

• Durch eine Fehlkonfiguration hat der Agent weitreichendere Rechte als nötig (z. B. Deploy auf alle Umgebungen).

• Ein Angreifer manipuliert seine Entscheidungsgrundlage (z. B. durch gefälschte Log-Einträge oder Tickets).

Schaden: Ungeplante Rollbacks in produktiven Systemen, Ausfall von Services, Verstöße gegen Change-Management- und GxP/ISO-Compliance.

Beispiel 4: Interner HR-Agent beeinflusst Personalentscheidungen

Ein HR-Agent aggregiert Bewerbungsdaten, führt Scorings durch und schlägt Shortlists vor. Er greift dazu auf Lebensläufe, interne Performance-Daten und externe Profile zu.

Risiko:

• Der Agent übernimmt unbemerkt verzerrte oder manipulierte Daten in seine Entscheidungslogik.

• Es gibt keine menschliche Kontrolle mehr über die finale Shortlist.

Schaden: Diskriminierende Einstellungsentscheidungen, Verletzung von Antidiskriminierungsgesetzen, Reputations- und Rechtsrisiken.

Business-Relevanz: Was Unternehmen jetzt konkret tun sollten

Der Gravitee-Report liefert keine Science-Fiction-Warnung, sondern ein sehr gegenwärtiges Governance-Problem. Entscheider sollten KI-Agenten so ernst nehmen wie hochprivilegierte Servicekonten oder kritische APIs.

1. Vollständige Inventarisierung aller KI-Agenten

• Erstellen Sie ein zentrales Register aller eingesetzten KI-Agenten (intern und in SaaS-Produkten):

- Wo laufen sie (Plattform, Region)?

- Welche Identität nutzen sie (Servicekonto, API-Key, OAuth-Client)?

- Auf welche Systeme und Datendomänen greifen sie zu?

- Wer ist Fach- und Technik-Owner?

• Binden Sie dieses Register in bestehende CMDB- oder IAM-Systeme ein.

2. Rollen- und Berechtigungskonzept („Least Privilege für Agenten“)

• Definieren Sie Agenten wie Benutzerrollen:

- Welche konkreten Aufgaben soll ein Agent erfüllen?

- Welche minimalen Rechte sind dafür wirklich notwendig?

• Implementieren Sie Least-Privilege-Zugriff:

- Segmentierte Rollen pro System (z. B. nur Lesezugriff im CRM, nur spezifische Schreiboperationen im Ticketing).

- Vermeidung von „God-Mode“-Agenten mit Vollzugriff auf viele Systeme.

3. Sichere Identitäten und Schlüsselverwaltung

• Nutzen Sie etablierte Secrets-Management-Lösungen (z. B. Vault, KMS), um API-Keys, Tokens und Zugangsdaten der Agenten zu speichern.

• Setzen Sie Kurzzeit-Tokens und Rotation um, statt statischer Langzeit-Schlüssel.

• Verknüpfen Sie Agenten-Identitäten mit standardisierten AuthN/AuthZ-Verfahren (z. B. OAuth2, OIDC, mTLS), nicht mit hartkodierten Passwörtern.

4. Spezifisches Monitoring und Telemetrie für Agenten

• Führen Sie dedizierte Logs für Agentenaktionen ein (z. B. separate Log-Streams mit Agent-ID, Zielsystem, Aktionstyp, Ergebniscode).

• Etablieren Sie Verhaltensprofile:

- Welche Aktionen sind für einen Agenten „normal“ (Volumen, Zielsysteme, Zeitfenster)?

- Wann weicht das Verhalten signifikant ab (Anomalieerkennung)?

• Integrieren Sie Agenten-Telemetrie in bestehende SIEM-/XDR-Plattformen.

5. Kill-Switch- und Isolationsmechanismen

• Definieren Sie für jeden Agenten einen technischen Abschaltmechanismus:

- sofortige Token-Invalidierung,

- Deaktivierung des zugehörigen Servicekontos,

- Routing-Änderung im API-Gateway.

• Simulieren und testen Sie regelmäßig Notfall-Szenarien („Tabletop Exercises“):

- Was passiert, wenn ein Agent kompromittiert ist?

- Wie schnell können wir ihn isolieren?

6. Anpassung von Richtlinien, Risiko- und Compliance-Frameworks

• Erweitern Sie bestehende IT-Sicherheitsrichtlinien um einen Abschnitt „Agentische KI“:

- Zulassungskriterien,

- Freigabeprozesse,

- Mindestanforderungen an Logging, IAM und Testing.

• Beziehen Sie KI-Agenten in Risikobewertungen (z. B. ISO 27001, NIS2, DORA) explizit ein – insbesondere, wenn sie kritische Services oder Finanzprozesse berühren.

• Stimmen Sie Maßnahmen mit Datenschutzbeauftragten ab (DSGVO, Zweckbindung, Datenminimierung).

7. Governance-Strukturen und Verantwortlichkeiten

• Benennen Sie klare Rollen und Verantwortlichkeiten:

- Wer genehmigt neue Agenten?

- Wer ist fachlich und technisch verantwortlich?

- Wer ist Incident-Owner bei Agenten-Vorfällen?

• Etablieren Sie ggf. ein „AI Risk Board“ oder erweitern Sie bestehende Gremien (IT-Steering, ISMS-Board), um agentische KI-Aktivitäten regelmäßig zu überprüfen.

Fazit und zentrale Takeaways

Die neue Analyse zu rund 1,5 Millionen unkontrollierten KI-Agenten macht deutlich: Unternehmen stehen nicht am Anfang einer Entwicklung, sie stecken bereits mittendrin. Agentische KI agiert heute in produktiven Prozessen – oft ohne die Sicherheits- und Governance-Strukturen, die man für vergleichbare menschliche oder technische Identitäten längst etabliert hat.

Entscheider sollten die Warnungen des Reports nutzen, um kurzfristig Transparenz zu schaffen und mittelfristig robuste Governance-Strukturen für KI-Agenten aufzubauen.

Kernpunkte auf einen Blick:

• Unsichtbare KI-Agenten sind Realität: Millionen agentischer Systeme arbeiten bereits produktiv in Unternehmen, oft ohne vollständige Transparenz für Security- und Compliance-Teams.

• Rund 1,5 Millionen Agenten sind ungoverned: Laut Gravitee fehlt ihnen angemessene Überwachung, Zugriffskontrolle und Incident-Handling – ein strukturelles Sicherheitsrisiko.

• Hauptgefahr ist Fehlkonfiguration, nicht „bösartige KI“: Unzureichend abgesicherte Agenten agieren wie hochprivilegierte Servicekonten und eröffnen neue Wege für Datenabfluss und Prozessmanipulation.

• Unternehmen müssen Agenten wie kritische Identitäten behandeln: Inventarisierung, Least-Privilege, sicheres Secrets-Management, spezielles Monitoring und Kill-Switches sind Mindeststandard.

• Governance und Compliance anpassen: Richtlinien, Risikoanalysen und Kontrollgremien müssen agentische KI explizit berücksichtigen – insbesondere in Finanz-, Kunden- und Betriebsprozessen.

• Jetzt handeln, bevor skandalisierte Vorfälle auftreten: Wer früh robuste Strukturen schafft, reduziert nicht nur Sicherheitsrisiken, sondern schafft auch die Grundlage für skalierbare, vertrauenswürdige KI-Nutzung im Kerngeschäft.

Häufig gestellte Fragen (FAQ)

Was versteht der Gravitee-Report unter einem KI-Agenten in Unternehmen?

Der Gravitee-Report bezeichnet als KI-Agent sogenannte „Digital Workers“, die mehrschrittige Aufgaben eigenständig ausführen und dabei auf interne und externe Systeme zugreifen. Diese Agenten treffen Entscheidungen oder führen Aktionen ohne unmittelbare menschliche Freigabe durch und unterscheiden sich damit klar von einfachen, rein assistierenden Chatbots ohne Schreibrechte.

Warum gelten rund 1,5 Millionen KI-Agenten laut Gravitee als Sicherheitsrisiko?

Etwa die Hälfte der weltweit produktiv eingesetzten KI-Agenten läuft ohne ausreichende Governance, Monitoring und Zugriffssteuerung. Dadurch entstehen unsichtbare, hochprivilegierte Identitäten, die bei Fehlkonfiguration oder Kompromittierung zu Datenabfluss, Prozessmanipulation oder finanziellen Schäden führen können.

Welche typischen Risiken gehen von unkontrollierten KI-Agenten in Geschäftsprozessen aus?

Unkontrollierte KI-Agenten können Fehlentscheidungen treffen, sensible Daten unbemerkt exfiltrieren oder geschäftskritische Workflows manipulieren. Werden ihre Identitäten von Angreifern übernommen, dienen sie zudem als legitimer Zugangspunkt in CRM-, ERP-, Finanz- oder DevOps-Systeme und umgehen klassische Sicherheitskontrollen.

Was ist der Unterschied zwischen agentischer KI und klassischen Chatbots?

Agentische KI verfügt in der Regel über System- und Schreibrechte, kann eigenständig Workflows anstoßen, Daten verändern und Aktionen in Fachsystemen ausführen. Klassische Chatbots agieren meist nur als Dialogschnittstelle ohne direkte, automatisierte Eingriffe in operative Systeme und haben daher ein deutlich geringeres Angriffspotenzial.

Wie sollten Unternehmen KI-Agenten im Identity- und Access-Management behandeln?

Unternehmen sollten KI-Agenten wie hochprivilegierte Servicekonten behandeln und sie als eigenständige Identitäten im IAM und in der CMDB inventarisieren. Dazu gehören ein Rollen- und Berechtigungskonzept nach dem Least-Privilege-Prinzip, sauberes Secrets-Management mit Token-Rotation sowie der Einsatz etablierter Authentifizierungs- und Autorisierungsverfahren.

Welche konkreten Sicherheitsmaßnahmen empfiehlt der Artikel für den Umgang mit KI-Agenten?

Empfohlen werden eine vollständige Inventarisierung aller Agenten, ein striktes Rollen- und Berechtigungskonzept, sicheres Schlüssel- und Identitätsmanagement, dediziertes Monitoring inklusive Verhaltensprofilen sowie zentrale Kill-Switch- und Isolationsmechanismen. Ergänzend sollten Richtlinien, Risikoanalysen und Compliance-Frameworks um den Baustein „agentische KI“ erweitert werden.

Was sollten Entscheider kurzfristig tun, um das Risiko durch „unsichtbare KI“ zu senken?

Kurzfristig sollten Entscheider Transparenz schaffen, indem sie alle produktiven KI-Agenten erfassen und deren Zugriffsrechte überprüfen. Parallel dazu sollten Mindeststandards für Logging, Monitoring, Notfall-Abschaltung und Freigabeprozesse definiert werden, um bestehende Agenten schnell in ein kontrolliertes Governance- und Sicherheitsregime zu überführen.