◄ ALLE POSTS
AI Security

Das Jahr, in dem KI-Agenten zur Angriffsfläche wurden

NW Nils Weiser 22 JUL 2026

Eine Zeit lang bedeutete „AI Security“ vor allem, einen Chatbot dazu zu bringen, etwas zu sagen, was er nicht sollte. Peinlich, gelegentlich gefährlich, aber begrenzt. Der Worst Case war schlechter Text auf einem Bildschirm. Diese Ära ist vorbei.

Die Forschung, die Mitte 2026 erscheint, dreht sich um ein anderes Problem: Was passiert, wenn ein Sprachmodell in eine Schleife eingebunden wird, die plant, Tools aufruft, Memory behält und in der Außenwelt handelt? Sobald das geschieht, hört das Modell auf, ein Textgenerator zu sein. Es wird zu einem Stück Software mit Händen.

Und Software mit Händen kann man dazu verleiten, sie zu benutzen.

Das Wichtigste in Kürze

Die Angriffe wurden konkret

Das Auffälligste an der jüngsten Welle der Agent-Security-Forschung ist, wie konkret sie geworden ist. Das ist kein abstraktes Händeringen über „Misalignment“. Das sind benannte Exploits mit Erfolgsquoten, also die Art von Sache, die man aus einem klassischen Pentest-Report erwartet. Vier davon sind mir aus den Juli-Zusammenfassungen besonders im Gedächtnis geblieben:

// GuardFall — Command-Guards von Coding-Agents ausgehebelt

Viele populäre Open-Source-Coding-Agents nutzen musterbasierte Command-Guards, im Grunde eine Allowlist, die einen Befehl prüft, bevor er in der Shell läuft. Forscher zeigten, dass klassische Shell-Quoting-Tricks diese Guards aushebeln und einen injizierten Prompt mit der Autorität des Operators an die bash durchreichen. Das Guardrail sieht funktionsfähig aus, bis zu dem Moment, in dem es das nicht mehr ist.

// AutoJack — der Agent als Remote-Shell des Angreifers

Von Microsoft dokumentiert, ist AutoJack eine Exploit-Kette gegen AutoGen Studio. Sie macht die Browsing-Fähigkeit eines Agents zur Waffe, erreicht privilegierte Dienste auf localhost und erzielt Code-Ausführung auf der Host-Maschine, ganz ohne User in the Loop. Der Agent ist die Remote-Shell des Angreifers.

// GitHub-Supply-Chain-Angriff — du reviewst sauberen Code, der Agent führt etwas anderes aus

Ein harmlos aussehendes Repository bringt den Agent dazu, Setup-Skripte auszuführen, die zur Laufzeit ein Reverse-Shell-Payload nachladen. Weil das bösartige Verhalten erst entsteht, wenn der Agent den Code ausführt, ist es für Code Review und statische Scanner unsichtbar. Du prüfst sauberen Code, ausgeführt wird etwas anderes. Genau der Punkt, der jeden, der einen Coding-Agent nutzt, unruhig machen sollte.

// Hijacking über gefälschte Bug-Reports — ~85 % Erfolgsquote

Angreifer-Anweisungen, platziert in Sentry-Error-Reports. Wenn ein Coding-Agent auf den Fehler angesetzt wird, um ihn „zu fixen“, liest und führt er stattdessen die injizierten Anweisungen aus. Berichten zufolge mit rund 85 % Erfolgsquote über die großen Plattformen hinweg. Deine Observability-Pipeline wird zum Injection-Kanal.

Vier verschiedene Angriffe, ein gemeinsames Muster: In keinem Fall wird das Modell „gehackt“ im klassischen Sinn. Es wird überredet, und zwar von Inhalten, die es ohnehin liest und für vertrauenswürdig hält. Ein Ort, an dem sich diese Überredung besonders lange hält, ist das Gedächtnis des Agents.

Memory ist die neue Frontier

Der Angriff, den ich langfristig am interessantesten finde, ist Memory Poisoning. Ein zustandsloser Agent vergisst eine Injection in dem Moment, in dem die Session endet. Aber Agenten behalten zunehmend persistentes Memory: Notizen, gelernte Präferenzen, abgerufener Kontext. Und dieses Memory ist ein Ort, an dem ein Angreifer etwas platzieren kann, das sich erst Sessions später auszahlt.

Die jüngste systematische Arbeit dazu zeigte, dass „aggressive“ memory-schreibende Agenten, also die, die eifrig speichern, was ihnen begegnet, hochgradig ausnutzbar sind und dass bestehende Prompt-Injection-Defenses das Problem kaum berühren. Ich habe diese Experimente selbst durchgeführt: Zwei ganz gewöhnliche Chat-Nachrichten genügten, um einen gehärteten Agent umzudrehen.

Die unbequeme Implikation

Die Features, die wir hinzufügen, um Agenten nützlicher zu machen, also längeres Memory, mehr Autonomie, mehr Tool-Zugriff, sind genau die Features, die den Blast Radius vergrößern. Nützlicher und angreifbarer sind hier dieselbe Bewegung.

Warum das anders ist als klassisches AppSec

Man könnte argumentieren, nichts davon sei neu. Shell Injection, Supply-Chain-Angriffe und gespeicherte Payloads sind Jahrzehnte alt. Und man hätte halb recht. Wirklich neu ist, dass die verwundbare Komponente natürliche Sprache als Anweisungen interpretiert und Anweisungen nicht zuverlässig von Daten unterscheiden kann.

Ein klassischer Parser hat eine Grammatik; er kennt den Unterschied zwischen einem Befehl und einem String. Ein Sprachmodell verarbeitet beides als undifferenzierten Text und fällt ein Urteil. Dieses Urteil ist die Schwachstelle. Und man kann sie nicht patchen, wie man einen Buffer Overflow patcht.

Deshalb konvergiert so viel der defensiven Forschung zur selben Schlussfolgerung: Man kann das Modell selbst nicht vertrauenswürdig genug machen, also muss man Grenzen um es herum bauen. Least Privilege bei Tools, Isolation von untrusted Content und die Behandlung jedes Agents als potenziell kompromittierten Insider. Wie diese Verteidigungslinie 2026 konkret aussieht, habe ich im Defense Playbook für KI-Agenten aufgeschrieben.

Was ich jedem raten würde, der heute einen Agent deployt

Geh davon aus, dass jeder Inhalt, den dein Agent liest, ob Webseite, Error-Log, Repo oder Datei, Anweisungen enthalten kann und dass dein Agent ihnen manchmal folgen wird. Dann stell die einzige Frage, die zählt:

Wenn er das tut: Was kann er tatsächlich anrichten?

Wenn die Antwort „beliebige Shell-Befehle ausführen“ oder „ausgehende Netzwerkaufrufe mit meinen Credentials machen“ enthält, dann hast du kein Prompt-Injection-Problem, sondern ein Privileg-Problem. Und Privileg-Probleme haben Lösungen, die es lange vor LLMs gab.

Die Forschung dieses Jahres liest sich wie die Frühzeit jeder neuen Plattform: ein Schwall cleverer Angriffe, ein Wettlauf um Defenses und die langsame Erkenntnis, dass die alten Sicherheitsprinzipien immer noch gelten. Sie müssen nur auf eine sehr fremdartige neue Komponente gerichtet werden.

In eigener Sache

Ich baue autonome KI-Agenten und härte sie gegen genau diese Angriffe ab (Red-Teaming, Prompt-Injection-Defense, 2. Platz in einer Prompt-Injection-Challenge). Wenn du einen Agent in Produktion hast oder planst und wissen willst, was er im Ernstfall wirklich anrichten kann: Lass uns reden.


Quellen: Adversa AI — Top Agentic AI Security Resources, July 2026; Check Point AI Security Report 2026 (via Help Net Security).

NW
Nils WeiserAI Agent Specialist · Bodenseeraum
MIT MIR ARBEITEN ▸

Weitere Field Notes

ALLE POSTS ▸