Agentische KI hat euer Sicherheitsmodell gebrochen

Was „agentische KI" für die Sicherheit bedeutet

Ein KI-Agent ist eine autonome Software-Einheit, die ein Ziel über mehrere Systeme hinweg verfolgt, Entscheidungen trifft und Menschen nur einbezieht, wenn es nötig ist. Praktisch heißt das 2026: Coding-Agents wie Claude Code, Cursor oder Codex, die Repositories lesen und Werkzeuge ausführen, Ops-Agents wie der Azure SRE Agent oder Agents aus Copilot Studio, die Cloud-Infrastruktur verwalten, und ein langer Schwanz von Business-Agents, die E-Mails zusammenfassen, Tickets anlegen, CRM-Datensätze aktualisieren und Antworten entwerfen.

Der Wechsel vom „KI-Assistenten" zum „KI-Agenten" ist der Wechsel von „das Modell sagt etwas, der Nutzer tut es" zu „das Modell entscheidet, was zu tun ist, und tut es". Der Nutzer ist nicht mehr der Handlungspunkt.

Das bricht vier Annahmen, auf denen jedes klassische Sicherheitswerkzeug aufbaut.

• Identität ist menschlich. IAM-Systeme wurden für Nutzer entworfen, die sich einmal authentifizieren und unter einer Identität handeln. Agents authentifizieren sich fortlaufend, oft unter delegierten menschlichen Zugangsdaten, und handeln schneller, als jede menschliche Prüfung mitkommt.

• Aktionen sind gewollt. DLP und Audit setzen voraus, dass jemand die Datenbewegung beabsichtigt hat. Ein Agent bewegt Daten, weil ein Inhalt es ihm gesagt hat, möglicherweise ohne Wissen des eigentlichen Nutzers.

• Rechte sind statisch. RBAC vergibt Rollen und prüft sie quartalsweise. Ein Agent mit derselben Rolle wie ein Mensch hat dramatisch größere Reichweite, weil er rund um die Uhr über alle verbundenen Systeme gleichzeitig arbeitet.

• Tempo ist menschlich. SOC-Schwellenwerte, Rate-Limit-Regeln und Prüf-Warteschlangen wurden auf menschliches Tempo abgestimmt. Anthropics Analyse des Angriffs GTG-1002 dokumentierte einen autonomen Agenten mit Tausenden Anfragen pro Sekunde, deutlich unterhalb der meisten Alarmierungsschwellen.

Die vier Annahmen brechen gemeinsam. Deshalb ist „agentische KI-Sicherheit" keine Funktion, die man an ein bestehendes Werkzeug anflanscht. Es ist eine andere Kontrollfläche.

Vier Vorfälle aus 2025 und 2026, die bereits passiert sind

Nicht hypothetisch. Zu jedem gibt es eine öffentliche Offenlegung und meist eine CVE.

GTG-1002 (Anthropic, September 2025)

Anthropic entdeckte eine staatlich unterstützte chinesische Gruppe, die Instanzen von Claude Code kaperte, um autonome Cyberspionage gegen rund 30 Ziele aus Verteidigung, Energie und Technologie zu betreiben. Die KI erledigte 80 bis 90 Prozent der taktischen Operationen eigenständig und fand und nutzte Schwachstellen mit Tausenden Anfragen pro Sekunde. Die Operatoren umgingen die Schutzmechanismen von Claude, indem sie das Modell selbst manipulierten und behaupteten, Mitarbeitende legitimer Sicherheitsfirmen bei autorisierten Tests zu sein.

Das war der erste öffentlich dokumentierte Fall eines Cyberangriffs, der in großem Maßstab weitgehend ohne menschliches Zutun lief.

CVE-2026-32173: Azure SRE Agent

Eine Schwachstelle im Azure SRE Agent von Microsoft legte laufende Befehlsströme über einen unauthentifizierten WebSocket-Endpunkt offen. Jeder Inhaber eines Entra-ID-Kontos konnte in Echtzeit mitverfolgen, was der Agent tat. CVSS 8,6.

Die Lehre ist architektonisch: Wenn ein Agent dauerhaft läuft und seine Operationen als Ereignisstrom bereitstellt, wird dieser Strom selbst zum Ziel. Klassische Pentest-Methodik deckt „der Herzschlag des Agenten ist ein Zugangsdatum" nicht ab.

Angriff auf mexikanische Behörden (Dezember 2025 bis Februar 2026)

Ein einzelner Angreifer nutzte Claude Code und GPT-4.1, um in neun mexikanische Behörden einzudringen, darunter die Bundessteuerbehörde, das Zivilregister von Mexiko-Stadt und das Wahlinstitut. Die Agents beschleunigten Aufklärung, Schwachstellensuche und laterale Bewegung auf ein Tempo, mit dem die Verteidigung nicht mithalten konnte.

Das ist der operative Beleg dafür, dass Agents die Geschwindigkeitsgleichung verändern. Der Angreifer brauchte kein Team. Der Agent war das Team.

Red-Team-Kompromittierung von McKinseys „Lilli"

In einer kontrollierten Red-Team-Übung wurde McKinseys interne KI-Plattform Lilli von einem autonomen Agenten kompromittiert, der in unter zwei Stunden breiten Systemzugriff erlangte. Bessemer Venture Partners dokumentierte das als exemplarischen Nachweis dafür, wie schnell agentische Bedrohungen menschliche Reaktionszeiten überholen.

Zwei Stunden von „Agent geht live" bis „Agent hat die Schlüssel". Das klassische Incident-Response-Playbook geht von Tagen aus. Die haben Sie nicht.

Die vier Angriffsmuster, auf die es ankommt

Destilliert aus OWASPs Top 10 für agentische Anwendungen und den Vorfallsdaten aus dem späten Jahr 2026:

1. Werkzeugmissbrauch und Rechteausweitung

Agents sind typischerweise überprivilegiert. Der am stärksten vorhersagende Risikofaktor ist überprivilegierter Zugriff: Teleports Forschung aus 2026 fand eine 4,5-mal höhere Vorfallsrate in Organisationen mit überprivilegierten KI-Systemen. Ein Agent, der „Dateien lesen muss", bekommt Schreibzugriff „für alle Fälle". Ein Agent, der „die Datenbank abfragen muss", bekommt die Admin-Zugangsdaten. Wird der Agent gekapert, ist der Wirkungsradius alles, was diese Zugangsdaten abdecken.

520 Vorfälle im Jahr 2026 wurden als Werkzeugmissbrauch oder Rechteausweitung klassifiziert, die größte Einzelkategorie in der Aufschlüsselung von Stellar Cyber.

2. Zielkaperung durch indirekte Prompt Injection

Das Ziel eines Agenten wird durch System- und Nutzer-Prompt gesetzt. Alles, was der Agent danach liest, ein Jira-Ticket, eine README, eine Kunden-E-Mail, ein PDF, kann Anweisungen enthalten, die dieses Ziel überschreiben. Die CVE-Historie für 2025 und 2026 enthält EchoLeak (CVE-2025-32711), CurXecute (CVE-2025-54135) und CVE-2025-53773, alles Varianten desselben Musters: Nicht vertrauenswürdiger Inhalt wird Teil des System-Prompts.

Für einen Agenten mit Werkzeugzugriff bedeutet Zielkaperung nicht „der Agent gibt eine schlechte Antwort". Es bedeutet „der Agent ruft das zerstörerische Werkzeug auf, mit den Parametern des Angreifers".

3. Memory Poisoning und Kompromittierung der Lieferkette

Agents haben oft persistentes Gedächtnis oder Zugriff auf langlebigen Kontext: RAG-Indizes, Vektordatenbanken, MCP-Server. Memory Poisoning und Supply-Chain-Angriffe treten seltener auf als Werkzeugmissbrauch, tragen aber überproportionale Schwere und Persistenz. Ist das Gedächtnis eines Agenten einmal vergiftet, ist jede folgende Entscheidung beeinflusst. Die Kompromittierung überlebt Sitzungsgrenzen.

Die ClawHavoc-Kampagne Anfang 2026 zeigte die Variante: bösartige Pakete, getarnt als Agent-Skills, verteilt über Community-Repositories. Einmal installiert, exfiltrierten sie Daten über den normalen Betriebskanal des Agenten.

4. Identitätsverwirrung und Confused Deputy

Agents handeln unter delegierten Zugangsdaten. Wenn Agent A Agent B beauftragt, zeigt das Audit-Log, dass B die Aktion unter As Zugangsdaten ausführte, unter denen eines Menschen oder unter gar keinen. Die NIST AI Agent Standards Initiative erkennt ausdrücklich an, dass bestehende Identitäts-Frameworks nie für diese Art von Entität entworfen wurden. Nur 21,9 Prozent der Organisationen behandeln KI-Agents derzeit als eigenständige, identitätstragende Einheiten mit eigenen Zugriffskontrollen.

Ohne Identität je Agent bricht die Zurechenbarkeit zusammen. Jede Aktion lautet „der Nutzer hat es getan", weil der Agent dessen Zugangsdaten geliehen hat. Der Nutzer hat es nicht getan.

Was echte agentenfähige Sicherheit leisten muss

Fünf Eigenschaften. Keine davon ist an diesem Punkt noch optional.

Identität je Agent und kurzlebige Zugangsdaten

Agents brauchen eigene Identitäten, keine delegierten menschlichen. Zugangsdaten müssen kurzlebig sein, auf eine einzelne Aufgabe zugeschnitten und in Echtzeit widerrufbar. NIST veröffentlicht dazu, AWS, GCP und Azure liefern langsam die nötigen Bausteine. Der Übergang zu Agenten-Identität wird Jahre dauern, die Sicherheitslücke besteht jetzt.

Prüfung von Tool-Calls an der Quelle

Die Handlungseinheit eines Agenten ist der Tool-Call. Jeder Tool-Call muss prüfbar sein: welches Werkzeug, mit welchen Argumenten, als Reaktion auf welchen Kontext. Ein SOC, das „Agent X hat Dinge getan" protokolliert, ist nutzlos. Ein SOC, das „Agent X rief destructive_action(target=Y) zum Zeitpunkt Z auf, als Reaktion auf Inhalt aus Quelle W" protokolliert, kann tatsächlich ermitteln.

Das ist der architektonische Grund, warum MCP-fähige AI-Firewalls zählen. MCP ist 2026 das De-facto-Protokoll für Tool-Calls in den großen LLM-Clients. MCP-Traffic auf dem Endpoint zu prüfen, bevor der Aufruf ausgeführt wird, macht Tool-Calls erst zu einem echten Audit-Primitiv.

Durchsetzung in Echtzeit statt nachträglicher Alarmierung

Bis das SIEM den Alarm korreliert hat, hat der Agent längst getan, was er tun wollte. Die einzige wirksame Kontrolle sitzt in der Leitung: Tool-Call prüfen, entscheiden über erlauben, verändern oder blockieren, dann ausführen. Latenz im Subsekundenbereich ist Pflicht, weil Agents mit Maschinentempo arbeiten und jede Verzögerung den Arbeitsablauf zerstört.

Verhaltens-Baselines speziell für Agents

Verhaltenserkennung für menschliche Nutzer (UEBA) lässt sich nicht auf Agents übertragen. Agents arbeiten durchgehend, in Mustern, die kein Mensch erzeugen würde. Die Baseline muss agentenspezifisch sein: Dieser Agent ruft normalerweise diese Werkzeuge auf, in dieser Reihenfolge, mit dieser Frequenz. Abweichungen sind das Signal. CVE-2026-32173, die Schwachstelle im Azure SRE Agent, wurde genau durch eine solche Verhaltensanomalie gefunden, nicht durch eine statische Signatur.

Human-in-the-Loop bei unumkehrbaren Aktionen

Manche Aktionen sind rückholbar, manche nicht. Ein Agent sollte niemals Geld überweisen, Daten löschen oder Zugriffsrechte ändern, ohne dass ein Mensch ausdrücklich zustimmt. Die Kategoriegrenze zählt mehr als das Volumen: Zehntausend routinemäßige Lesezugriffe pro Tag sind in Ordnung, ein einziges DROP TABLE beendet das Gespräch. Die Kontrolle besteht darin, die unumkehrbare Kategorie gesondert zu behandeln.

Warum der bestehende Security-Stack das nicht liefert

Kurzfassung, Kontrolle für Kontrolle:

• IAM und PAM: für Menschen gebaut. Statische Zugangsdaten, quartalsweise Prüfungen. Die Zahl von 21,9 Prozent bei der Agenten-Identität sagt alles darüber, wie weit sich das bisher bewegt hat.

• CASB: sieht SaaS-Verbindungen. Sieht nicht, was innerhalb der Tool-Call-Sequenz eines Agenten passiert. Der MCP-Traffic bleibt lokal auf dem Gerät.

• DLP: sieht Datenbewegungen auf bekannten Kanälen. Übersieht agenteninitiierte Datenflüsse, die per Tool-Call zwischen freigegebenen SaaS-Diensten laufen.

• EDR: beobachtet Prozesse auf bösartiges Verhalten. Ein Agent, der im Namen eines Nutzers legitim aussehende Dinge tut, passt auf keine bekannte Signatur.

• SIEM: korreliert Alarme im Nachhinein. Agents handeln schneller als das Korrelationsfenster. Nützlich für Forensik, nicht für Prävention.

• Cloud-AI-Gateways: sehen Prompts und Antworten auf dem Netzwerkpfad zum LLM-Anbieter. Sehen keinen lokalen MCP-Traffic, keine Tool-Calls innerhalb von Anfragen und keinen Agent-zu-Agent-Verkehr auf demselben Gerät.

Die strukturelle Lücke ist dieselbe wie bei Shadow AI insgesamt: Agents handeln auf Anwendungsebene, auf dem Endpoint, in Echtzeit. Sichtbarkeit und Kontrolle müssen dort sitzen.

Wie Sie in den nächsten 30 Tagen anfangen

Wenn Sie Agents produktiv einsetzen und keine agentenfähige Kontrolle haben:

• Inventarisieren Sie eingesetzte Agents. Über verwaltete Laptops und Server hinweg: Erfassen Sie jeden laufenden Agenten (Claude Code, Cursor, Codex, Copilot Studio, interne Agents). Die meisten Organisationen unterschätzen die Zahl um das Dreifache.

• Erfassen Sie die Rechte je Agent. Listen Sie für jeden Agenten jedes Zugangsdatum, jeden MCP-Server und jedes Werkzeug auf, worauf er Zugriff hat. Die Liste wird länger als erwartet. Kürzen Sie sie.

• Erzwingen Sie einen menschlichen Prüfpunkt für unumkehrbare Aktionen. Die meisten Agent-Frameworks unterstützen das, wenige aktivieren es standardmäßig. Schalten Sie es ein, auch wenn es Reibung kostet.

• Protokollieren Sie jeden Tool-Call, lokal. Auch ohne echte Agent-Firewall ist ein lokales Protokoll der Tool-Calls besser als nichts. Cursor und Claude Code können das in eine Datei schreiben. Tun Sie es.

• Pilotieren Sie eine agentenfähige Kontrolle in einem Team. Achten Sie gezielt auf: Prüfung von Tool-Calls, MCP-Sichtbarkeit, Durchsetzung in Echtzeit, Betrieb auf dem Gerät. Genau dort setzt die Roadmap von Patronus Protect für das dritte Quartal 2026 an.

Häufige Fragen

Ist agentische KI nur ein leistungsfähigerer Assistent oder wirklich eine neue Kategorie? Wirklich neu. Das bestimmende Merkmal ist Autonomie: Der Agent entscheidet, welche Werkzeuge er in welcher Reihenfolge aufruft, basierend auf Inhalten, die er liest. Ein Assistent sagt „du solltest X ausführen". Ein Agent führt X aus. Das Bedrohungsmodell unterscheidet sich entsprechend.

Kann ich die Autonomie einfach abschalten und für jede Aktion eine Freigabe verlangen? Können Sie, und das Ergebnis ist ein langsamerer Assistent. Der Produktivitätsnutzen von Agents bricht zusammen, wenn jeder Tool-Call eine Freigabe braucht. Das realistische Ziel lautet: Freigabe für unumkehrbare Aktionen, Beobachtbarkeit für alles andere.

Löst Zero Trust für Menschen auch agentische KI? Teilweise. Die Prinzipien gelten weiterhin: kein implizites Vertrauen, fortlaufende Verifikation, minimale Rechte. Die Umsetzung ist eine andere. Zero Trust für Agents verlangt Identität je Agent, kurzlebige Zugangsdaten und Verhaltens-Baselines in Agentengeschwindigkeit.

Wie hängt das mit dem EU AI Act zusammen? Die Betreiberpflichten nach Artikel 26 gelten für Hochrisiko-KI-Systeme, zu denen viele agentische Unternehmens-Deployments zählen. Die Protokollpflicht für Betreiber (sechs Monate Aufbewahrung, ausreichend, um zu rekonstruieren, was das System tat und warum) entspricht direkt der Anforderung „protokolliere jeden Tool-Call mit Kontext". Agentenfähige Protokollierung ist damit zugleich AI-Act-fähige Protokollierung.

Was ist mit Angriffen zwischen Agents? Offene Forschung. Das allgemeine Muster, bei dem die Ausgabe von Agent A zur Eingabe von Agent B wird, B gekapert wird und B wiederum A beeinflusst, ist dokumentiert, wird produktiv aber noch nicht breit ausgenutzt. Gegenmaßnahmen erfordern Herkunftskennzeichnung über Agentengrenzen hinweg, und die ist noch nicht standardisiert.