Alle paar Monate bringt ein Forschungsfeld ein Paper hervor, das weniger ein neues Ergebnis ist als eine neue Karte — ein Survey, das einen Schritt zurücktritt, alles liest und einem sagt, wie das gesamte Terrain tatsächlich aussieht. Für KI-Agent-Security kam dieses Paper 2026: eine Systematization of Knowledge (SoK), die 247 Paper verdichtet, die zwischen 2023 und 2026 erschienen sind.
Wenn du nur eine Sache liest, um dich in diesem Feld zu orientieren, würde ich argumentieren, es sollte diese sein. Ihre zentrale Behauptung ist trügerisch simpel, und ich komme immer wieder darauf zurück:
Sobald ein Sprachmodell in eine Schleife eingebunden ist, die plant, Tools aufruft, Memory behält und in der Außenwelt handelt, geht es bei Security nicht mehr um unsicheren Text, sondern um ein Software- und Systemproblem.
Dieser Satz stellt das ganze Feld leise neu auf. Jahrelang drehte sich das dominante mentale Modell von „AI Safety" um Outputs — wird das Modell etwas Schädliches sagen? Das SoK argumentiert, dieses Framing sei ein Kategorienfehler in dem Moment, in dem man einen Agent deployt. Die interessanten Fehler liegen nicht darin, was das Modell sagt; sie liegen darin, wie untrusted Information zu einer Steuerungsentscheidung wird, wie diese Entscheidung auf delegierte Autorität trifft und wie persistenter Zustand die Sicherheitseigenschaften des gesamten Systems über die Zeit verändert.
Der Lifecycle, nicht der Vorfall
Der nützlichste Beitrag des Surveys ist, dass es aufhört, Angriffe isoliert zu katalogisieren, und sie stattdessen auf den agentischen Lifecycle abbildet — acht Phasen, in denen etwas schiefgehen kann:
- Input Handling
- Planning
- Decision-Making
- Tool Execution
- Output Generation
- Memory & State
- Monitoring
- Multi-Agent Coordination
Das ist wichtig, weil es die Frage verändert, die man stellt. Statt „Ist dieser Output sicher?" fragt man „In welcher Phase hat untrusted Input die Autorität erlangt, Schaden anzurichten?" Eine Prompt Injection ist kein einzelnes Ereignis; sie ist eine Kette, die im Input Handling beginnt, das Planning überlebt und bei der Tool Execution kassiert wird. Threat-Modeling über den Lifecycle zeigt einem, wo eine Grenze sie hätte stoppen können.
Der Befund, der Verteidiger beunruhigen sollte
Hier ist der Teil, der meiner Meinung nach die meiste Aufmerksamkeit verdient. Das Survey sah sich die Defenses an, die das Feld hervorgebracht hat — Guardrails, Privilege Controls, Isolation, Provenance Tracking — und stellte fest, dass sie einzeln überwiegend funktionieren. Das Problem ist die Komposition: Sie „addieren sich nicht sauber auf". Jede Defense setzt ein anderes Trust-Modell voraus, und wenn man sie stapelt, fügen sich die Annahmen nicht zu einem kohärenten Ganzen. Man kann vier vernünftige Defenses zusammenschrauben und trotzdem eine Naht lassen, durch die ein Angreifer spaziert.
Das ist eine wirklich wichtige Einsicht, und es ist die Art Sache, die nur ein Survey zutage fördern kann, weil man sie von innerhalb eines einzelnen Papers nicht sieht. Jede einzelne Defense sieht in Ordnung aus. Die Lücke liegt in den Räumen zwischen ihnen.
Wir messen außerdem die falschen Dinge
Der zweite unbequeme Befund betrifft Benchmarks. Die meisten Agent-Security-Evaluations messen Single-Turn-, begrenzte Erfolgsquoten — hat der Angriff funktioniert, ja oder nein, in einem Schuss. Aber echte Agenten laufen lange, tragen Zustand über Sessions hinweg und koordinieren sich mit anderen Agenten.
Die untermessenen Risiken
Das Survey argumentiert, wir untermessen systematisch genau die Risiken, die im Deployment am meisten zählen: Long-Horizon-Verhalten, statusbehaftete Memory-Korruption und Multi-Agent-Propagation. Und fast niemand misst Sicherheit gemeinsam mit Nutzen, Latenz und Kosten — was dazu führt, dass man „sichere" Designs bekommt, die niemand tatsächlich ausliefert, weil sie zu langsam oder zu nutzlos sind.
Wohin das Feld gehen sollte
Das Survey landet bei vier Säulen für den Bau von Agenten, die secure by construction sind statt durch Patchen:
// Explizite Trust Boundaries
Wisse, wo vertrauenswürdige Autorität endet und untrusted Input beginnt — und setze es strukturell durch.
// Prinzipientreues least privilege
Skaliere Autorität pro Aktion, nicht pro Agent. Gib einem Agent nicht alles, was er anfassen kann.
// Provenance-getrackter Zustand
Wisse, woher jedes Stück Memory kam, damit vergifteter Zustand sich nicht in vertrauenswürdigen Kontext einschleusen kann.
// Deployment-realistische Evaluation
Miss Long-Horizon-, statusbehaftetes, Multi-Agent-Verhalten — und Sicherheit gemeinsam mit Nutzen, Latenz und Kosten.
Nichts davon ist überraschend, wenn man aus der Systems Security kommt — und genau das ist der Punkt. Die Botschaft von 247 Papern, destilliert, lautet, dass Agent Security eine Systems-Engineering-Disziplin ist, die zufällig ein Sprachmodell im Kern hat, und je früher das Feld sie so behandelt, desto schneller wird es echten Fortschritt machen.
Was ich an Survey-Papern wie diesem mag, ist, dass sie eine günstige Möglichkeit sind, Perspektive zu kaufen. Ein einziges SoK zu lesen macht dich nicht zum Forscher, aber es immunisiert dich gegen die beiden häufigsten Fehler in diesem Feld: zu glauben, das Modell sei das ganze Problem, und zu glauben, eine einzelne clevere Defense sei die ganze Lösung.
Quellen: Toward Secure LLM Agents — a 247-paper SoK; A Systematic Survey of Security Threats and Defenses in LLM-Based AI Agents (arXiv 2604.23338); Data Agents Under Attack (arXiv 2606.08661).