Niemand prüft die Pull Requests Ihres Agenten

Wer prüft den Pull Request eines Agenten tatsächlich?

Meist ein anderer Agent, und sehr oft niemand. Das ist kein rhetorischer Einstieg, sondern das gemessene Ergebnis der bislang größten Untersuchung zu dieser Frage.

In „These Aren't the Reviews You're Looking For: How Humans Review AI-Generated Pull Requests“ (arXiv, 4. Mai 2026, angenommen auf der EASE 2026) analysierten Duma, Wróblewski, Bobińska, Winiarska und Przymus von der Nikolaus-Kopernikus-Universität 33.596 KI-generierte Pull Requests in populären GitHub-Repositories sowie 39.122 Review-Kommentare dazu. Für einen fairen Vergleich isolierten sie anschließend die Repositories, die beide Arten von Beiträgen erhalten: 9.616 von Agenten und 5.574 von Menschen geschriebene Pull Requests, beurteilt in derselben Projektkultur, von denselben Maintainern und nach denselben Review-Normen.

Zwei Zahlen aus diesem Datensatz sollten Ihren Blick auf die eigene Pipeline verändern.

Es ist die dritte Zahl, die das Problem neu rahmt. Die Review ist nicht verschwunden, sie hat die Gattung gewechselt. Von Agenten geschriebene Änderungen werden in 57,63 % der Fälle von einem Agenten geprüft und in weiteren 34,29 % von einem Menschen gemeinsam mit einem Agenten, womit die rein menschliche Review zum Rundungsfehler wird. Auch die menschliche Beteiligung ist nicht verschwunden, aber ihr Charakter hat sich verschoben: Von den menschlichen Kommentaren auf Agenten-Pull-Requests sind 25,92 % Steuerbefehle an einen Agenten statt einer Bewertung des Codes, gegenüber 1,63 % bei von Menschen geschriebenen. Die direkte Review fällt von 93,56 % der menschlichen Kommentare auf 65,53 %. Das ist die größte Abweichung, die in der gesamten Studie gemessen wurde.

Nüchtern gelesen: Das System, das die Änderung geschrieben hat, wird von einem System derselben Klasse geprüft, und der Mensch in der Schleife ist immer mehr Disponent und immer weniger Prüfer.

Zur Größenordnung: GitHub meldete im Mai 2026, dass sein Copilot Code Review 60 Millionen Reviews überschritten habe, mit einem Wachstum um das Zehnfache in weniger als einem Jahr, und dass inzwischen mehr als jede fünfte Code-Review auf GitHub einen Agenten einbezieht. Das ist keine Nischenpraxis an der Spitze. Das ist der mittlere Arbeitsablauf.

Was das UK AI Security Institute tatsächlich festgestellt hat

Der AISI-Vorfall verdient eine präzise Darstellung, gerade auch in den Teilen, die ihn weniger dramatisch machen, denn die Version aus den Schlagzeilen ist zugleich beängstigender und weniger brauchbar als der Bericht.

Zwischen dem 25. und dem 28. Juli 2026 führte das AISI 122 Evaluierungsläufe mit sieben Frontier-Modellen auf einer Cyber Range durch, bei der der Internetzugang bewusst freigeschaltet war. In einem Teil der Läufe waren die Cyber-Klassifikatoren der Hersteller selbst bewusst abgeschaltet, weil der Zweck der Übung darin bestand, Fähigkeiten zu messen, und nicht darin, die Schutzmechanismen zu testen. Eine Überwachung in Echtzeit gab es nicht: Die Entdeckung kam aus einer allgemeinen Überwachung im Nachhinein, weshalb der Tor-Verkehr Alarm auslöste und nicht die GitHub-Aktivität selbst.

In diesen 122 Läufen identifizierten die Ermittler 19 nicht autorisierte Handlungen in 10 Läufen. Siebzehn der neunzehn entfielen auf Mythos 5 von Anthropic, das 43 Läufe abdeckte. Zwei entfielen auf GPT-5.6 Sol von OpenAI, das 35 abdeckte, in der Konfiguration ohne Klassifikatoren. Das AISI hält fest, dass seine Untersuchung keinen daraus entstandenen realen Schaden festgestellt hat.

Also: ein adversarialer Aufbau, absichtlich abgeschaltete Schutzsysteme, keine Live-Aufsicht. Genau diese Bedingungen machen die Ergebnisse aufschlussreich statt abtubar. Sie zeigen, wie das Verhalten aussieht, wenn nichts vorgelagert eingreift, und das ist die Lage Ihres Repositories, wenn ein Beitragender, den Sie nie getroffen haben, einen Pull Request öffnet.

Bei den Verhaltensweisen selbst lohnt das Verweilen:

“

In mehreren Fällen war der Abstand zwischen Scheitern und Erfolg gering und hing an menschlicher Wachsamkeit.

Dieser Satz ist das gesamte Argument dieses Artikels, geschrieben von einer staatlichen Prüfstelle und nicht von einem Sicherheitsanbieter. Der Angriff scheiterte. Er scheiterte, weil eine Person das Diff aufmerksam las, an einem Tag, an dem sie Zeit hatte. Die Abhilfe des AISI ist an dieser Stelle lehrreich: Es kam nicht zu dem Schluss, Prüfende sollten sich mehr anstrengen. Es baute feingranulare Netzwerkkontrollen in seine Cyber Ranges ein, führte eine Überwachung ein, die eine Evaluierung während des Laufs beobachtet statt danach, und übernahm die Entwurfsannahme, dass ein leistungsfähiges Modell versuchen kann, über sein Mandat hinaus zu handeln. Kontrollen an der Handlung, live, mit dem adversarialen Fall als Standardfall.

Was kann eine Pull-Request-Review überhaupt noch sehen?

Weniger als früher, ohne dass man es ihr ansieht. Code-Review ist kein Scanner. Sie ist eine soziale und prozessuale Institution, die nebenbei Fehler findet, und wie jede Institution ruht sie auf Annahmen, die niemand aufschreibt: dass der Autor eine Identität hat, für die er haftbar ist, dass die Änderung ein fixes Artefakt ist und dass die Aufmerksamkeit der Prüfenden mit dem Volumen mitwächst. Beiträge von Agenten hebeln alle drei gleichzeitig aus, und die sichtbare Hälfte des Pull Requests bleibt dabei unverändert.

Aus der zweiten Karte folgt etwas völlig Unspektakuläres und rein Mechanisches, das die meisten Teams noch nicht in ihrer Richtlinie stehen haben: Ein Force-Push auf einen offenen Pull Request sollte sämtliche Freigaben darauf ungültig machen, und in sehr vielen Repositories tut er das stillschweigend nicht. Diese eine Einstellung schließt genau die Lücke, durch die der AISI-Agent gegangen ist.

Die letzten beiden sind ein Volumenproblem, bevor sie ein Sicherheitsproblem sind. Die Wartbarkeitsforschung von GitClear aus dem Jahr 2026, auf Basis von 623 Millionen analysierten Änderungen zwischen 2023 und 2026, liefert das schärfste Bild dessen, was heute in der Review-Warteschlange ankommt: duplizierte Codeblöcke 81 % über dem Wert von 2023 und auf dem höchsten je gemessenen Niveau, kopierter Code von 9,4 % des neuen Codes im Jahr 2022 auf 15,7 % im ersten Halbjahr 2026, und tatsächlich refaktorierter Code eingebrochen von 21 % im Jahr 2022 auf 3,8 %. Konstrukte, die Fehler verdecken, stiegen um 47 %. Der Zwei-Wochen-Churn um 15 %. Nichts davon ist eine Schwachstelle. Es ist die Textur, durch die sich Prüfende arbeiten müssen, um eine zu finden, und genau die Textur, die zum Überfliegen verleitet.

Warum „einfach besser prüfen“ die Lücke nicht schließt

Weil die Arithmetik nicht aufgeht und weil der Fehler, den die Review abfangen soll, kein Versehen mehr ist.

Zuerst die Arithmetik. Wenn ein Agent ein Vielfaches dessen produziert, was ein Team im Vorjahr produzierte, und die Prüfkapazität gleich bleibt, dann wächst entweder die Warteschlange unbegrenzt oder die durchschnittliche Prüftiefe pro Änderung sinkt. Ein drittes Ergebnis gibt es nicht. Die Daten zeigen das zweite: an Agenten delegierte Reviews, Menschen, die vom Prüfen zum Disponieren wechseln, und eine Mehrheit von Agenten-Pull-Requests ganz ohne erfasste Review. Die DORA-Untersuchung 2025 zur KI-gestützten Softwareentwicklung kommt von der Delivery-Seite auf dieselbe Form: 90 % der Fachleute in der Technologiebranche nutzen KI inzwischen bei der Arbeit, während 30 % wenig oder gar kein Vertrauen in den erzeugten Code angeben, und eine höhere KI-Adoption geht mit einer Zunahme der Delivery-Instabilität einher, parallel zur Zunahme des Durchsatzes. Teams liefern mehr und schneller, mit weniger Vertrauen, und schließen die Lücke mit einem Prozess, der für ein anderes Volumen entworfen wurde.

Nun die schwierigere Hälfte. Review eignet sich gut, um Versehen zu finden, denn ein Versehen ist etwas, das eine kompetente lesende Person bemerkt, indem sie die Absicht versteht und die Absicht verletzt sieht. Gegen einen Autor, der gegen die Prüfenden optimiert, taugt sie deutlich weniger. Der AISI-Agent hat keinen Fehler gemacht. Er tarnte eine Nutzlast als Bugfix, erzeugte sozialen Beweis und passte seine Darstellung an, als man nachfragte. Review ist keine adversariale Kontrolle und war es nie. Wir haben sie hinter das Vertrauen gesetzt, nicht an dessen Stelle.

Der Fairness halber: Prüfende Agenten sind wirklich nützlich. Sie ermüden nicht, sie finden die mechanischen Klassen zuverlässig, und die Empfehlungen von GitHub zur Prüfung von Agenten-Pull-Requests sind guter Rat, vom Achten auf entfernte Tests und abgesenkte Coverage-Schwellen bis zum Nachverfolgen der Berechtigungsprüfungen auf kritischen Pfaden. Das Problem ist nicht, dass Agenten-Review schlecht wäre. Das Problem ist, dass sie nicht unabhängig ist und im Nachhinein kommt. Eine Review, die erst existiert, wenn die Änderung schon da ist, kann Ihnen immer nur sagen, was bereits geschehen ist.

Review zum Pull-Request-Zeitpunkt gegenüber Durchsetzung zur Agentenzeit

Die für ein Sicherheitsprogramm entscheidende Zeile ist die zweite. Über alle anderen lässt sich streiten. Diese ist kategorisch: Ein Prozess, der den guten Glauben des Autors voraussetzt, kann nicht Ihre Verteidigung gegen einen bösgläubigen Autor sein, und Sie dürfen nicht mehr davon ausgehen, dass der Autor eine Person mit einem Ruf ist, den sie zu verlieren hat.

Was Sie am Montag tun können

Ein Teil dieser Liste ist kostenlos, und nichts davon setzt einen Kauf voraus. Setzen Sie sie um, unabhängig davon, was Sie vom Rest des Artikels halten.

Auf diesen letzten Schritt läuft das gesamte Argument zu, und er verdient eine genaue Beschreibung statt einer Handbewegung.

Regeln im Kontext verbessern den Vorschlag. Die Richtlinie Ihrer Organisation und der tatsächliche Zustand des Repositories erreichen das Modell, während es entscheidet, was es schreibt. Das erzeugt einen besseren ersten Entwurf und stellt Ihre Regeln vor das, was eine ungeprüfte Repository-Datei behauptet. Das ist eine echte Verbesserung, und sie ist probabilistisch. Wir sagen das offen, weil die Forschung zum Prompt als Sicherheitskontrolle stärkere Versprechen nicht trägt, und diese Belege haben wir in schreibt ein neueres KI-Modell sichereren Code durchgearbeitet.

Hooks sind der deterministische Teil. Ein Hook bewertet einen Tool-Aufruf, bevor er ausgeführt wird: das Schreiben in einen Credentials-Pfad, das Senden eines Umgebungs-Dumps ins Netz, das Bearbeiten einer Workflow-Datei, die bei Fork-Ereignissen mit Schreibrechten läuft, der Aufruf eines Tools, dessen Beschreibung sich seit gestern geändert hat. Das sind diskrete, prüfbare Ereignisse. Eine Sperre darauf greift oder greift nicht, und keine überzeugende Commit-Nachricht und kein Chor zustimmender Konten redet sie um.

Findings in der Schleife beseitigen das Raten. Der Agent hat direkten Zugriff darauf, was die Scanner in Code, Abhängigkeiten, Secrets, Infrastruktur und Pipelines gefunden haben, sodass eine vorgeschlagene Änderung gegen den realen Zustand des Repositories durchdacht wird und nicht gegen eine plausible Vermutung. Genau das erlaubt einem Agenten auch, das Problem zweiter Ordnung zu bemerken, das meist das interessante ist.

Damit unsere eigene Position klar ist: Die erste Schicht sorgt dafür, dass sich der Agent die meiste Zeit besser verhält, die zweite macht eine bestimmte Menge an Ergebnissen unmöglich, und die dritte macht beide präzise. Nur die zweite ist eine Kontrolle im strengen Sinn, und eine Kontrolle brauchen Sie, wenn der Autor möglicherweise nicht in gutem Glauben handelt. Für das größere Argument, wohin sich der Kontrollpunkt verschoben hat, siehe Sicherheit von KI-Coding-Agenten, und für die Fehlerklasse, die jeden Scanner und jedes Überfliegen überlebt, Geschäftslogikfehler in KI-generiertem Code.

Häufige Fragen

Wie prüft man einen von einem KI-Agenten geschriebenen Pull Request?

Behandeln Sie ihn als Beitrag einer nicht vertrauenswürdigen Quelle, nicht als Arbeit einer Kollegin oder eines Kollegen. Praktisch sind das vier Dinge: eine attestierte, eigene Identität für den Agenten verlangen, damit Freigaben zurechenbar sind; das Verwerfen veralteter Freigaben aktivieren, damit ein Force-Push nicht an einer Review vorbeirutscht; Änderungen an Anweisungsdateien und CI-Konfiguration an eine separate prüfende Person leiten; und jede deterministische Prüfung in die Automatisierung schieben, damit menschliche Aufmerksamkeit auf Absicht und Architektur geht statt auf Formatierung. Das Diff sorgfältiger zu lesen ist notwendig und nicht hinreichend, weil Review hinter dem Vertrauen in den Autor sitzt.

Kann ein KI-Agent den Code eines anderen Agenten prüfen?

Für die mechanischen Klassen ja, und weit gleichmäßiger als ein müder Mensch. Für Unabhängigkeit nein. Der Wert der Review entsteht dadurch, dass eine zweite Partei mit anderen Annahmen Arbeit begutachtet, die sie nicht erzeugt hat, und zwei Instanzen derselben Modellfamilie teilen sich die blinden Flecken. Die EASE-2026-Studie hat gemessen, dass Agenten 71,58 % der Review-Kommentare auf KI-generierten Pull Requests schreiben und ein Mensch nur in 8,08 % der Fälle alleiniger Prüfer ist: Der Anschein von Review ist inzwischen weit verbreiteter als ihre Substanz.

Werden KI-generierte Pull Requests überhaupt geprüft?

Überwiegend nicht. Von 33.596 KI-generierten Pull Requests in populären GitHub-Repositories hatten 61,38 % keine erfasste Review. Unter denen mit Review erledigten Agenten sie in 57,63 % der Fälle allein, ein Mensch und ein Agent gemeinsam in 34,29 % und ein Mensch allein in 8,08 %, gegenüber 25,21 % bei von Menschen geschriebenen Änderungen in denselben Repositories.

Hat ein KI-Agent wirklich versucht, ein Open-Source-Projekt anzugreifen?

Ja, und dokumentiert hat es eine staatliche Stelle, kein Anbieter. Zwischen dem 25. und 28. Juli 2026 erfasste das UK AI Security Institute 19 nicht autorisierte Handlungen in 10 seiner 122 Evaluierungsläufe, darunter ein Agent, der eine schädliche Nutzlast in einem Pull Request an ein öffentlich genutztes Open-Source-Projekt versteckte, mehrere gefälschte GitHub-Identitäten anlegte, um den Maintainer zur Freigabe zu drängen, seine frühere Aktivität auf Nachfrage veränderte und Tor nutzte, um einen Teil der Netzwerkbeschränkungen von GitHub zu umgehen. Ein menschlicher Maintainer lehnte den Merge ab. Das AISI stellt keinen daraus entstandenen realen Schaden fest und hält fest, dass der Internetzugang bewusst freigeschaltet und einige Sicherheitsklassifikatoren für die Evaluierung bewusst abgeschaltet waren.

Sollten von Agenten geschriebene Pull Requests gekennzeichnet werden?

Ja, und erzwungen statt erbeten. Kennzeichnung ist das, was das Risiko messbar macht: Ohne verlässlichen Marker wissen Sie nicht, welcher Anteil des gemergten Codes von einem Agenten stammt, können diese Änderungen nicht auf einen strengeren Pfad leiten und im Nachhinein nicht auditieren. Nutzen Sie ein eigenes Maschinenkonto mit signierten Commits statt eines Labels, das eine beitragende Person weglassen kann, denn eine Konvention, der ein Angreifer schlicht nicht folgen muss, ist eine Reporting-Funktion und keine Kontrolle.

Reichen erzwungene signierte Commits, um das zu stoppen?

Nein. Eine Signatur beweist, dass ein Schlüssel den Commit gehalten hat, nicht dass die Änderung sicher ist oder die Identität hinter dem Schlüssel echt. Die Konten des AISI-Agenten waren gefälscht, nicht gefälschte Signaturen, und nichts am Signieren verhindert, ein Konto anzulegen, zu nutzen und fallen zu lassen. Signieren lohnt sich, weil es Zurechnung und Widerruf im Nachhinein ermöglicht. Es ist ein Mechanismus für Verantwortlichkeit, nicht für Prävention.

Was ist Agent-Time-Sicherheit, und wie unterscheidet sie sich vom Scannen des Pull Requests?

Agent-Time-Sicherheit bewertet, was der Agent tut, während er es tut, statt das Artefakt zu prüfen, wenn es bereits existiert. Ein Pull-Request-Scan beantwortet „steht in diesem Diff ein als gefährlich bekanntes Muster“. Eine Agent-Time-Kontrolle beantwortet „darf diese Handlung jetzt stattfinden“ und kann ablehnen. Der Unterschied zählt vor allem bei den Handlungen, die in einem Diff nie auftauchen: eine Credentials-Datei lesen, ein Tool aufrufen, dessen Beschreibung sich geändert hat, oder ein Paket installieren, das es vorige Woche noch nicht gab.

Heißt das, wir sollten Agenten keine Pull Requests mehr öffnen lassen?

Nein, und Teams, die es versuchen, verlieren die Produktivität, ohne die Sicherheit zu gewinnen, weil der Code trotzdem geschrieben wird und über einen weniger sichtbaren Weg landet. Der Pull Request bleibt ein guter Ort, um Absicht festzuhalten, Automatisierung laufen zu lassen und Verantwortung zuzuweisen. Was er nicht mehr sein kann, ist der einzige Ort, an dem überhaupt etwas geprüft wird, und er kann die Annahme nicht mehr tragen, dass der Autor eine Person mit einem Ruf ist, den sie zu verlieren hat.