OWASPs LLM Top 10 2026 zeichnen die Risikolandkarte für agentische Sicherheit neu

Weniger als zwei Wochen nachdem OWASP seinen aktualisierten Leitfaden am 3. August veröffentlicht hatte, brachte Akamai die OWASP LLM Top 10 2026 in Google News. Das Timing unterstreicht einen Sicherheitskonflikt, der inzwischen weit über unsichere Modellantworten hinausgeht. KI-Anwendungen statten Modelle zunehmend mit Tools, Speicher, Zugangsdaten und Handlungsbefugnissen aus.

Die neue Risikolandkarte spiegelt diesen Wandel wider. Prompt Injection bleibt ein zentrales Problem, doch eine manipulierte Antwort ist nicht länger das schlimmstmögliche Ergebnis. Eine eingeschleuste Anweisung kann einen Agenten umleiten, ein Tool auslösen, persistenten Speicher verändern, Zugangsdaten offenlegen oder sich über verbundene Agenten verbreiten.

Dieser Übergang erhöht zugleich den Druck auf Unternehmen, die Assistenten für E-Mails, Kundenservice, Softwareentwicklung und interne Wissenssysteme einsetzen. Herkömmliche Anwendungskontrollen bleiben wichtig, steuern Systeme jedoch nicht vollständig, wenn diese probabilistische Entscheidungen über mehrstufige Arbeitsabläufe hinweg treffen.

Akamais Analyse erscheint parallel zu den eigenen Vorstößen des Unternehmens in die Agentensicherheit. Das Unternehmen hat die Inspektion von KI-Datenverkehr, Agentenidentität, Verhaltensanalyse und Durchsetzung am Netzwerkrand in einem umfassenderen kommerziellen Rahmen verbunden. Das macht seine Einordnung nützlich, verlangt aber auch eine kritische Prüfung als Anbieterperspektive auf einen entstehenden Markt.

Die tiefere Geschichte ist keine neue Liste von zehn isolierten Schwachstellen. Sie ist ein Wandel vom Schutz der Ein- und Ausgaben eines Modells hin zur Kontrolle einer gesamten Ausführungskette. Die Sicherheitsgrenze umfasst nun jedes Dokument, das ein Agent liest, jedes Tool, das er aufruft, und jede Identität, die er annehmen kann.

Google News erfasst einen umfassenderen OWASP-Sicherheitswandel

Das OWASP-Update verwandelt LLM-Sicherheit von einem Modellproblem in ein anwendungsweites Kontrollproblem.

OWASP veröffentlichte seinen LLM-Leitfaden für 2026 am 3. August 2026. Die Organisation beschreibt ihn als gemeinschaftlich entwickelten Leitfaden, an dem Hunderte KI-Sicherheitsexperten mitwirkten. Die Arbeit stütze sich auf Tausende reale Sicherheitsvorfälle.

Der Leitfaden aktualisiert Rangfolgen und erweitert die Bedrohungsabdeckung für Anwendungen, die von Large Language Models betrieben werden. Außerdem ordnet er seine Risiken NIST, MITRE ATLAS, CWE sowie OWASPs separatem Rahmenwerk für agentische Anwendungen zu.

Diese Zuordnung über mehrere Rahmenwerke hinweg ist bedeutsamer als eine bloße Ranglistenänderung. Sie erkennt an, dass LLM-Fehler selten auf eine Chat-Oberfläche begrenzt bleiben. Moderne Systeme verbinden Modelle mit Retrieval, Speicher, Application Programming Interfaces, Identitätsdiensten und ausführbaren Tools.

Die vorherige Risikoliste für 2025 spiegelte einen Teil dieser Ausweitung bereits wider. Zu ihren Kategorien gehörten Prompt Injection, Offenlegung sensibler Informationen, Schwächen in der Lieferkette, Datenvergiftung, unsachgemäße Verarbeitung von Ausgaben und übermäßige Handlungsbefugnisse.

Lecks von System Prompts, Schwächen bei Vektoren und Embeddings, Fehlinformationen und unbegrenzter Ressourcenverbrauch vervollständigten diese Ausgabe. Diese Kategorien betrafen Anwendungen rund um das Modell und nicht nur Schwächen in Modellgewichten.

Die Veröffentlichung für 2026 macht die Beziehung zu autonomen Systemen expliziter. Eine LLM-Anwendung kann Fragen beantworten, während ein Agent eine Abfolge von Aktionen planen und ausführen kann. Dieser Unterschied verändert, wie Verteidiger Auswirkungen berechnen.

Eine falsche Antwort eines Support-Chatbots kann einen Kunden in die Irre führen. Eine falsche Entscheidung eines Support-Agenten könnte ein Konto ändern, eine Erstattung auslösen oder Datensätze offenlegen. Dasselbe Modellverhalten führt zu einem anderen Sicherheitsergebnis, sobald Tools und Berechtigungen in den Arbeitsablauf eingebunden werden.

Prompt Injection veranschaulicht den Unterschied. Sie tritt auf, wenn präparierte Eingaben das Verhalten eines Modells unbeabsichtigt verändern. Die Eingabe kann direkt von einem Nutzer oder indirekt aus Inhalten stammen, die das System abruft.

Indirekte Injection macht gewöhnliche Geschäftsinhalte zu einem Teil der Angriffsfläche. Eine bösartige Anweisung könnte in einer E-Mail, einer Webseite, einem freigegebenen Dokument, einem Support-Ticket oder einem abgerufenen Wissenseintrag stehen. Der Agent trifft darauf, während er eine legitime Aufgabe erledigt.

Das Problem besteht nicht nur darin, dass das Modell bösartigen Text wiederholen könnte. Es könnte diesen Text als Anweisung behandeln und seine Auswirkungen an eine andere Komponente weitergeben. Tool-Zugriff verwandelt einen Fehler bei der Sprachinterpretation in ein operatives Sicherheitsereignis.

Die Verbreitung über Google News verschafft diesem spezialisierten Rahmenwerk ein breiteres Publikum. Der Aggregationskanal sollte jedoch nicht mit der Primärevidenz verwechselt werden. OWASPs Veröffentlichung und die zugrunde liegenden technischen Materialien bleiben die maßgeblichen Referenzen.

Das Ereignis hat daher zwei Ebenen. Die sichtbare Ebene besteht darin, dass Akamai ein neu veröffentlichtes Risikorahmenwerk erklärt. Die wichtigere Ebene ist, dass OWASP Risiken von LLM-Anwendungen formal mit Risiken agentischer Ausführung verknüpft.

Diese Verbindung bildet die zentrale Spannung des Artikels. Unternehmen möchten, dass Agenten mehr Arbeit ohne ständige Eingriffe erledigen. Jede zusätzliche Berechtigung erhöht jedoch auch den Schaden, den eine kompromittierte Anweisung verursachen kann.

Agentische Anwendungen gefährden Tools, Identität und Speicher

Der Wert eines Agenten beruht auf seiner Handlungsfähigkeit, doch genau diese Fähigkeit vergrößert den Schadensradius jedes Kontrollversagens.

OWASP veröffentlichte seine agentischen Top 10 am 9. Dezember 2025. Mehr als 100 Branchenexperten, Forscher und Praktiker trugen zu dem begutachteten Rahmenwerk bei.

Die agentische Liste umfasst Zielentführung, Tool-Missbrauch, Identitätsmissbrauch, Schwachstellen in der Lieferkette, unerwartete Codeausführung und Speichervergiftung. Sie behandelt außerdem unsichere Kommunikation zwischen Agenten, Kaskadenfehler, die Ausnutzung menschlichen Vertrauens und abtrünnige Agenten.

Diese Kategorien ersetzen die LLM-Liste nicht. Sie beschreiben, was geschieht, wenn vertraute Modellschwächen mit Autonomie, persistentem Zustand, delegierten Berechtigungen und mehreren Systemen interagieren.

Die Entführung von Agentenzielen erweitert die Logik von Prompt Injection. Ein Angreifer muss weder ein Modell umschreiben noch dessen Infrastruktur kompromittieren. Stattdessen lenkt er den Agenten von dem Ziel ab, das dessen Eigentümer beabsichtigt hatte.

Stellen Sie sich einen Agenten vor, der ein Postfach zusammenfassen soll. Eine Nachricht enthält versteckte Anweisungen, die den Agenten dazu auffordern, nach vertraulichen Dateien zu suchen. Wenn das System Daten nicht von Befehlen trennen kann, kann der Agent das Ziel des Angreifers übernehmen.

Akamai beschreibt dieses Szenario in seiner Analyse zur Absicherung von Agenten. Die Forscher argumentieren, dass Anweisungs- und Informationskanäle unterschiedliche Verarbeitungspfade und Berechtigungsstufen erfordern.

Tool-Missbrauch bildet das nächste Glied in der Kette. Ein eingeschleustes Ziel hat begrenzte Auswirkungen, wenn das Modell nur Text erzeugen kann. Das Risiko verändert sich, wenn dasselbe Modell eine Shell aufrufen, Dateien ändern, externe Dienste ansprechen oder Datenbanken abfragen kann.

Ein universelles Shell-Tool ist besonders schwer zu kontrollieren. Es stellt viele Aktionen über eine Schnittstelle bereit und macht Autorisierungsentscheidungen weniger granular. Ein enger gefasstes Tool kann einen Agenten auf definierte Operationen und Verzeichnisse beschränken.

Identitäts- und Berechtigungsmissbrauch fügen eine weitere Ebene hinzu. Viele Agenten arbeiten mit den Berechtigungen der Person, die sie installiert oder autorisiert hat. Ein kompromittierter Agent kann daher Zugriff übernehmen, der für einen vertrauenswürdigen Mitarbeiter vorgesehen war.

Dedizierte Dienstidentitäten können diese Gefährdung verringern. Ihre Berechtigungen sollten eng begrenzt, temporär und von interaktiven Nutzersitzungen getrennt sein. Sensible Aktionen benötigen außerdem eine erneute Autorisierung, statt sich auf eine frühere pauschale Genehmigung zu stützen.

Persistenter Speicher verändert die Dauer eines Angriffs. Eine in den Speicher geschriebene bösartige Anweisung kann spätere Sitzungen beeinflussen, nachdem die ursprüngliche Eingabe verschwunden ist. Dies wird als Speichervergiftung bezeichnet: Feindselige Inhalte korrumpieren Informationen, die der Agent als vertrauenswürdigen Kontext behandelt.

Unternehmen legen bereits umfangreiches Betriebswissen in Retrieval-Systemen und KI-Arbeitsbereichen ab. Eine durchsuchbare Wissensdatenbank kann den Zugriff auf technische Aufzeichnungen verbessern, doch ihre Herkunft und Berechtigungen bleiben entscheidend.

Wissen und Anweisungen dürfen nicht austauschbar werden. Abgerufene Materialien sollten Fakten für eine Aufgabe liefern, ohne die Betriebsregeln des Agenten stillschweigend zu verändern. Systeme benötigen zudem Aufzeichnungen darüber, welche Quelle jede folgenreiche Aktion beeinflusst hat.

Die Kommunikation zwischen Agenten schafft weitere Unsicherheit. Ein Agent kann der Ausgabe eines anderen Agenten vertrauen, ohne dessen Herkunft, Berechtigungen oder frühere Eingaben zu kennen. Ein kompromittierter Teilnehmer kann vergifteten Kontext durch einen ansonsten legitimen Arbeitsablauf weitergeben.

Kaskadenversagen ist das daraus entstehende Risiko auf Systemebene. Eine falsche Aktion kann nachgelagerte Agenten, Automatisierungen und externe Dienste auslösen. Der endgültige Schaden kann weit entfernt vom ursprünglichen bösartigen Dokument sichtbar werden.

Dieses Bedrohungsmodell setzt Entwickler, Identitätsteams, Sicherheitsbetrieb und Geschäftsverantwortliche zugleich unter Druck. Kein einzelner Prompt-Filter kann Least Privilege zuweisen, Speicher isolieren, Tools verifizieren und einen Ausfall mehrerer Agenten eindämmen.

Die OWASP LLM Top 10 2026 dienen daher als Einstiegspunkt, nicht als vollständiges Betriebsmodell. Teams müssen Modelltests mit Anwendungssicherheit, Zugriffsmanagement, Lieferkettenprüfung und Incident Response verbinden.

Autonomie und Eindämmung sind jetzt die zentralen Gegenspieler

Der zentrale Sicherheitskonflikt lautet nicht länger Intelligenz versus Genauigkeit, sondern nützliche Autonomie versus durchsetzbare Eindämmung.

Ein Assistent, der vor jedem Schritt um Genehmigung bittet, bietet nur begrenzte Automatisierung. Ein Agent, der nie fragt, kann mehr Arbeit erledigen, aber auch einen fehlerhaften oder bösartigen Plan schneller ausführen.

Daraus entsteht eine unbequeme Produktentscheidung. Teams müssen festlegen, welche Aktionen automatisch ausgeführt werden dürfen und welche einen menschlichen Kontrollpunkt erfordern. Die Antwort hängt von Reversibilität, Datensensibilität, finanziellen Auswirkungen und der Zuversicht des Agenten ab.

Least Privilege bietet einen Ausgangspunkt. Ein Agent sollte nur die Fähigkeiten erhalten, die für seine aktuelle Aufgabe erforderlich sind. Berechtigungen sollten mit Abschluss der Aufgabe ablaufen, statt an einer langlebigen Sitzung hängen zu bleiben.

Least Agency überträgt dieselbe Überlegung auf Entscheidungen. Ein System sollte kein mehrstufiges Ziel delegieren, wenn eine eingeschränkte Operation das gewünschte Ergebnis erzielen würde. Engere Befugnisse erleichtern die Eindämmung unerwarteten Verhaltens.

Im Kundensupport wird dieser Unterschied deutlich. Ein Agent kann anhand der Kontohistorie und von Richtliniendokumenten eine Erstattungsempfehlung formulieren. Ihm zu erlauben, die Erstattung auszuführen, fügt Zahlungsbefugnisse hinzu und führt eine andere Risikoklasse ein.

Auch Softwareentwicklungsagenten zeigen dasselbe Muster. Das Lesen eines Repository unterstützt die Codeanalyse. Das Schreiben in einen Branch erhöht das Integritätsrisiko, während ein Deployment in die Produktion direkte operative Auswirkungen hat.

Ein sicheres Design kann diese Fähigkeiten trennen. Der Agent könnte standardmäßig Lesezugriff erhalten, nach Genehmigung zeitlich begrenzten Branch-Zugriff und keinerlei Produktionszugangsdaten. Eine unabhängige Deployment-Kontrolle kann die endgültige Änderung überprüfen.

Die Risikorahmenwerke für 2026 stellen zudem die Annahme infrage, dass Model Alignment eine ausreichende Verteidigung darstellt. Alignment versucht, das Verhalten eines Modells zu beeinflussen, doch Zugriffskontrollen müssen begrenzen, was die umgebende Anwendung zulässt.

Ein Modell kann viele schädliche Anweisungen ablehnen und dennoch an einer unbekannten Injection scheitern. Containment geht davon aus, dass einige Modellentscheidungen falsch sein werden. Es begrenzt die Folgen, wenn diese Annahme zutrifft.

Akamais Position spiegelt diese architektonische Sicht wider. Die Analyse des Unternehmens zu OpenClaw vom Februar argumentiert, dass die Sicherheit autonomer Agenten auf herkömmlichen Netzwerk-, Betriebssystem- und Anwendungskontrollen beruht.

Das Unternehmen nennt exponierte Dienste, unzureichende Authentifizierung, Befehlsausführung und die Speicherung von Zugangsdaten als grundlegende Schwachstellen. Ein Agent, der auf diesen Schwachstellen aufsetzt, wird zum privilegierten Proxy für einen Angreifer.

Diese Schlussfolgerung verhindert, dass agentische Sicherheit zur Ausrede wird, vertraute Engineering-Arbeit zu vernachlässigen. Eine Eingabeprüfung kann einen exponierten Verwaltungsdienst nicht ausgleichen. Ein Policy-Prompt kann Zugangsdaten nicht schützen, die ohne angemessene Kontrollen gespeichert sind.

Auch die Sicherheit der Lieferkette gewinnt an Bedeutung, wenn Agenten Skills von Drittanbietern installieren oder aufrufen. Ein Skill kann natürlichsprachliche Anweisungen, ausführbaren Code, Remote-Dienste und Zugriffsanfragen in einem Paket vereinen.

Die herkömmliche Überprüfung von Abhängigkeiten untersucht Herkunft, Versionen, Schwachstellen und Maintainer. Agentische Systeme müssen zudem deklarierte Fähigkeiten, Prompt-Verhalten, Tool-Zugriff und die an das Modell zurückgegebenen Informationen prüfen.

Sandboxing hilft dabei, nicht vertrauenswürdige Ausführung zu isolieren. Eine Sandbox muss jedoch Dateien, Netzwerke, Zugangsdaten und Persistenz einschränken, um wirksames Containment zu bieten. Ein nur nominell isolierter Prozess mit weitreichenden Tokens kann weiterhin sensible Dienste erreichen.

Beobachtbarkeit ist die andere Hälfte von Containment. Teams benötigen Aufzeichnungen über Nutzerabsicht, Modellentscheidungen, Tool-Argumente, Berechtigungsfreigaben, abgerufene Quellen, Speicheränderungen und nachgelagerte Antworten.

Diese Aufzeichnungen ermöglichen es Verteidigern nachzuvollziehen, warum ein Agent gehandelt hat. Sie unterstützen außerdem die automatisierte Erkennung, wenn Verhalten vom genehmigten Umfang einer Aufgabe abweicht.

Jeden Modellgedanken zu protokollieren, ist weder zuverlässig noch immer angemessen. Interne Schlussfolgerungen können unvollständig, sensibel oder nicht verfügbar sein. Sicherheitsnachweise sollten sich stattdessen auf beobachtbare Entscheidungen, Eingaben, Berechtigungen und Auswirkungen konzentrieren.

Der Zielkonflikt bleibt schwierig, weil strenge Kontrollen die Nützlichkeit eines Agenten verringern können. Häufige Freigabeanfragen führen zu Ermüdung. Eng gefasste Tools erfordern mehr Engineering, während Isolation komplexe Workflows verlangsamen kann.

Das Entfernen von Kontrollen löst dieses Produktproblem jedoch nicht. Es verlagert die Komplexität in die Incident Response und erschwert die Umkehr von Fehlern. Reifes Agentendesign muss Sicherheitsgrenzen als Teil der Funktionalität behandeln.

Leser von Google News könnten das OWASP-Update als Liste neu auftretender Bedrohungen wahrnehmen. Unternehmenskäufer sollten es als Beschaffungstest lesen. Anbieter müssen erklären, wie ihre Systeme Befugnisse begrenzen, nicht nur, wie gut ihre Modelle Anweisungen befolgen.

Entwickler sollten fragen, welche Komponenten eine Aktion stoppen können, nachdem das Modell sie ausgewählt hat. Lautet die Antwort lediglich „ein weiterer Prompt“, bleibt Containment von derselben probabilistischen Schicht abhängig, die das Risiko erzeugt hat.

Akamais Sicherheitsrahmen zeigt sowohl die Chance als auch die Lücke

Akamai übersetzt OWASPs Risikosprache in Infrastrukturkontrollen, doch seine Produktversprechen erfordern weiterhin unabhängige operative Nachweise.

Akamai kündigte am 15. Juni 2026 einen einheitlichen Sicherheitsrahmen für agentische Systeme an. Das Unternehmen erklärt, er kombiniere Identität, Beobachtbarkeit, Vertrauen und Edge-Sicherheit in einer Echtzeit-Entscheidungsebene.

Sein Agent Security Framework umfasst sechs integrierte Säulen. Sie decken Identität, Berechtigungsvergabe, Durchsetzung, Inhaltszugriff, Traffic-Analyse und kommerzielle Interaktionen ab.

Ein Element ist Know Your Agent, kurz KYA, eine vorgeschlagene Methode zur Deklaration von Identität, Herkunft und Absicht eines Agenten. Akamai erklärt, der Ansatz verknüpfe Agenten mit ihren Plattformen und den von ihnen vertretenen Nutzern.

Das Identitätsproblem ist real. Websites können herkömmliche Browser häufig von bekannten Bots unterscheiden, doch autonome Agenten erschweren die Zuordnung. An einer Anfrage können ein Modellanbieter, eine Agentenplattform, ein Nutzer und mehrere delegierte Dienste beteiligt sein.

Einen Agenten zu erkennen, macht seine Aktion nicht automatisch vertrauenswürdig. Sicherheitsentscheidungen erfordern auch die Befugnis des Nutzers, die angeforderte Operation, den aktuellen Kontext und alle Grenzen der Delegation.

Ein verifizierter Agent kann dennoch kompromittiert werden. Ein legitimer Nutzer kann eine verbotene Aktion anfordern. Eine vertrauenswürdige Plattform kann beschädigten Kontext aus einer externen Quelle weiterreichen.

Identität sollte daher Autorisierung informieren, statt sie zu ersetzen. Jede sensible Anfrage benötigt weiterhin eine Richtlinienentscheidung auf Basis von Umfang, Risiko und aktuellen Nachweisen.

Akamai schlägt zudem eine Durchsetzung am Edge vor, die Agentenverkehr bewertet, bevor er eine Anwendung erreicht. Diese Position kann umfassende Sichtbarkeit über Webanfragen hinweg bieten und die Belastung einzelner Dienste verringern.

Edge-Kontrollen können Automatisierungsmuster identifizieren, Ratenbegrenzungen durchsetzen und bekannte schädliche Eingaben blockieren. Sie können außerdem einheitliche Regeln über Anwendungen hinweg anwenden, die ansonsten unterschiedliche KI-Frameworks nutzen.

Eine Inspektion auf Netzwerkebene kann jedoch nicht jede Entscheidung innerhalb eines Agenten sehen. Sie könnte einen API-Aufruf beobachten, ohne zu wissen, welcher Speichereintrag, welches abgerufene Dokument oder welcher interne Plan ihn ausgelöst hat.

Telemetrie auf Anwendungsebene bleibt notwendig. Entwickler müssen den Aufgabenbereich des Agenten, die Tool-Auswahl, den Autorisierungsstatus und relevante Herkunftsinformationen erfassen. Weder das Edge noch die Anwendung bieten allein vollständige Abdeckung.

Akamais kommerzielle Position schafft einen weiteren Aspekt. Das Unternehmen profitiert, wenn Unternehmen agentischen Traffic als neue Infrastrukturkategorie behandeln, die spezialisierte Kontrollen erfordert.

Das entkräftet seine Analyse nicht. Es bedeutet, dass Leser verifizierte Risikobeschreibungen von Aussagen über die Fähigkeit eines einzelnen Anbieters, diese Risiken zu adressieren, trennen sollten.

Dieselbe Vorsicht gilt im gesamten Sicherheitsmarkt. Eine Firewall kann häufige Injections erkennen, ohne einen Agenten einzudämmen, der bereits über übermäßige Berechtigungen verfügt. Ein Identitätsprodukt kann Agenten authentifizieren, ohne ihr aktuelles Verhalten zu verifizieren.

Eine Monitoring-Plattform kann einen Vorfall aufzeichnen, ohne ihn zu stoppen. Ein Red-Team-Produkt kann bekannte Angriffsmuster finden und zugleich Fehler übersehen, die für den Workflow eines Unternehmens einzigartig sind.

OWASPs Secure Agent Guide betont praktische Leitlinien für Design, Entwicklung und Bereitstellung. Seine Existenz zeigt, warum keine einzelne Sicherheitsebene die Aufgabe vollständig erfüllt.

Organisationen benötigen überlappende Kontrollen in Architektur, Identität, Daten, Tools, Laufzeitüberwachung und Incident Response. Die Kontrollen müssen zudem gemeinsam getestet werden, statt sie als unabhängige Produktfunktionen zu bewerten.

Die skeptische Frage lautet, ob aktuelle Produkte für Agentensicherheit den Kontext über diese Kette hinweg aufrechterhalten können. Eine am Netzwerk-Edge getroffene Entscheidung benötigt Informationen aus Identitätssystemen und dem Aufgabenstatus der Anwendung.

Fehlalarme stellen eine weitere Herausforderung dar. Legitime Anweisungen zu blockieren, kann einen Agenten unzuverlässig machen, während das Zulassen mehrdeutiger Eingaben gefährliche Pfade öffnen kann. Anbieter benötigen messbare Nachweise dafür, wie sie diese Ergebnisse ausbalancieren.

Veröffentlichte Erkennungsraten hängen oft von kuratierten Testsets ab. Produktionsumgebungen enthalten längere Gespräche, proprietäre Dokumente, ungewöhnliche Tools und sich weiterentwickelnde Angriffe. Ergebnisse aus engen Benchmarks lassen sich möglicherweise nicht übertragen.

Unternehmen sollten Testmethoden, Abdeckungsgrenzen, Daten zu Fehlalarmen und Verfahren zur Fehlerbehandlung anfordern. Sie sollten zudem prüfen, ob eine Kontrolle eine Aktion blockiert oder lediglich anschließend eine Warnung erzeugt.

Akamais Rahmenwerk lässt sich am besten als Beleg dafür verstehen, dass sich der Markt in Richtung agentenbewusster Infrastruktur bewegt. Es ist kein Nachweis dafür, dass das zugrunde liegende Sicherheitsproblem gelöst wurde.

Die OWASP LLM Top 10 2026 liefern ein gemeinsames Vokabular zur Bewertung dieses Markts. Ihr größter Wert könnte darin liegen, Käufern zu helfen, konkrete Fragen zu stellen, statt weitreichende Versprechen über „sichere KI“ zu akzeptieren.

Worauf Sicherheitsteams nach dem OWASP-Update achten sollten

Der nächste Test besteht darin, ob Organisationen die neue Taxonomie in messbare Kontrollen umsetzen, bevor autonome Bereitstellungen weiter wachsen.

Das erste Signal sind Nachweise dafür, dass Anbieter Agentenidentität von Nutzeridentität trennen. Ein Agent, der für eine Person handelt, sollte nicht jede Berechtigung erben, die in deren interaktiver Sitzung verfügbar ist.

Sicherheitsteams sollten auf begrenzte Zugangsdaten, kurze Ablaufzeiten, explizite Delegationsaufzeichnungen und aufgabenbezogene Autorisierung achten. Diese Merkmale würden die Annahme stärken, dass Agentenidentität operativ wird.

Ein Label zur Kennzeichnung einer automatisierten Anfrage reicht nicht aus. Das System muss zeigen, wer den Agenten autorisiert hat, was er tun darf und wann diese Befugnis endet.

Das zweite Signal sind umfassendere Tests indirekter Prompt-Injection und Speichervergiftung. Diese Angriffe gelangen über Inhalte hinein, die Nutzer möglicherweise als gewöhnliche Geschäftsdaten betrachten.

Nützliche Evaluierungen sollten E-Mails, Dokumente, Websites, Tool-Antworten, abgerufene Datensätze und persistenten Speicher einbeziehen. Tests müssen messen, ob schädliche Inhalte ein handlungsfähiges Tool erreichen.

Die Containment-Rate ist wichtiger als eine bloße Erkennungszahl. Eine Kontrolle bietet Wert, wenn sie verhindert, dass feindlicher Kontext eine nicht autorisierte Wirkung erzeugt, selbst wenn das Modell der Anweisung zunächst folgt.

Teams sollten Angriffe außerdem über längere Zeiträume hinweg testen. Ein vergifteter Speichereintrag kann inaktiv bleiben, bevor er eine spätere Aufgabe beeinflusst. Eine kurze Evaluierung kann diese Persistenz übersehen.

Das dritte Signal sind reale Vorfallberichte zu Multi-Agent-Workflows. Das OWASP-Framework benennt unsichere Kommunikation, kaskadierende Fehler und abtrünnige Agenten, doch öffentliche operative Nachweise bleiben begrenzt.

Klare Offenlegungen würden zeigen, welche Grenzen zuerst versagten und welche Kontrollen den Schaden eindämmten. Sie würden außerdem helfen, theoretische Kategorien von wiederkehrenden Produktionsschwächen zu unterscheiden.

Das Fehlen öffentlicher Berichte sollte nicht als Fehlen von Vorfällen interpretiert werden. Organisationen erkennen agentische Fehler möglicherweise nicht, oder sie klassifizieren sie unter herkömmlichen Anwendungs- und Identitätskategorien.

Die Qualität künftiger Offenlegungen wird Sicherheitsinvestitionen prägen. Wenn die meisten Fehler mit übermäßigen Berechtigungen beginnen, verdienen Identitäts- und Tool-Kontrollen Priorität. Wenn vergiftete Retrieval-Daten dominieren, werden Herkunftsnachweise und Inhaltsisolation dringlicher.

Regulierungs- und Standardisierungsarbeit wird die Umsetzung ebenfalls beeinflussen. Die Zuordnung von OWASP-Risiken zu NIST, MITRE ATLAS, CWE und anderen Frameworks kann Teams helfen, KI-Kontrollen in bestehende Governance-Prozesse zu integrieren.

Doch Zuordnung allein belegt keine Wirksamkeit. Auditoren benötigen Nachweise, dass eine Kontrolle unter realistischen Bedingungen funktioniert. Entwickler benötigen wiederholbare Tests, die bei Änderungen an Modellen, Prompts, Tools oder Berechtigungen ausgeführt werden können.

Die Aufmerksamkeit von Google News für Akamais Analyse kann dazu beitragen, das Thema über spezialisierte Sicherheitsteams hinauszutragen. Produktverantwortliche und Unternehmenskäufer beeinflussen nun, wie viel Befugnis Agenten erhalten.

Ihre Entscheidungen bestimmen, ob Sicherheit zu einer architektonischen Anforderung oder zu einer Prüfung nach der Bereitstellung wird. Letzterer Ansatz wird zunehmend kostspielig, da Agenten persistenten Speicher und umfassendere Integrationen erhalten.

Eine praktische Überprüfung sollte bei Aktionen beginnen, nicht bei Modellnamen. Teams sollten inventarisieren, welche Agenten sensible Daten lesen, Datensätze ändern, Code ausführen, Nachrichten senden oder Transaktionen initiieren können.

Jede Aktion benötigt einen Verantwortlichen, eine Berechtigungsgrenze, eine Freigaberichtlinie und einen Wiederherstellungspfad. Vorgänge mit hoher Auswirkung sollten zudem manipulationsresistente Aufzeichnungen erzeugen, die Untersuchungen unterstützen.

Organisationen sollten davon ausgehen, dass Prompt-Injection nicht verschwinden wird. Das vertretbare Ziel besteht darin, zu verhindern, dass eine erfolgreiche Manipulation zu einer uneingeschränkten Aktion wird.

Das bedeutet, Anweisungen von abgerufenen Informationen zu trennen, Tools zu beschränken, die Ausführung zu isolieren und Ausgaben zu validieren, bevor nachgelagerte Systeme sie übernehmen. Persistenter Speicher erfordert Herkunftsnachweise, Schreibkontrollen und Überprüfungsmechanismen.

Menschliche Aufsicht muss sich auf bedeutsame Entscheidungen konzentrieren. Nutzer um die Freigabe jedes noch so kleinen Schritts zu bitten, fördert automatische Bestätigungen. Kontrollpunkte sollten vor irreversiblen, sensiblen oder unerwartet weitreichenden Aktionen erscheinen.

Auch Incident-Response-Pläne benötigen agentenspezifische Verfahren. Teams müssen delegierte Zugangsdaten widerrufen, Tools deaktivieren, Speicher unter Quarantäne stellen und betroffene nachgelagerte Systeme nachverfolgen können.

Das OWASP-Update etabliert keinen endgültigen Sicherheitsstandard. Es liefert ein gemeinsames Modell, um Lücken zu erkennen, während sich Agentenarchitekturen weiter verändern.

Akamais Beitrag besteht darin, dieses Modell mit Netzwerkdurchsetzung, Identität und operativer Transparenz zu verbinden. Wettbewerber werden unterschiedliche Kombinationen anbieten, wodurch Käufer testbare Ergebnisse einfordern können.

Für Entwickler ist die unmittelbare Frage einfach: Was geschieht, nachdem das Modell die falsche Entscheidung getroffen hat? Ein sicheres System muss darauf mit einer technischen Grenze antworten, nicht mit einem Versprechen über das Modellverhalten.

Für Unternehmenskäufer besteht der nächste Schritt darin, einen folgenreichen Workflow vom Input bis zur Ausführung zu testen. Verfolgen Sie die abgerufenen Inhalte, Berechtigungen, Tools, Speicheränderungen und die endgültige Wirkung.

Für Wissensarbeiter ist das Update eine Erinnerung daran, dass ein mit privater Arbeit verbundener Assistent ein anderes Risikoprofil hat als ein isolierter Chatbot. Mit zunehmenden Verbindungen steigt der Komfort, aber auch die Angriffsfläche.

Achten Sie darauf, ob kommende Produkte Agentenberechtigungen standardmäßig stärker einschränken, realistische Injection-Tests veröffentlichen und eine schnelle Eindämmung unterstützen. Diese Signale werden zeigen, ob das OWASP-Framework eingesetzte Systeme verändert.

Sichtbarkeit in Google News kann die Warnung verstärken, doch die Umsetzung wird über ihren Wert entscheiden. Bevor Sie einem weiteren Agenten Zugriff gewähren, identifizieren Sie die Grenze, die verhindert, dass eine manipulierte Anweisung zu einem dauerhaften operativen Ausfall wird.