Bedrohungslandschaft KI-Agenten 2026: Angriffsfläche, neue TTPs und was sich dieses Jahr verändert hat

Autonome KI-Agenten sind 2026 keine Demos mehr, sondern produktive Systeme, die Code ausführen, E-Mails verschicken, Datenbanken abfragen und im Namen von Menschen Entscheidungen treffen. Genau das verschiebt die Sicherheitslage grundlegend: Ein Sprachmodell, das nur Text zurückgibt, hat eine begrenzte Wirkung. Ein Agent, der Werkzeuge bedient und ein Gedächtnis besitzt, kann kompromittiert werden – und der Schaden landet dann nicht im Chatfenster, sondern in Ihren Systemen.

Dieser Pillar-Artikel ordnet die Bedrohungslandschaft KI-Agenten für das Jahr 2026 ein: Wie sieht die Angriffsfläche autonomer Agenten konkret aus, welche neuen TTPs (Taktiken, Techniken und Prozeduren) haben sich etabliert, und was hat sich gegenüber 2025 tatsächlich verändert. Wir stützen uns dabei auf die einschlägigen Referenzwerke – OWASP, MITRE ATLAS und die regulatorische Lage in der EU – und nennen nur überprüfbare Fakten.

Was hat sich 2026 an der Bedrohungslage für KI-Agenten verändert?

Kurz gesagt: Die Angriffsfläche ist von „dem Modell“ auf „das gesamte Agentensystem“ gewachsen, und die Angriffe sind von akademischen Beispielen zu real beobachteten Vorfällen geworden. Drei Entwicklungen prägen das Jahr 2026.

Erstens hat das OWASP Gen AI Security Project im Dezember 2025 die erste peer-reviewte „Top 10 für Agentic Applications“ (2026) veröffentlicht – mit zehn Risikoklassen von ASI01 bis ASI10, an denen über 100 Sicherheitsexperten mitgewirkt haben. Damit existiert erstmals ein konsolidiertes Referenzmodell, das sich nicht mehr nur auf Sprachmodelle, sondern explizit auf autonome Agenten bezieht. Das ist der entscheidende konzeptionelle Bruch: Agentensicherheit wird als eigene Disziplin behandelt, nicht als Anhängsel der LLM-Sicherheit.

Zweitens hat MITRE ATLAS seine Wissensbasis um agentenspezifische Techniken erweitert. Im Oktober 2025 wurden in Zusammenarbeit mit Zenity Labs 14 neue Angriffstechniken und Subtechniken aufgenommen, die sich gezielt auf KI-Agenten richten. Das Update v5.3.0 vom Januar 2026 ergänzte zudem Fallstudien zu kompromittierten MCP-Servern, indirekter Prompt Injection über MCP-Kanäle und der Verbreitung bösartiger Agenten. Angriffe wie Memory Poisoning (AML.T0080) oder Tool Poisoning (AML.T0110) sind damit nicht länger Hypothesen, sondern formal dokumentierte Verfahren.

Drittens ist das Model Context Protocol (MCP) – der De-facto-Standard, über den Agenten externe Werkzeuge anbinden – vom Versprechen zur Angriffsfläche geworden. Das erste bösartige MCP-Paket wurde im September 2025 beobachtet, und mit CVE-2025-6514 wurde eine kritische Befehlsinjektion in einem weit verbreiteten OAuth-Proxy (mcp-remote) dokumentiert, die Remote Code Execution auf dem Client ermöglichte. Anders formuliert: Die Lieferkette der Werkzeuge, die ein Agent nutzt, ist 2026 selbst zum Ziel geworden.

Der gemeinsame Nenner dieser drei Entwicklungen: Es geht nicht mehr darum, ob ein Modell eine unerwünschte Antwort gibt, sondern darum, dass ein autonomes System mit echten Berechtigungen unter fremde Kontrolle geraten kann.

Was genau ist die Angriffsfläche autonomer Agenten?

Die Angriffsfläche der Agenten 2026 lässt sich nur verstehen, wenn man einen Agenten nicht als „Chatbot mit Extras“ begreift, sondern als verteiltes System aus mehreren Komponenten, die jede für sich angreifbar sind. Ein produktiver Agent besteht typischerweise aus sechs Bausteinen – und jeder erweitert die Angriffsfläche auf eigene Weise.

Das Modell (Reasoning-Kern). Das Sprachmodell trifft Entscheidungen auf Basis seines Kontextfensters. Alles, was in diesen Kontext gerät – Systemanweisung, Nutzereingabe, abgerufene Dokumente, Werkzeug-Ausgaben –, kann sein Verhalten beeinflussen. Die Grenze zwischen „Daten“ und „Anweisung“ ist im Modell physisch nicht vorhanden; genau das ist die Wurzel der Prompt Injection.

Die Werkzeuge (Tools/Functions). Sobald ein Agent Funktionen aufrufen darf – eine Datei lesen, eine API ansprechen, eine Zahlung auslösen –, wird aus einer Textausgabe eine Handlung mit Nebenwirkungen. Jedes Werkzeug ist ein potenzieller Hebel: Wer das Modell dazu bringt, das falsche Werkzeug mit den falschen Parametern aufzurufen, erreicht eine reale Wirkung.

Das Gedächtnis (Memory). Persistentes Gedächtnis ist der größte Unterschied zwischen einem Agenten und einem zustandslosen Chat. Was einmal als „Fakt“ oder „Nutzerpräferenz“ im Speicher landet, beeinflusst alle künftigen Sitzungen. Damit wird das Gedächtnis zu einem dauerhaften Einfallstor: Eine einmal eingeschleuste Anweisung wirkt fort, lange nachdem der ursprüngliche Angriffsvektor geschlossen wurde.

Die Orchestrierung (Planning/Control Flow). Agenten zerlegen Ziele in Teilschritte, planen, korrigieren und wiederholen. Diese Schleife ist manipulierbar: Wird das Ziel verschoben (Goal Hijacking), arbeitet der Agent zuverlässig auf ein fremdes Ziel hin – mit der vollen Entschlossenheit, die ihn eigentlich nützlich macht.

Die Identität und Berechtigungen (Identity/Privileges). Ein Agent handelt selten unter der eingeschränkten Berechtigung des Endnutzers, sondern oft mit einem breiter angelegten Dienstkonto oder OAuth-Token. Diese Diskrepanz ist die Grundlage des „Confused Deputy“-Problems: Der Agent ist ein berechtigter Stellvertreter mit mehr Rechten, als der Auslöser eigentlich besitzt.

Die Inter-Agenten-Kommunikation. In Multi-Agenten-Architekturen geben Agenten Aufgaben aneinander weiter. Eine kompromittierte Nachricht zwischen zwei Agenten ist schwer zu kontrollieren, weil das empfangende System der Quelle implizit vertraut. Genau hier entstehen Kaskadenfehler, bei denen ein einziger fehlgeleiteter Agent ein ganzes Kollektiv mitreißt.

Der OWASP-Leitfaden „Securing Agentic Applications“ (Juli 2025) macht deutlich, dass diese Angriffsfläche kein Fixum ist: Ein sequenzieller Agent mit einem einzigen Modell und eng begrenztem API-Zugriff hat ein anderes Risikoprofil als ein hierarchischer Orchestrator mit spezialisierten Subagenten oder gar ein kollaborativer Agenten-Schwarm mit geteiltem, sitzungsübergreifendem Gedächtnis. Mit der Architektur wächst die Angriffsfläche.

Welche neuen TTPs prägen die Bedrohungslandschaft 2026?

Die neuen TTPs lassen sich grob in zwei Gruppen teilen: solche, die wirklich neu für Agenten sind, und solche, die alte LLM-Schwächen auf gefährliche Weise verstärken. OWASP hat in seinem Dokument „Agentic AI – Threats and Mitigations“ (v1.0a, Februar 2025) 15 Bedrohungskategorien beschrieben und genau diese Unterscheidung getroffen. Hier die Verfahren, die 2026 die Praxis bestimmen.

Wie funktioniert indirekte Prompt Injection bei Agenten?

Bei der direkten Prompt Injection (MITRE ATLAS AML.T0051) gibt ein Angreifer schädliche Anweisungen direkt ein. Bei der indirekten Variante – der für Agenten gefährlicheren – versteckt der Angreifer die Anweisung dort, wo der Agent ohnehin liest: in einer Webseite, einer E-Mail, einem PDF, einem Kalendereintrag, einem Git-Issue. Sobald der Agent dieses Material in seinen Kontext zieht, behandelt er die versteckte Anweisung wie eine legitime Vorgabe.

Das ist der entscheidende Punkt: Der Nutzer sieht die Anweisung nie, der Agent befolgt sie trotzdem. Für ein autonomes System, das selbstständig Webseiten abruft oder Postfächer durchsucht, ist jede externe Datenquelle damit ein potenzieller Befehlskanal. Die indirekte Prompt Injection ist deshalb weniger eine einzelne Schwachstelle als ein struktureller Konstruktionsfehler aktueller Agenten.

Was bedeutet Memory Poisoning und warum ist es so heikel?

Memory Poisoning (MITRE ATLAS AML.T0080) beschreibt das Einschleusen unautorisierter Anweisungen oder „Fakten“ in das persistente Gedächtnis eines Agenten. Einmal vergiftet, behandelt der Agent diese Einträge als legitime Nutzerpräferenzen und richtet sein künftiges Verhalten danach aus – über Sitzungsgrenzen hinweg.

Das Tückische daran ist die Zeitverschiebung zwischen Ursache und Wirkung. Der Angriff erfolgt einmal; die Wirkung entfaltet sich Tage oder Wochen später, in einem völlig anderen Kontext, möglicherweise gegenüber einem anderen Nutzer, der dasselbe Gedächtnis teilt. Microsoft beschrieb im Februar 2026 eine kommerzielle Spielart davon – „AI Recommendation Poisoning“ –, bei der manipulierte Speicherinhalte ein Assistenzsystem dazu bringen, bestimmte Produkte oder Anbieter zu bevorzugen. Memory Poisoning ist damit nicht nur ein Sicherheits-, sondern auch ein Integritäts- und Wettbewerbsproblem.

Was ist Tool Poisoning und wie hängt es mit MCP zusammen?

Tool Poisoning (AML.T0110) bettet schädliche Anweisungen in die Metadaten und Beschreibungen von Werkzeugen ein. Der Mechanismus ist subtil: Wenn ein Agent über MCP ein Werkzeug anbindet, liest das Modell die Beschreibung dieses Werkzeugs – „Diese Funktion sendet E-Mails“ – als Teil seines Kontexts. Steht in dieser Beschreibung eine versteckte Anweisung, befolgt das Modell sie. Der Nutzer sieht nur den freundlichen Werkzeugnamen, das Modell sieht den vergifteten Beipackzettel.

Die Lage verschärft sich dadurch, dass die meisten MCP-Clients server-seitig bereitgestellte Metadaten ohne strenge Prüfung übernehmen – die MCP-Spezifikation verlangt keine clientseitige Validierung. Empirische Tests zeigten, dass die Mehrzahl der untersuchten Clients keine statische Prüfung der Werkzeugbeschreibungen vornimmt. Wer einen bösartigen MCP-Server unterschiebt, kann damit das Verhalten jedes Agenten steuern, der ihn anbindet. Eine kompakte Definition dieses Vergiftens von Werkzeug-Metadaten finden Sie im Glossar.

Was ist das Confused-Deputy-Problem bei Agenten?

Das Confused-Deputy-Problem verstärkt Tool Poisoning auf gefährliche Weise. Selbst wenn ein vergiftetes Werkzeug erkannt wird, ermöglichen zu weit gefasste Zugriffstoken den Zugriff über legitime Werkzeuge. Der MCP-Server – oder der Agent selbst – handelt im Namen eines Nutzers, aber mit breiteren Rechten, als dieser Nutzer eigentlich besitzt. Eine OAuth-Fehlkonfiguration genügt, und ein eigentlich harmloser Aufruf erreicht Ressourcen, die dem Auslöser verschlossen bleiben sollten.

Wie entstehen Kaskadenfehler in Multi-Agenten-Systemen?

In Architekturen mit mehreren Agenten ist die Inter-Agenten-Kommunikation ein eigener Angriffsvektor. Ein Orchestrator delegiert an Subagenten; die Antworten dieser Subagenten fließen ungeprüft in die nächste Planungsstufe ein. Wird ein einzelner Agent kompromittiert, kann er manipulierte Zwischenergebnisse weiterreichen, die das Kollektiv übernimmt. Aus einem lokalen Fehler wird so ein systemischer – ein Kaskadenfehler, der schwer einzugrenzen ist, weil die Agenten einander implizit vertrauen. Wie sich daraus eigene Angriffsklassen wie die Übernahme des Multi-Agenten-Konsenses und die Verwirrung der Kontextgrenzen entwickeln, behandeln wir gesondert.

Was ist ein „Rogue Agent“?

Schließlich beschreibt OWASP für 2026 die Klasse der abtrünnigen Agenten (Rogue Agents): autonome Komponenten, die außerhalb der vorgesehenen Grenzen operieren – sei es, weil sie kompromittiert wurden, sei es durch fehlausgerichtete Ziele (Goal Misalignment) und emergentes Verhalten. Ein Agent, der seine Aufgabe „zu wörtlich“ oder „zu kreativ“ interpretiert, kann ohne jeden externen Angreifer Schaden anrichten. Das ist die unbequeme Wahrheit der Agentensicherheit 2026: Nicht jede Bedrohung braucht einen Angreifer; manche entstehen aus der Autonomie selbst.

Wie ordnen OWASP und MITRE ATLAS die Bedrohungen 2026 ein?

Für die Praxis ist es wichtig, die beiden zentralen Referenzwerke auseinanderzuhalten, weil sie unterschiedliche Fragen beantworten. OWASP liefert eine Risikotaxonomie für Entwickler und Verteidiger („Was kann schiefgehen und wie verhindere ich es?“). MITRE ATLAS liefert eine Angreifer-Wissensbasis nach dem Vorbild von ATT&CK („Welche konkreten Techniken setzen Angreifer ein?”). Beide ergänzen sich.

Aspekt	OWASP Top 10 for Agentic Applications (2026)	MITRE ATLAS (v5.3.0, Jan. 2026)
Perspektive	Verteidiger / Entwickler	Angreifer / Threat Intelligence
Struktur	10 Risikoklassen (ASI01–ASI10)	Taktiken, Techniken, Subtechniken, Fallstudien
Schwerpunkt 2026	Goal Hijacking, Tool-Missbrauch, Identität/Privilegien, Memory Poisoning, Inter-Agenten-Kommunikation, Rogue Agents	agentenspezifische Techniken (14 neu seit Okt. 2025), MCP-Kompromittierung
Beispiel-Eintrag	ASI: Memory Poisoning	AML.T0080: Memory Poisoning
Nutzen	Priorisierung von Schutzmaßnahmen	Erkennung, Red Teaming, Detektionslogik

Die Konvergenz ist bemerkenswert: Beide Frameworks benennen Memory Poisoning, Tool-Missbrauch und Prompt Injection als Kernrisiken – aus jeweils anderer Richtung. Wer Agentensicherheit ernst nimmt, nutzt OWASP zur Priorisierung von Schutzmaßnahmen und ATLAS, um Erkennung und Red Teaming an realen Angreifer-Techniken auszurichten. Wie sich jede Angriffsphase konkret den ATLAS-Taktiken und ihren Erkennungssignalen zuordnen lässt, und wie die zehn ASI-Risikoklassen im Detail aussehen, vertiefen zwei eigene Beiträge. Ergänzend kursiert mit MAESTRO ein dritter Ansatz, der die Bedrohungsmodellierung über die Schichten eines Agentensystems hinweg strukturiert.

Das OWASP-Dokument von Februar 2025 unterscheidet außerdem zwischen Bedrohungen, die vollständig neu für agentische KI sind, und solchen, die bekannte LLM-Schwächen lediglich verstärken. Diese Unterscheidung ist praktisch wertvoll: Sie zeigt, wo bestehende Sicherheitskontrollen (Eingabevalidierung, Rechtevergabe, Protokollierung) weiterhin greifen – und wo wirklich neue Werkzeuge nötig sind.

Welche realen Vorfälle prägen 2026 die Lage?

Die Bedrohungslandschaft 2026 ist deshalb ernst zu nehmen, weil sie nicht mehr nur aus Laborbeispielen besteht. Einige überprüfbar dokumentierte Ereignisse markieren die Wende.

CVE-2025-6514 – Befehlsinjektion in mcp-remote. Diese kritische Schwachstelle in einem weit verbreiteten OAuth-Proxy für MCP erlaubte einem bösartigen Server, über eine manipulierte authorization_endpoint-URL Befehle an die System-Shell des Clients durchzureichen – bis hin zur Remote Code Execution auf dem Rechner des Nutzers. Sie zeigt exemplarisch, dass die Werkzeug-Anbindung selbst, nicht nur das Modell, eine klassische Code-Schwachstelle einschleppen kann.

Erstes bösartiges MCP-Paket (September 2025). Mit dem Auftauchen des ersten schädlichen MCP-Pakets wurde Tool Poisoning von der Theorie zur beobachteten Praxis. Die Lieferkette der Agenten-Werkzeuge ist damit endgültig ein Angriffsziel – analog zu kompromittierten npm- oder PyPI-Paketen, nur dass hier zusätzlich das Verhalten des Modells gesteuert werden kann.

Asana-AI-Vorfall (Mai 2025). Ein Fehler in der Mandantentrennung führte dazu, dass Daten organisationsübergreifend vermischt werden konnten – mit Auswirkungen auf bis zu rund 1.000 Unternehmen. Der Vorfall illustriert, dass Isolationsfehler in KI-gestützten Funktionen denselben Schaden anrichten wie klassische Multi-Tenancy-Lücken, nur in einer neuen Schicht.

Diese Vorfälle eint, dass keiner von ihnen ein „böses Modell“ voraussetzt. Es genügten eine Code-Schwachstelle, ein vergiftetes Paket und ein Isolationsfehler – vertraute Kategorien, die durch die Autonomie der Agenten lediglich gefährlicher werden. Wie sich eine solche Kette von der Prompt Injection bis zur Exfiltration im Detail abspielt, zeigt unsere Breach-Analyse realer KI-Agenten-Vorfälle wie EchoLeak und des GitHub-MCP-Heists.

Wie verändert die EU-Regulierung 2026 das Risikomanagement?

Für Unternehmen im DACH-Raum ist die regulatorische Lage Teil der Bedrohungslandschaft, weil sie definiert, welche Sorgfalt nachweisbar verlangt wird. Der EU AI Act (in der DACH-Praxis oft „KI-Verordnung“ genannt) entfaltet 2026 weitere Wirkung.

Die Verordnung wird am 2. August 2026 weitgehend anwendbar, einschließlich der Transparenzpflichten nach Artikel 50. Die Pflichten für allgemeine KI-Modelle (GPAI) gelten bereits seit dem 2. August 2025. Zugleich hat eine politische Einigung über das „Digital Omnibus“-Paket einige Fristen für Hochrisiko-Systeme verschoben – für eigenständige Annex-III-Systeme auf den 2. Dezember 2027. Wer plant, sollte diese Verschiebung kennen, sie aber nicht als Entwarnung missverstehen. Wie diese Hochrisiko-Einstufungen in Finanzwesen, Gesundheitswesen und Rechtsbereich konkret durchschlagen, zeigt unsere branchenspezifische Analyse.

Wichtig für die Agentensicherheit: Anbieter von GPAI-Modellen mit systemischem Risiko unterliegen Risikomanagementpflichten, die ausdrücklich die autonomen Fähigkeiten und die agentische Nutzung eines Modells berücksichtigen. Die EU-Kommission betont allerdings, dass ihre regulatorischen Überlegungen zu KI-Agenten angesichts der schnellen Entwicklung vorläufig sind und das KI-Büro die Lage weiter beobachtet. Praktisch heißt das: Verlassen Sie sich nicht auf eine fertige Checkliste aus Brüssel, sondern bauen Sie ein eigenes, an OWASP und ATLAS orientiertes Risikomanagement auf. Hinzu kommt die DSGVO, deren Anforderungen an Datenminimierung und Zweckbindung für Agenten mit weitreichendem Datenzugriff unmittelbar relevant bleiben.

Welche Schutzmaßnahmen sind 2026 wirklich wirksam?

Die gute Nachricht: Ein großer Teil der Agentensicherheit besteht aus bewährten Prinzipien, konsequent auf die neue Architektur angewendet. Die folgenden Maßnahmen adressieren die oben beschriebenen TTPs direkt und lassen sich überprüfbar umsetzen.

Geringstmögliche Privilegien pro Werkzeug. Geben Sie jedem Agenten und jedem Werkzeug nur die Rechte, die für die konkrete Aufgabe nötig sind. Das schmälert sowohl das Confused-Deputy-Problem als auch den Schaden eines kompromittierten Werkzeugs. Eng gefasste, kurzlebige Token statt breiter Dienstkonten sind hier der Hebel.

Trennung von Daten und Anweisungen, soweit möglich. Behandeln Sie alles, was aus externen Quellen in den Kontext gelangt – Webinhalte, E-Mails, Dokumente, Werkzeug-Ausgaben –, als nicht vertrauenswürdige Daten und nicht als Befehle. Diese Trennung lässt sich technisch nie perfekt erzwingen, aber durch klare Kontextstrukturierung, Markierung externer Inhalte und nachgelagerte Prüfung deutlich verbessern.

Validierung von MCP-Servern und Werkzeug-Metadaten. Übernehmen Sie Werkzeugbeschreibungen nicht ungeprüft. Pinnen Sie MCP-Server-Versionen, prüfen Sie Metadaten statisch, und behandeln Sie die Werkzeug-Lieferkette mit derselben Sorgfalt wie Software-Abhängigkeiten – inklusive Herkunftsprüfung und Allowlists.

Schutz des Gedächtnisses. Validieren Sie, was in das persistente Gedächtnis geschrieben wird, trennen Sie Gedächtnis nach Mandant und Nutzer, und ermöglichen Sie Audit und Rücknahme einzelner Einträge. Ein Gedächtnis, das man nicht inspizieren und bereinigen kann, ist ein dauerhaftes Risiko.

Mensch in der Schleife für folgenreiche Aktionen. Aktionen mit irreversiblen oder kostspieligen Nebenwirkungen – Zahlungen, Löschungen, externe Veröffentlichungen – sollten eine ausdrückliche Bestätigung erfordern. Das begrenzt den Schaden von Goal Hijacking und Rogue-Agent-Verhalten.

Beobachtbarkeit und Protokollierung. Protokollieren Sie Werkzeugaufrufe, Parameter, Gedächtniszugriffe und Inter-Agenten-Nachrichten lückenlos. Ohne diese Spur ist weder Erkennung noch Forensik möglich – und die meisten der oben genannten Techniken hinterlassen genau hier ihre Signatur.

Red Teaming entlang von ATLAS. Testen Sie Ihre Agenten gezielt gegen die dokumentierten Techniken – indirekte Prompt Injection, Memory Poisoning, Tool Poisoning. MITRE ATLAS bietet dafür die strukturierte Grundlage; spezialisierte Frameworks für LLM-Red-Teaming setzen darauf auf.

Keine dieser Maßnahmen ist für sich genommen ausreichend. Wirksame Agentensicherheit 2026 ergibt sich aus der Tiefenstaffelung: mehrere unabhängige Kontrollen, sodass das Versagen einer Schicht nicht das gesamte System öffnet.

Worauf sollten Sicherheitsverantwortliche im DACH-Raum jetzt achten?

Für CISOs, Sicherheitsarchitekten und Entwicklungsleiter lässt sich die Lage in drei Prioritäten verdichten.

Erstens: Inventarisieren Sie Ihre Agenten und deren Werkzeuge. Viele Organisationen haben 2026 mehr produktive Agenten im Einsatz, als ihre Sicherheitsteams kennen – über Plattformen wie Microsoft Copilot, über Eigenentwicklungen und über eingebettete Funktionen in SaaS-Produkten. Ohne Inventar gibt es keine Angriffsflächenanalyse.

Zweitens: Behandeln Sie die Werkzeug-Lieferkette als kritisch. Die Verschiebung von 2025 zu 2026 ist im Kern eine Lieferkettengeschichte – vergiftete MCP-Pakete, anfällige Proxys, ungeprüfte Werkzeug-Metadaten. Die Disziplin, die Sie auf npm- und PyPI-Abhängigkeiten anwenden, gehört nun auch auf MCP-Server und Agenten-Werkzeuge.

Drittens: Verankern Sie Agentensicherheit in einem anerkannten Rahmenwerk. Nutzen Sie die OWASP Top 10 for Agentic Applications zur Priorisierung und MITRE ATLAS für Erkennung und Tests. Das schafft eine gemeinsame Sprache mit Auditoren, Versicherern und – mit Blick auf den EU AI Act – Aufsichtsbehörden.

Die Bedrohungslandschaft KI-Agenten ist 2026 nicht aus dem Nichts entstanden. Sie ist die logische Folge davon, dass wir Sprachmodellen Hände gegeben haben: Werkzeuge, Gedächtnis und Autonomie. Genau deshalb ist die Antwort keine einzelne Wunderlösung, sondern dieselbe ingenieurmäßige Sorgfalt, die wir für jedes andere mächtige System verlangen – nur konsequent auf eine neue Architektur angewendet.

---

Dieser Artikel dient der allgemeinen Information und ersetzt keine individuelle Sicherheits- oder Rechtsberatung. Die genannten Frameworks, CVEs und regulatorischen Fristen entsprechen dem Stand der zugrunde liegenden Quellen (OWASP Gen AI Security Project, MITRE ATLAS, Europäische Kommission) und können sich weiterentwickeln.