Was die OWASP Top 10 für Agentic Applications für KI-SRE-Agenten bedeutet

Das meiste, was ein KI-SRE-Agent tut, ist lesen. Er zieht Metriken, durchsucht Logs und reiht Events aneinander, bis er eine brauchbare Hypothese hat, was gerade schiefläuft. Für viele Teams würde sich das allein schon rechnen. Interessant wird es, sobald man den Loop schließt und ihn auf seine Ergebnisse reagieren lässt: einen Workload neu starten, Traffic umleiten, ein Deployment hochskalieren. Diese Aktionen treffen Produktion in dem Moment, in dem der Agent sich für sie entscheidet. Oft bevor irgendwer das Reasoning dahinter gelesen hat. Und genau das erhöht den Einsatz für alles, was danach kommt.

Im Dezember 2025 hat das OWASP GenAI Security Project die OWASP Top 10 für Agentic Applications veröffentlicht, die Risiken ASI01 bis ASI10. Das ist eine eigene Liste, getrennt von den älteren OWASP LLM Top 10, über die wir schon geschrieben haben. Aus gutem Grund: Ein Agent ist weit mehr als ein Chat-Modell mit längerem Prompt. Er plant ein Vorgehen, hält Credentials, nimmt Memory von einer Session in die nächste mit und arbeitet neben anderen Agenten. Mehrere der Einträge, die von Agenten handeln, die mit Agenten reden, würden für ein Modell, das nur Fragen beantworten kann, gar keinen Sinn ergeben.

Trotzdem überschneiden sich die beiden Listen stark. Eine agentic Anwendung erbt die kompletten LLM Top 10, von Prompt Injection bis Sensitive Information Disclosure. Die agentic Risiken kommen obendrauf, sie ersetzen die alten nicht. Und ein paar Einträge sind schlicht ein LLM-Risiko, das hier in neuer Form wieder auftaucht. Prompt Injection etwa wird zu Goal Hijack, sobald das Modell ein Tool in der Hand hält, mit dem es handeln kann. Und das sind keine Nischen-Systeme. Ein SRE-Agent ist genau die Art maßgeschneiderte KI-Anwendung, direkt an Produktion verdrahtet, die Gartner im Blick hat: Bis 2028 sollen Incidents mit KI-Anwendungen die Hälfte des Aufwands für Cybersecurity-Incident-Response ausmachen.

Jedes der zehn Risiken ist der Preis für eine Fähigkeit, die ein Chatbot nie hatte. Deshalb haben wir sie nach genau dieser Fähigkeit gruppiert: was passiert, wenn der Agent handeln kann, wenn er eine Identität trägt, wenn er sich erinnert, wenn er als Teil einer Flotte arbeitet und wenn er einen Menschen überzeugen muss.

Kurz gefasst

Jedes Risiko geht auf eine Fähigkeit zurück, die ein Chatbot nie hatte: Der Agent handelt, trägt eine Identität, erinnert sich, stimmt sich mit anderen Agenten ab und muss einen Menschen überzeugen. Gruppiert man die zehn so, ergeben sich die Gegenmaßnahmen fast von allein.

Das wichtigste Prinzip: Least Agency. Ein Agent bekommt nur so viel Fähigkeit, Memory und Autonomie, wie seine Aufgabe braucht. Nicht mehr.

Dem Agenten eine eigene Identität mit begrenztem Scope geben, nie einen geliehenen Admin-Account. Gartner rechnet damit, dass bis 2028 ein Viertel der Enterprise-Breaches auf missbrauchte KI-Agenten zurückgeht, und ein Agent mit zu vielen Rechten ist der schnellste Weg dahin.

Ein Mensch, der mit Anfragen geflutet wird, ist keine Safety-Net mehr. Approvals für die Aktionen reservieren, die wirklich eine brauchen, alles loggen und einen Killswitch bereithalten, der mit einer Aktion greift.

Wenn der Agent handeln kann

Das Erste, was ein Agent kann und ein Modell nicht, ist, in der Welt zu handeln. Man gibt ihm ein Tool und ein Ziel, und er nutzt das Tool, um das Ziel zu verfolgen. Darin liegt der ganze Wert der Sache, und drei der OWASP-Risiken drehen sich genau darum. Das Ziel kann durch etwas umgeschrieben werden, das der Agent liest. Das Tool kann auf etwas gerichtet werden, das nie vorgesehen war. Und die Aktion kann Code sein, den der Agent sich selbst geschrieben hat.

ASI01 Agent Goal Hijack

Der Agent untersucht einen Latenz-Spike. In den Logs steht eine Zeile, die niemand aus dem Team geschrieben hat: eine "interne Notiz für den Assistenten", laut der der richtige Fix darin besteht, das Payments-Deployment auf null zu skalieren und den Incident zu schließen. Im Chat wäre das eine falsche Antwort, über die man hinwegliest. Mit Zugriff auf ein Scale-Tool ist es eine Anweisung, die ausgeführt wird. Goal Hijack heißt: Eine eingeschleuste Anweisung sitzt am Steuer.

Das Problem dabei: Der Payload kommt über genau die Kanäle rein, für die man den Agenten überhaupt einsetzt. Alerts, Tickets, Commit Messages, Chat-Threads, Log-Zeilen. Überall, wo ein Angreifer reinschreiben kann, kann er auch steuern. Und operative Daten bestehen zu einem guten Teil aus genau solchen Feldern.

Praktisch heißt das: Das Ziel kommt vom System und vom Operator, nie aus Inhalten, die der Agent unterwegs liest. Operative Daten sind per Default untrusted. Und Änderungen mit echtem Impact, etwa ein Deployment auf null skalieren, brauchen eine Freigabe, die das Modell nicht selbst erzeugen kann.

ASI02 Tool Misuse and Exploitation

Der Agent hat ein free_disk_space-Tool bekommen, weil die Nodes nachts ständig vollgelaufen sind. Eines Nachts sieht er einen Disk-Pressure-Alert, kommt zu dem Schluss, dass sich am schnellsten Platz schaffen lässt, indem er das Persistent Volume hinter einem StatefulSet löscht, und ruft das freigegebene Tool mit einem Argument auf, an das vorher niemand gedacht hat. Kompromittiert wurde dabei nichts. Das Tool hat genau das gemacht, wofür es gebaut wurde. Der Agent hat eine völlig legitime Fähigkeit genutzt, um Daten zu zerstören.

Mehr steckt hinter Tool Misuse nicht. Das Risiko liegt in der Lücke zwischen "der Agent darf dieses Tool aufrufen" und "der Agent darf dieses Tool aufrufen, mit diesen Argumenten, gegen diese Ziele, so und so oft". Wer das Verb freigibt, gibt nicht automatisch den Blast Radius frei. Die Differenz füllt das Modell mit dem, was es sich selbst zusammenreimt.

Deshalb: Tools nicht nur auf Verb-Ebene scopen, sondern auch auf Argument-Ebene.

Per Allowlist festlegen, welche Namespaces und Ressourcen-Typen ein Tool anfassen darf. Alles andere lehnt das Interface ab.
Irreversible Calls als eigene Risikoklasse behandeln, nicht wie einen Read. Erst Dry-Run, oder eine Bestätigung verlangen, die der Agent nicht selbst liefern kann.
Argumente vor der Ausführung validieren. Ein Delete mit Wildcard-Target ist nicht dieselbe Anfrage wie ein Delete auf ein einzelnes benanntes Objekt.

ASI05 Unexpected Code Execution

Ein Agent, der einen kubectl-Patch oder ein Remediation-Skript entwirft, spart echte Zeit. Aber sobald er das Skript selbst ausführt, ungereviewt, hat man sich absichtlich eine primitive Remote Code Execution gebaut. Das Modell muss nur ein einziges Mal danebenliegen, in einem einzigen generierten Befehl, und es hat die Rechte, den Befehl auch auszuführen.

Also: Alles, was der Agent generiert, ist untrusted Output. Es gibt keine Variante von "das Modell hat es geschrieben, wird schon passen", die den Kontakt mit Produktion überlebt. Nichts davon läuft ungeprüft auf Live-Systemen. Entweder es läuft in einer Sandbox, oder es landet als vorgeschlagene Änderung, die ein Mensch oder eine strengere Policy abnickt, bevor irgendwas den Cluster erreicht. Die Grenze zwischen "der Agent hat das entworfen" und "das ist gelaufen" ist ein Checkpoint. Den sollte man absichern.

Wenn der Agent eine Identität trägt

Um zu handeln, braucht der Agent Berechtigungen, und Berechtigungen hängen an einer Identität. Diese Identität wird schnell zu einem der mächtigsten nicht-menschlichen Accounts in der ganzen Umgebung. Und anders als ein Service, der eine feste Aufgabe abarbeitet, überlegt sich dieser Account tatsächlich, was er als Nächstes tut. Daran hängen zwei Risiken: die Rechte, die die Identität hält, und die Komponenten, die sie sich nachlädt, um diese Rechte zu nutzen.

ASI03 Identity and Privilege Abuse

Der schnellste Weg, einen SRE-Agenten live zu bringen: ein Service Account, der alles darf. Man weiß ja noch nicht, welche Rechte er am Ende braucht. Genau diese Bequemlichkeit ist der Kern der Schwachstelle. Maschinen-Identitäten kommen laut CyberArks Landscape-Report 2025 schon jetzt auf mehr als achtzig pro menschlicher Identität, und der Agent ist eine weitere. Nur dass diese eine Identität Schlüsse zieht, Aktionen verkettet und sich von den Daten, die sie liest, dazu bringen lässt, ihre Rechte auszuspielen.

Die Zahlen zeigen, dass die meisten Teams da noch nicht angekommen sind. Laut IBMs Cost-of-a-Data-Breach-Report 2025 hatten 13 % der Organisationen einen Breach eines KI-Modells oder einer KI-Anwendung, und 97 % davon hatten keine vernünftigen Zugriffskontrollen für ihre KI-Systeme. Gartner rechnet damit, dass bis 2028 ein Viertel der Enterprise-Breaches auf missbrauchte KI-Agenten zurückgeht.

Der Fix: eine eigene Identität, nie eine geliehene Admin-Identität. Rechte auf die Aufgabe zuschneiden und kurzlebig halten, damit ein Token, das für den Neustart eines Deployments ausgestellt wurde, nicht nebenbei auch einen Node drainen kann. Und jede Aktion zur Laufzeit gegen die Policy autorisieren. Genau so, wie man es bei einem menschlichen Operator mit so viel Reichweite auch täte.

ASI04 Agentic Supply Chain

Die Fähigkeiten des Agenten stecken nicht alle in seinem Image. Er lädt MCP-Server, zieht Runbooks aus einem Repo, holt sich Tool-Definitionen aus einer Registry. Vieles davon kommt erst zur Laufzeit dazu, aus Quellen, die man nicht vollständig kontrolliert. Ein kompromittierter MCP-Server oder ein vergiftetes Runbook ist ein Supply-Chain-Angriff, der sich als neues Verhalten zeigt, nicht als neuer Code im Build. Und genau das macht ihn im Review so schwer zu fassen. Die Dependency-Fläche besteht nicht mehr aus Modell-Weights und einer Handvoll Packages, sondern aus jedem Connector, der auf dem Cluster handeln kann.

Deshalb: Connectors und Runbooks wie die Dependencies behandeln, die sie sind. Pinnen und signieren, aus einer kuratierten Registry ziehen, nicht mitten im Incident aus dem offenen Internet. Neue Tools erst in einer Sandbox abklopfen, bevor sie an Produktion dürfen. Und danach weiter im Blick behalten, denn ein Connector, der beim Install sauber war, kann drei Monate später ein bösartiges Update ausliefern.

Wenn der Agent sich erinnert

Ein Chatbot vergisst dich zwischen den Sessions. Ein SRE-Agent ist genau fürs Gegenteil gebaut. Der ganze Sinn ist ja, dass er weiß, was letztes Quartal kaputt war, was der Fix war und welchen Postmortems man trauen kann. Dieses Memory ist aber auch ein Ort, an dem ein schlechter Eintrag still liegen bleiben und jede spätere Entscheidung beeinflussen kann.

ASI06 Memory and Context Poisoning

Ein einziges Postmortem, das behauptet, der Fix bei hohem Memory Pressure sei, den OOM Killer abzuschalten, wird zum eigenen Incident, sobald der Agent das um drei Uhr nachts mit voller Überzeugung wiederholt. Was den Agenten über die Zeit besser macht, sein Wissen über vergangene Incidents und deren Fixes, ist genau das, was ein Angreifer oder ein ehrlicher Fehler verfälschen kann. Mit Wirkung auf jede künftige Untersuchung.

Vergiftetes Memory ist schlimmer als eine einmalige Injection, gerade weil es bleibt. Wer es vergiftet, ob Angreifer oder der eigene Engineer, muss nur einmal treffen. Danach verteilt der Agent das selbst weiter, über Sessions und Incidents hinweg.

Deshalb: Zu allem, was der Agent sich merkt, die Provenance mitführen. Wer hat es geschrieben, wann, aus welchem Incident. Memory segmentieren, damit ein Tenant oder eine schlechte Quelle nicht den Rest überschreiben kann. Einträge ablaufen lassen, und alles, was komisch aussieht, in Quarantäne. Ein Memory, auf dessen Basis der Agent handelt, sollte mindestens so nachvollziehbar sein wie ein Runbook, das man einem neuen On-Call Engineer in die Hand drückt.

Wenn Agenten als Team arbeiten

Die leistungsfähige Variante von operativer KI ist selten ein einzelner Agent. Es ist ein Overview-Agent, ein Investigator, ein Remediation-Agent, manchmal eine ganze Pipeline davon, die sich Arbeit weiterreicht. Diese Struktur macht das System deutlich besser. Sie bringt aber auch drei Fehlermodi mit, die ein einzelnes Modell nie hat: Der Kanal zwischen den Agenten kann manipuliert werden. Der Fehler eines Agenten kann zum Fehler der ganzen Flotte werden. Und ein Agent kann entgleisen, während jeder einzelne Schritt weiter nach Routine aussieht.

ASI07 Insecure Inter-Agent Communication

Ein Analyse-Agent grenzt das Problem ein, ein Investigator sammelt Belege, ein Remediation-Agent handelt, und die Findings wandern zwischen ihnen hin und her. Läuft dieser Hand-off über einen unauthentifizierten Kanal, kann alles, was dort eine Nachricht einschleusen kann, dem Remediation-Agenten Anweisungen unterschieben, die der Analyse-Agent nie geschickt hat. Das Vertrauen in die eigene Pipeline wird zum Einfallstor.

Agent-zu-Agent-Traffic gehört authentifiziert und verschlüsselt, wie jeder andere Service-zu-Service-Call auch. Mutual TLS, signierte Payloads, Replay-Schutz. Eine Anweisung ist nur so vertrauenswürdig wie die Identität, die sie signiert hat. Wenn man nicht sagen kann, welcher Agent etwas gesagt hat, gibt es keinen sicheren Weg, darauf zu reagieren. Und "die Nachricht kam über den internen Kanal" ist keine Identität.

ASI08 Cascading Failures

Ein einziges falsch gelesenes Signal, verstärkt durch die Architektur drumherum. Der erste Agent stuft eine Region als ungesund ein und leitet Traffic weg. Der zweite sieht die verschobene Last und skaliert die jetzt leere Region runter. Der dritte liest den daraus entstehenden Error-Spike als neuen Incident und reagiert. Jeder Schritt ist für sich genommen vernünftig. Zusammen sind sie ein Ausfall, den die Agenten selbst verursacht haben und jetzt voller Überzeugung aufräumen. Die Vernetzung, die eine Flotte stark macht, ist dieselbe Eigenschaft, die einen Fehler zu vielen werden lässt.

Die Grenzen für den Blast Radius gehören nicht in den Agenten selbst, denn der Agent ist ja genau das, dessen Urteil gerade in Frage steht. Aktionen rate-limiten, Circuit Breaker auf Remediation setzen, deckeln, wie viel eine einzelne Untersuchung ändern darf, bevor ein Mensch dazukommt. Mehrstufige Pläne testen, bevor sie auf Produktion laufen. Und sicherstellen, dass zwei Agenten eine Aktion nicht endlos hin- und herspielen können, ohne dass ein Limit den Loop stoppt.

ASI10 Rogue Agents

Der schwierigste Fall ist der Agent, der auf den ersten Blick in Ordnung aussieht, aber über einen der Wege oben kompromittiert wurde. Oder der schlicht nicht mehr zu dem Ziel passt, das man ihm gegeben hat. Er arbeitet einfach weiter: wiederholt Aktionen, hält sich über Sessions hinweg, gibt sich gelegentlich als anderer Agent aus, und jeder einzelne Schritt sieht dabei nach normalem Betrieb aus. Das Problem in Produktion: "sieht nach normalem Betrieb aus" ist genau das, worauf man sich allein nicht verlassen kann.

Den Agenten also überwachen wie jeden anderen privilegierten Akteur in der Umgebung. Behavioural Monitoring auf das, was er tut, nicht nur auf das, was er sagt. Governance darüber, welche Agenten existieren und was jeder von ihnen dürfen soll. Und immer einen Killswitch einbauen: eine Aktion, die dem Agenten Identität und Tools sofort entzieht.

Wenn der Agent dich überzeugt

Das letzte Problem ist das subtilste, weil es auf einen selbst zurückzeigt. Ein Agent handelt nicht nur auf Systemen, er berichtet auch an die Menschen, die ihn beaufsichtigen. Und ein ruhiger, flüssig formulierter Bericht ist selbst eine Angriffsfläche. Wenn der Agent einen dazu bringen kann, die falsche Aktion freizugeben, ist jede Absicherung hinter dieser Freigabe schon umgangen.

ASI09 Human-Agent Trust Exploitation

Das ist der Fehler, den wir in Claude Code Is Not an SRE Agent beschrieben haben. Das Modell liest die Symptome schnell, schreibt eine saubere Story und landet bei einer Root Cause, die plausibel ist. Und falsch. Schlimmer noch: Ein flüssiger, selbstsicherer Agent führt einen nicht nur in die Irre. Er holt sich auch die Freigabe für seine Aktion.

Und wenn er vierzig Mal pro Stunde danach fragt, hört der On-Call Engineer auf zu lesen und fängt an zu klicken. OWASP hat für diesen zweiten Fehler einen Namen: den Menschen im Loop überfluten. Ein Reviewer, der nur noch abnickt, ist keine Absicherung mehr.

Eines also im Kopf behalten: Selbstsicherheit ist kein Beleg. Der Agent soll seine Arbeit zeigen, nicht nur sein Fazit. Welche Signale er genutzt hat, welche Query er ausgeführt hat, wo er unsicher ist. Menschliche Freigaben für die Aktionen reservieren, die wirklich eine brauchen, damit die verbleibenden noch Gewicht haben. Den Operator nicht in Bestätigungen ertränken. Und ein unveränderliches Log führen: was freigegeben wurde, von wem und warum.

So gehen wir das bei Hyground an

Der rote Faden durch alle zehn Punkte ist Reichweite: wie viel der Agent anfassen, sich merken und anstoßen kann, bevor jemand draufschaut. Unsere Antwort ist, diese Reichweite per Default schmal zu halten und an die Umgebung zu koppeln, in der der Agent läuft. Hyground sitzt im Cluster des Kunden und arbeitet mit einer Identität, die auf die Aufgabe gescopet ist. Was er erreichen kann, gibt also die Umgebung vor, nicht das Vertrauen, das irgendwer dem Modell entgegenbringt. Lesen darf er breit, denn so untersucht er. Alles, was Produktion mit echtem Blast Radius verändert, wartet auf einen Menschen.

Das Ziel: jedem im On-Call die Tiefe eines Senior SRE geben und die Entscheidungen mit echtem Risiko bei einer Person lassen, die dafür geradestehen kann.

Schlussgedanke

Jedes dieser Risiken ist der Preis für eine Fähigkeit, die man haben wollte: Handeln, eine Identität, Memory, eine Flotte, einen Bericht, dem ein Mensch trauen kann. Das Risiko senkt man nicht, indem man die Fähigkeit wieder wegnimmt, denn dann steht man wieder bei einem Chatbot, der Produktion zuschaut und nicht helfen kann. Man senkt es, indem man jede dieser Fähigkeiten auf genau die Aufgabe vor ihr begrenzt. Das meint OWASP mit Least Agency. Diese Begrenzung ist die eigentliche Engineering-Arbeit, und die abnehmen kann einem die Liste nicht. Denn das richtige Limit hängt davon ab, was man den Agenten anfassen lässt, und davon, womit das Team leben kann, wenn er danebenliegt.

Das schwierigere Problem ist, so einen Stand aktuell zu halten. Connectors pinnen, auf vergiftete Updates achten, Identitäten neu zuschneiden und die Autonomie-Grenzen halten, während Modelle, MCP-Server und das ganze Agenten-Ökosystem weiter driften. Diese Arbeit hört nicht auf. Und sie ist der größte Posten, den Teams unterschätzen, wenn sie durchrechnen, so etwas selbst zu bauen. Das ist dieselbe Build-vs-Buy-Frage wie in Hyground vs DIY, und eines der acht Probleme auf dem Weg vom Dev-Agenten zum SRE-Agenten.