Die schwierigsten KI‑Sicherheitsprobleme liegen jetzt außerhalb des Modells

Der 2026 OWASP Top 10 für LLM‑Anwendungen bietet eine kritische Sicht auf die Reife von produktiv eingesetzter KI. Er erfasst einen entscheidenden Wandel: Die Branche bewegt sich über die Sandbox hinaus und ringt mit den Komplexitäten der realen Integration.

Wenn Sie ein LLM an Unternehmenswerkzeuge und -abläufe anbinden, ändert sich die Angriffsfläche grundlegend. Risiken im Zusammenhang mit Autorität und Ressourcennutzung werden deutlich schwerer zu begrenzen. Gleichzeitig rücken Schwachstellen wie unsachgemäße Ausgabe­verarbeitung aus dem Vordergrund, nicht weil sie gelöst sind, sondern weil andere Probleme in den Vordergrund gerückt sind.

Das OWASP Top‑10‑Ranking spiegelt diese Entwicklung wider. „Excessive Agency“ ist von Platz sechs auf Platz drei aufgestiegen, während „Unbounded Consumption“ auf Platz sechs geklettert ist. Im Gegenzug ist „Improper Output Handling“ auf den zehnten Platz gesunken.

Dies mindert das Risiko der Ausgabe­verarbeitung nicht. Wenn eine LLM‑Antwort ohne gründliche Validierung eine Shell oder Datenbank erreicht, bleiben herkömmliche Injektionsfehler bestehen. Das Paradigma hat sich jedoch verschoben. In einem agentenbasierten System ist die Modellantwort nicht das Ziel; sie ist ein Eingabe‑Element, das Autorität trägt. Wenn ein Modell Anmeldeinformationen besitzt oder mit einer API interagiert, wirkt seine Ausgabe als Vektor, der Aktionen über verschiedene Systeme hinweg auslösen kann.

Die Sicherheitsherausforderung besteht nicht mehr nur darin, das Modell zu bewerten; sie liegt darin, die Grenzen dessen zu definieren, was nach der Inferenz geschieht. Ihre Architektur bestimmt, ob eine Halluzination im Text verbleibt oder sich als unautorisierte Datenbank‑mutation manifestiert.

Das Ranking folgt dem Schaden

OWASP nutzte 7,714 Vorfälle, 75 % durch Konsens der Community und 25 % durch empirische Vorfalldaten. Diese Evidenzbasis zwang zu einer echten Neuordnung der Prioritäten.

„Excessive Agency“ stieg, weil die Realität produktiver Umgebungen die Theorie einholte. Unternehmen beschleunigen die Bereitstellung autonomer Fähigkeiten schneller, als sie notwendige Steuerungsebenen etablieren. Die kritische Schwachstelle ist nicht nur die vom Modell gegebene Antwort, sondern der Autorisierungskontext, in dem diese Antwort ausgeführt wird.

Während „Improper Output Handling“ weiterhin ein Problem darstellt, haben DevOps‑Teams ihre Fähigkeit, nachgelagerte Senken durch Schemagültigkeit und parametrisierte Abfragen zu sichern, weiterentwickelt. Dies sind etablierte Praktiken der Anwendungssicherheit.

Agentur ist jedoch eine andere Klasse von Problem. Ein Werkzeugaufruf kann strukturell gültig, aber kontextuell unzulässig sein. Das Modell kann eine genehmigte Funktion für eine ungeeignete Aufgabe aufrufen oder die falsche Ressource anvisieren. Statische Bereinigung kann die Absicht nicht beurteilen. Dies erfordert eine ausgefeilte, kontextbewusste Autorisierung, die das Modell niemals isoliert ausführen sollte.

Betrachten Sie jedes Werkzeug als exponierte Fähigkeit

Viele Teams behandeln Tool‑Definitionen lediglich als Integrations‑Infrastructure. Das ist ein ziemlich lächerlicher und grundlegender Fehler. Jedes Tool, jeder Connector oder API‑Endpunkt erweitert den Einflussbereich der KI‑Anwendung.

Betrachten Sie einen Agenten, der ein Postfach zusammenfassen soll. Wenn die Implementierung einen breiten Connector verwendet, der Schreib‑ oder Löschfunktionen beinhaltet, haben Sie übermäßige Funktionalität eingeführt, bevor die erste Eingabe überhaupt verarbeitet wird.

Sie müssen das Prinzip der minimalen Rechte durchsetzen:

• Schnittstelle einschränken: Dem Agenten nur schreibgeschützte Werkzeuge bereitstellen statt allgemein einsetzbarer Connectoren.
• Eingeschränkter Kontext: Anfragen im OAuth‑abgestuften Identitätskontext des Benutzers ausführen.
• Policy Enforcement Points (PEP): Autorisierungslogik als verpflichtende Middleware zwischen dem Modell und nachgelagerten Systemen implementieren. Jede Aktion muss vor der Ausführung anhand der Richtlinie validiert werden.
• Human-in-the-loop (HITL): Explizite Genehmigung für Vorgänge verlangen, die schwer rückgängig zu machen sind oder hohe materielle Auswirkungen haben.

Dieser Ansatz erfordert eine Verschiebung in der Lieferpipeline. Ihr Prüfungsprozess muss über das Modell hinaus erweitert werden, um Änderungen an Tool‑Schemas, Service‑Identitäten und Berechtigungsskopen zu umfassen. Ein Modell‑Update mag harmlos erscheinen, doch eine Änderung des Autorisierungskontexts eines Connectors kann eine katastrophale Schwachstelle erzeugen.

Transparenz ist unverhandelbar. Sie müssen die konkrete Tool‑Ausführung, die autorisierende Identität und die resultierende Änderung im Zielsystem protokollieren. Diese Kette der Verantwortlichkeit ist für die Vorfallsreaktion essenziell, da sie es ermöglicht, einen aktiven Prozess zu unterbrechen und den Prüfpfad nach dem Vorfall zu rekonstruieren.

Jeder autonome Durchlauf benötigt einen harten Stopp

„Unbounded Consumption“ hat stark zugenommen, weil das Anfragenvolumen eine unzureichende Kennzahl für Ressourcenrisiken darstellt. Eine einzelne, prägnante Eingabe kann eine rekursive, ressourcenintensive Kette von Tool‑Aufrufen auslösen. Das Messgerät stoppt erst, wenn der Agent beendet ist.

Einfache Alarmierung reicht nicht aus, wenn die Ausführungsgeschwindigkeit die menschliche Reaktionszeit übertrifft. Sie benötigen deterministische, harte Grenzen, die außerhalb der Kontrolle des Agenten liegen. Implementieren Sie strenge Obergrenzen für Token‑Verbrauch, Laufzeit, Rekursionstiefe und kumulative Betriebskosten. Überschreitet eine Ausführung diese Parameter, muss das System den Vorgang beenden oder drosseln.

Der operative Umfang erfordert ähnliche Strenge. Bestimmen Sie die maximale Anzahl von Datensätzen, die ein Agent ändern darf, und definieren Sie die Grenzen der Aufgabenverbreitung. Wenn Ihre Architektur keinen deterministischen „Stopp“-Mechanismus besitzt, haben Sie im Wesentlichen Autorität delegiert, ohne deren Umfang festzulegen.

Für die falsche Antwort bauen

Die Systemtechnik hat lange auf resiliente Architektur gesetzt, um von Natur aus unzuverlässige Komponenten zu sichern. Wir rechnen mit Komponenten‑Ausfällen und Netzwerkinstabilität; die Sicherheit leitet sich aus dieser Annahme ab, nicht aus der Illusion von Perfektion. LLMs erfordern dieselbe architektonische Disziplin.

Stützen Sie Ihre Sicherheitsstrategie nicht auf die Annahme einer perfekten Modell‑Ausrichtung. Gehen Sie von Fehlfunktionen aus, sei es durch gutartige Missverständnisse oder böswillige Ausnutzung. Beschränken Sie die Fähigkeiten des Agents auf das absolut notwendige Minimum und halten Sie strenge Benutzer‑Autorisierungskontexte für alle nachgelagerten Aufrufe aufrecht. Entscheidend ist, dass die Durchsetzung von Richtlinien außerhalb des Modells erfolgt, um Prompt‑Injection oder Denkfehler zu verhindern, die Ihre Kontrollen umgehen könnten.

Wir betrachten Prompt‑Injection heute weniger als Schwachstelle, sondern eher als ein physikalisches Gesetz. Sie wird immer im Hintergrund lauern. Tatsache ist, dass die Modelle selbst keine wirksamen Entscheider für sicherheitskritische Fragen sein können. In einem realen agentischen Projekt, das ich aufbaue, führen wir etwa 100 automatisierte „Red‑Team“-Tests durch. Wir stellen sicher, dass wir alle bestehen. Das erreichen wir, indem wir harte Kontrollen außerhalb des Modells implementieren. Wir können das Modell ausschalten und die Bestehens‑/Durchfall‑Raten nur für das Modell selbst beobachten. Das älteste, schwächste Modell, das wir testen, scheitert zu 17 % der Fälle. Das neueste, größte Modell scheitert zu 2 % der Fälle. Großer Fortschritt, oder? Aber reicht 98 % aus, wenn jeder Fehler einen Datenverlust sensibler Informationen bedeutet? Nicht annähernd.

Operationen mit hoher Wirkung müssen beobachtbar, auditierbar und idealerweise reversibel sein. Jede autonome Ausführung erfordert unveränderliche Leitplanken, die außerhalb der Reichweite des Modells bleiben.

Die Rankings 2026 verdeutlichen, wann KI‑Fehler in materielle Konsequenzen übergehen. Das Modell kann den Fehler auslösen, aber die Architektur bestimmt den Explosionsradius. Für produktive KI ist die kritischste Sicherheitsarbeit in der Post‑Inference‑Pipeline zu finden.