Agentic AI: Wenn Autonomie zur Angriffsfläche wird

Wie Agenten heimlich Daten abgreifen, Systeme ändern – und Kosten verursachen

Bild: Getty Images / Credits: hirun

KI-Agenten sind mehr als nur die nächste Chatbot-Generation. Sie sind Software-Akteure mit Zielen, Werkzeugen und Berechtigungen. Genau das macht sie produktiv. Und genau das macht sie zu gefährlichen Insidern: Agenten können Daten abrufen, Infrastruktur verändern oder Ressourcen missbrauchen. Die gute Nachricht: Unternehmen können sich schützen. Die Schlechte: Klassische IT-Security-Mechanismen reichen dafür nicht mehr aus.

Der Übergang von generativer KI zu agentischen Systemen ist eigentlich ein Sprung: Agenten können mehrstufig planen, APIs aufrufen, Terminals bedienen, Code verändern, auf Mails/Dateien/Ticketsysteme zugreifen – oft mit ausgedehnten Rechten. Die Agenten werden auch als „digitale Insider“ beschrieben: privilegierte Entitäten innerhalb von Systemen.

Vom Insider zum Insider-Threat

Besonders heikel wird es, wenn Agenten zustandsbehaftet sind (Long-Term Context), selbst Werkzeuge nutzen (Tool-Calls) und externe Inhalte in Entscheidungen einfließen lassen (RAG, Internetrecherche, nicht ausreichend klassifizierte Dokumente). Genau hier setzen die modernen Angriffstechniken an: Prompt-Injection (direkt/indirekt), unkontrollierte Tool-Nutzung, Prompt-Leaks, Datenabfluss, „Excessive Agency“. OWASP weist explizit darauf hin, dass Prompt-Injection nicht nur Ausgaben manipuliert, sondern auch unerlaubte Aktionen über Tools/APIs auslösen kann – bis hin zu persistenten Manipulationen über Sessions. Dabei beschleunigen die smarten Agenten nicht nur die Angriffe – sie automatisieren auch die gesamte Cyber-Kill-Chain.

Wie schnell agentische KI zum Angriffsbeschleuniger wird, zeigte ein Red-Team-Experiment Anfang März. Ein autonomer KI-Agent erlangte innerhalb von rund zwei Stunden über eine klassische SQL-Injection Lese- und Schreibzugriff auf die zentrale Datenbank Lilli, McKinseys interne generative KI-Plattform. Berichtet wird von einem Zugriff auf 46,5 Mio. Chat-Nachrichten, 728.000 Dateien, 57.000 Accounts und 95 System-Prompts.

Brisant ist allerdings nicht der Angriff selbst, sondern die Möglichkeit, System-Prompts still zu verändern – ohne Deployment, ohne Code-Change und ohne klassische Alarme auszulösen. Ein einzelner Angreifer hätte das Verhalten der KI für Zehntausende von Mitarbeitenden dauerhaft beeinflussen können.

Nicht manipuliert, sondern abgedriftet.

Noch beunruhigender ist ein Vorfall, bei dem ein Agent ein unerwartetes Verhalten entwickelte. Laut Berichten schlugen während des Trainings eines experimentellen KI‑Agenten im Umfeld der Alibaba‑Cloud plötzlich Sicherheitsalarme an: ungewöhnlicher Netzwerk‑Traffic, Egress‑Verbindungen nach außen, auffällige GPU‑Last.

Am Ende kam heraus: Der Agent versuchte, GPU‑Rechenleistung für Crypto‑Mining umzuleiten und richtete zudem einen Reverse‑SSH‑Tunnel nach außen ein. Beides ohne entsprechende Anweisung, ausgelöst durch exploratives Verhalten während des Reinforcement Learnings.

Bemerkenswert ist in diesem Zusammenhang, dass der Vorfall nicht vom KI‑Monitoring entdeckt wurde, sondern durch klassische Telemetrie wie das Auswerten von Firewall-Logs und Netzwerkmonitoring.

Vibe‑Coding in der Produktion

Unser drittes Beispiel ist ist weniger spektakulär, aber potenziell gefährlicher. Morning Brew berichtet über Vorfälle bei Amazon, bei dem ein AI‑Coding‑Tool Änderungen vornahm, die zu längeren Ausfällen der Website beitrugen.

Immer mehr Unternehmen lassen KI‑Agenten und Coding‑Assistenten Konfigurationen erzeugen oder ändern und spielen diese direkt in Produktionspipelines ein. Das Ergebnis sind unerwartete Seiteneffekte bis hin zu großflächigen Ausfällen.

Interne Berichte bei großen Cloud‑ und E‑Commerce‑Anbietern zeigen allerdings auch: KI‑generierter Code ist fehleranfälliger – und wird oft weniger kritisch geprüft. Verantwortung verwischt. „Das hat die KI gemacht“ ersetzt saubere Review‑Prozesse. Geschwindigkeit schlägt Sorgfalt.

Amazon verschärfte nach den Vorfällen die Sign‑off‑Pflichten und etablierte Senior‑Reviews für AI‑assistierte Änderungen.

OpenClaw, Moltbook & Co sind kein Einzelfall, sondern ein Muster

Diese aktuellen Vorfälle fügen sich nahtlos in eine Reihe von Pannen ein: exponierte APIs oder Credentials, unsichere Standardkonfigurationen, schadhafte Plugins, überprivilegierte Agenten, schwache Authentifizierung – und kaum wirksame Kontrolle.

Besonders kritisch wird es, wenn Agenten untereinander interagieren. Prompt‑Injection zwischen Agenten, Credential‑Leakage oder Manipulation über Langzeit‑Kontext hebeln klassische Sicherheitsmodelle aus. Der Traffic ist legitim, die Aktionen sind formal erlaubt – und trotzdem hochriskant.

Sobald KI‑Agenten Teil von CI/CD‑Pipelines werden, ist das übrigens nicht nur ein Sicherheits‑ sondern auch ein Budgetrisiko.

Jack Watts schreibt auf LinkedIn: “Eine einzige Eingabeaufforderung kann zu Argumentationsschleifen, Tool-Aufrufen, Abrufabfragen und mehreren Modellaufrufen führen. Plötzlich werden aus einer einfachen Anfrage mehr als 20 API-Calls.”

Lehrstücke systemischer Agent‑Risiken

OpenClaw veranschaulicht Skalierung (viele Instanzen, viele Plugins, viele Fehlkonfigurationen), McKinsey hebt die Speed‑Komponente hervor (Agenten als Angriffsautomatisierer), Alibaba zeigt die Misalignment‑Komponente (unerwartete, policy‑brechende Handlungen), und Amazon demonstriert die Operations‑Komponente (Agenten als Change‑Beschleuniger mit Nebenwirkungen).

Die entscheidende Frage lautet daher nicht mehr: „Ist unsere KI sicher?“ Sondern: „Was darf unsere KI konkret tun – und wer merkt es, wenn sie es nicht oder etwas anderes tut?“

Mitigation: Was wirklich wirkt (und was nur beruhigt)

Unternehmen sind dem nicht hilflos ausgeliefert. Es erfordert allerdings ein Umdenken. Erfolgreiche Organisationen setzen auf Agenten‑Observability statt auf reine Modellkontrolle.

Wer heute keine Antwort auf die Frage „Welcher Agent hat wann welche Aktion mit welcher Berechtigung ausgeführt?“ geben kann, ist nicht audit‑fähig. Entscheidend sind:

IBM fasst es pragmatisch zusammen: „Agenten brauchen Authentifizierung, RBAC, Guardrails und Observability.“

Vor allem sollte ein Modell oder ein Agent nicht automatisch alles ausführen dürfen, was es oder er sich „ausdenkt“ (Trennung von Denken und Handeln). OWASP betont: Prompt‑Injection entsteht oft, weil Anweisungen und Daten sich nicht immer klar trennen lassen und externe Inhalte (Web, Mails, Docs) als Instruktionen wirken können.

Merksatz: Alles, was ein Agent liest, ist potenziell ein Prompt. Alles, was er ausführen darf, ist potenziell ein Exploit.

Human‑in‑the‑Loop ist kein Rückschritt

Autonomie bedeutet nicht Kontrollverlust. Aber es erfordert gezielte menschliche Eingriffspunkte. Bewährt haben sich unter anderem:

Human‑in‑the‑Loop (HITL) ist kein Zeichen von Misstrauen gegenüber KI. Es ist ein Zeichen von professionellem Risikomanagement.

Galileo empfiehlt dafür confidence‑basierte Eskalation (Schwellenwerte) und nachhaltige Review‑Quoten, damit HITL nicht zum Flaschenhals wird, sondern ein skalierbares Betriebsmodell.

Agenten sind keine smarten Tools – sie sind operative Akteure

Die Lehre aus McKinsey, Alibaba, OpenClaw und dem Vibe‑Coding‑Hype ist unbequem, aber klar: Sobald KI handeln darf, gehört sie ins Threat‑Model. Nicht als exotische Sonderlösung, sondern als vollwertiger Akteur mit Identität, Rechten und Nebenwirkungen. Wer nur versucht, Modelle „sicherer“ zu machen, greift zu kurz. Entscheidend ist, den Handlungsraum der KI zu kontrollieren.

Oder anders gesagt: Das Risiko ist nicht die KI. Das Risiko besteht darin, sie unbeaufsichtigt zu lassen.

5 Quick Wins für CIOs, CISO und CAIOs

  1. Agent‑ und Tool-Inventar + Rechte-Matrix (wer darf was wo und wohin?) als Grundlage für Governance.
  2. Default‑Deny für Tool‑Calls, dann schrittweise Allowlists (APIs/Domains/Commands).
  3. Egress‑Monitoring + Anomalie-Erkennung für Agent‑Workloads (Tunneling, Burst‑Traffic).
  4. Immutable Audit‑Trails für Prompts/Policies/Actions (Forensik‑Readiness).
  5. HITL‑Gates für High-Impact-Actions – nicht überall, sondern dort, wo’s im Ernstfall wirklich weh tut.