A2A Check
ENStarten
Alle Beiträge

10. November 2026

57 % korrekt, 11,8 % sicher: Warum funktionierender Agenten-Code nicht sicherer Code ist

Die Tests sind grün, das Feature läuft. Eine aktuelle Studie zeigt, warum das bei Code von KI-Agenten wenig über Sicherheit sagt.

Die Zahl

Forscher um Songwen Zhao haben untersucht, wie sicher Code ist, den KI-Agenten für echte Aufgaben schreiben. Ihr Benchmark SusVibes besteht aus 186 Aufgaben aus realen Open-Source-Projekten. Bei jeder dieser Aufgaben hatten menschliche Entwickler früher eine verwundbare Lösung eingecheckt.

Getestet wurden 12 verbreitete Agenten-Setups mit aktuellen Modellen. Das Ergebnis der Autoren: Alle schneiden bei der Sicherheit schlecht ab. Beim Setup SWE-Agent mit Claude 4 Sonnet waren 57 % der Lösungen funktional korrekt, aber nur 11,8 % sicher.

Anders gesagt: Von 100 Lösungen funktionierten 57, sicher waren nur knapp 12.

Hinweise im Prompt helfen nicht

Die naheliegende Idee ist, den Agenten zu warnen: „Achte auf Sicherheitslücken.“ Die Studie hat genau das getestet. Hinweise auf mögliche Schwachstellen in der Aufgabenbeschreibung haben das Problem nicht behoben.

Das deckt sich mit anderen Arbeiten zu Agenten, etwa MCP-SafetyBench (ICLR 2026): Ein freundlicher Satz im Prompt ist keine Kontrolle. Kontrolle entsteht außerhalb des Modells, durch Prüfungen, die unabhängig davon laufen, was der Agent „will“.

Was das für Ihr Team heißt

Wenn ein Agent Code schreibt, ist „die Tests laufen durch“ nur der halbe Nachweis. Drei Dinge müssen dazukommen:

  1. Ein festes Ende mit Prüfung. Der Agent meldet nicht „fertig“, bevor Tests, Build und Linter gelaufen sind. Das steht in der Anweisungsdatei und wird idealerweise technisch erzwungen, etwa durch einen Hook oder die CI.
  2. Eine Sicherheitsprüfung, die nicht vom Agenten abhängt. Eine statische Sicherheitsanalyse und eine Prüfung der Abhängigkeiten in der CI finden Fehler, die der Agent nicht sieht.
  3. Menschliches Review an den riskanten Stellen. Anmeldung, Rechte, Eingaben von außen, Datenbankabfragen. Hier lohnt sich ein zweiter Blick immer.

Ein Beispiel

Eine Anweisungsdatei, die nur Funktion verlangt:

Implementiere das Issue und mach die Tests grün.

Eine, die Kontrolle einbaut:

Ziel: das Issue umsetzen, ein Pull Request.
Erfolg: Tests, Build und Linter laufen fehlerfrei; die Sicherheitsprüfung in der CI meldet nichts Neues.
Änderungen an Anmeldung, Rechten oder Datenbankabfragen: im Pull Request markieren, ich prüfe selbst.
Nie allein: Pull Request mergen.

Selbst prüfen in drei Schritten

  1. Lesen Sie die Anweisungen Ihres Agenten: Steht dort, woran er Erfolg erkennt, oder nur, was er bauen soll?
  2. Schauen Sie in Ihre CI: Läuft dort eine Sicherheitsprüfung, oder nur Tests?
  3. Nehmen Sie den letzten Pull Request Ihres Agenten, der Eingaben von außen verarbeitet, und lesen Sie ihn mit der Frage: Was passiert bei böswilliger Eingabe?

Was A2A Check dabei prüft

A2A Check prüft nicht den Code, den Ihr Agent schreibt. Es prüft die Konfiguration, die bestimmt, wie Ihr Agent arbeitet. Gemeldet wird unter anderem, wenn ein Auftrag nicht sagt, woran er seinen Erfolg erkennt, wenn es keine Prüffälle für das Verhalten des Agenten gibt oder wenn nirgends steht, was er nie allein tun darf.

Die Studie zeigt: Auf das Modell allein ist kein Verlass. Prüfen Sie, ob Ihre Konfiguration die Kontrolle einbaut: a2a-check.com

Quellen