Sicherheitsschulden in Agenten-Pull-Requests: Echte Zugangsdaten stammen meist von Menschen und bleiben in der Prüfung meist ohne Kommentar

Echte Zugangsdaten in Pull Requests autonomer Programmieragenten stammen überwiegend von Menschen, nicht von den Agenten. Zu diesem Ergebnis kommen A H M Nazmus Sakib und Murtuza Jadliwala von der University of Texas at San Antonio sowie Dipayan Banik von Danovo Energy Solutions. Ihre Auswertung steht seit dem 19. Juli 2026 in zweiter Fassung auf arXiv. Zwei quelloffene Sprachmodelle als Gutachter sichteten 16.112 Dateiänderungen aus 4.022 Pull Requests, also Änderungsvorschlägen an GitHub-Projekten; die Treffer zu Zugangsdaten prüfte das Team von Hand. Die Arbeit ist eine Vorabveröffentlichung; ein Workshop der Data-Mining-Konferenz KDD 2026 (Knowledge Discovery and Data Mining) hat sie angenommen, einen Tagungsband gibt es dort laut Workshopseite nicht.

Laut der Studie aus San Antonio enthalten 1.563 der 4.022 Pull Requests, das sind 38,9 Prozent, mindestens einen Security-Smell. Gemeint ist ein Muster im Code, das auf ein Sicherheitsrisiko hindeutet, ohne schon eine nachgewiesene Lücke zu sein. Von 74 bestätigten echten Zugangsdaten hatten laut Sakib und Kollegen Menschen 50 eingebracht, das sind 67,6 Prozent. Bei 60 von 74 Fällen, also 81,1 Prozent, kommentierte nach Angaben der Studie weder ein Sicherheitsbot noch ein menschlicher Prüfer die Zugangsdaten.

Eine zweite Studie fragt, wer agentengeschriebenen Code danach pflegt. Angenommen ist sie für die Fachkonferenz Evaluation and Assessment in Software Engineering (EASE) 2026. Laut Sawada und Kollegen stammen 83,21 Prozent der späteren Änderungen an solchen Dateien von Menschen. Die Provimedia GmbH aus Bietigheim-Bissingen ordnet beide Arbeiten für Teams ein, die Programmieragenten im eigenen Projekt arbeiten lassen. Wie ein Prüfrahmen um solche Agenten arbeitet, beschreibt die Seite zu Code Guardian als Prüfrahmen für KI-Programmierassistenten.

Wo hinterlassen Agenten-Pull-Requests die meisten Sicherheitsschulden?

Die texanische Studie wertete nur Dateien mit hohem Risiko aus, etwa Workflow-, Container- und Konfigurationsdateien; die meisten Befunde fielen in Workflow- und Containerdateien. Von 8.701 gezählten Security-Smells fielen 7.160 oder 82,3 Prozent in die Kategorie Lieferkettenintegrität. Dazu zählen veränderliche Versionsmarken, mit denen ein Projekt fremde GitHub-Actions-Bausteine oder Container-Images einbindet. GitHub-Actions-Workflows und Dockerfiles, die Bauanleitungen für Container, vereinten laut der Studie 87,6 Prozent aller Smells. Als kritisch stuften die Gutachter 253 Smells ein; 252 davon, 99,6 Prozent, waren hartkodierte Zugangsdaten wie Schlüssel oder Token im Klartext.

Mit der Größe der Änderung steigt der Anteil laut Sakib und Kollegen: Pull Requests mit ein bis neun geänderten Zeilen trugen in 16,2 Prozent der Fälle einen Smell, solche ab 1.000 Zeilen in 53,6 Prozent. Nach Agent aufgeschlüsselt nennt die Studie folgende Anteile der Pull Requests mit mindestens einem Security-Smell:

GitHub Copilot: 45,5 Prozent

Claude Code: 41,2 Prozent

Cursor: 40,6 Prozent

Devin: 39,7 Prozent

OpenAI Codex: 34,9 Prozent

Wer bringt echte Zugangsdaten in die Pull Requests der Agenten?

Menschliche Mitwirkende brachten die Mehrheit der echten Zugangsdaten ein, nicht die Agenten. Von 294 markierten Zugangsdaten-Smells konnten die Forscher 272 einordnen, weil 22 Pull Requests nicht mehr existierten. Echte Zugangsdaten statt Platzhalter waren laut der Studie 74, also 27,2 Prozent; der Rest waren Platzhalter, Beispiele oder Fehllesungen. Als Autor des Commits, also der gespeicherten Änderung, fand das Team bei 50 der 74 echten Zugangsdaten einen Menschen und bei 24 einen Agenten.

Auf 14 der 74 echten Zugangsdaten reagierte ein Sicherheitsbot oder ein menschlicher Prüfer mit einem Kommentar, das sind laut der texanischen Studie 18,9 Prozent. Bei den übrigen 60 blieb ein solcher Hinweis aus. Laut Ergebnistext entfernten die Prüfer diese Zugangsdaten ohne Kommentar; Abstract und Kernbefund sprechen von einer Übernahme ohne Hinweis eines Bots oder Menschen. Die Autoren sehen in der hohen Zahl menschlich eingebrachter Zugangsdaten einen möglichen Hinweis auf Ermüdung bei der Durchsicht oder darauf, dass Entwickler das Mitdenken an die Werkzeuge abgeben. Klären müssten das nach ihren Worten weitere Verhaltensstudien.

Wer wartet den Code, den Agenten geschrieben haben?

Menschen übernehmen den größten Teil der Wartung, zeigt die Studie von Shota Sawada und fünf Mitautoren vom National Institute of Technology, Nara College, und dem Nara Institute of Science and Technology. Die Kurzarbeit stand im Juni 2026 im Programm der Fachkonferenz EASE in Glasgow. Eine Fassung im Tagungsband ließ sich bis zum 29. September 2026 nicht nachweisen; zitiert wird die Vorabveröffentlichung auf arXiv vom 9. Mai 2026.

Das Team verfolgte 508 von Agenten und 508 von Menschen angelegte Dateien aus 100 Repositories bis zum 31. Januar 2026. Laut der Auswertung entfielen auf die Agenten-Dateien 1.543 spätere Commits: 1.284 davon oder 83,21 Prozent stammten von Menschen, 259 oder 16,79 Prozent von Agenten. Agenten-Dateien erhielten seltener Wartung als menschlich angelegte. Am häufigsten waren dort Funktionserweiterungen mit 21,78 Prozent der Commits, Fehlerbehebungen machten 11,73 Prozent aus.

Eine geringe Wartungshäufigkeit belegt nach Sawada und Kollegen keine hohe Codequalität. Möglich sei auch, dass Entwickler agentengeschriebenen Code schwer verstehen und deshalb meiden. Die Autoren empfehlen Teams, zu verfolgen, wie sich erzeugte Dateien nach dem Zusammenführen entwickeln, statt die erste Fassung als fertiges Produkt zu behandeln.

Was prüft ein Arbeitsablauf, bevor Agenten-Code übernommen wird?

Code Guardian, das Skill-Paket der Provimedia GmbH für die KI-Programmierassistenten Claude Code und Codex, analysiert den Code laut Anleitung nicht selbst. Das Paket sorgt dafür, dass die etablierten Prüfwerkzeuge der jeweiligen Sprache laufen und ihr Ergebnis nicht übergangen wird; welche das sind, beschreibt das Kapitel über die Prüfwerkzeuge, die installiert sein sollten. Dazu kommen Prüf-Agenten, die laut Produktseite kalt lesen: ohne das Gespräch, ohne den Plan, ohne das Urteil des Autors. Für Auslieferungen nennt die Produktseite den Grundsatz „Nichts erreicht einen Server unklassifiziert“. Für GitHub-Actions-Workflows und Dockerfiles nennt die Anleitung kein eigenes Prüfwerkzeug.

„Die beiden Studien verschieben den Blick vom Agenten auf den ganzen Arbeitsablauf. Wenn Menschen die meisten echten Zugangsdaten einbringen und die Prüfung sie meist ohne Kommentar lässt, reicht es nicht, nur dem Modell zu misstrauen. Wer Agenten Änderungen vorschlagen lässt, sollte die eigene Prüfstrecke so ernst nehmen wie die Wahl des Modells“, sagt Alexander Weipprecht, Geschäftsführer der Provimedia GmbH.

Welche Grenzen haben die beiden Studien?

Die Gutachter der texanischen Studie erreichten gegenüber einer von Hand geprüften Stichprobe eine Trefferquote von 0,775 und übersahen damit 22,5 Prozent der Smells. Die gemeldeten Häufigkeiten unterschätzen die tatsächliche Verbreitung deshalb nach Angaben der Autoren eher. Untersucht wurden nur hinzugefügte Zeilen in Dateien mit hohem Risiko und nur Open-Source-Projekte; ein Smell ist zudem keine nachgewiesene ausnutzbare Lücke.

Die japanische Studie ordnete Commits automatisch mit einem Klassifikationssystem ein, dessen Präzision laut der Studie bei 77,95 Prozent liegt, und ließ Codex außen vor, weil sich dessen Commits keinem Agenten sicher zuordnen ließen. Ihre Pull Requests stammen aus dem AIDev-Datensatz und entstanden zwischen Dezember 2024 und Juli 2025; auch die texanische Studie stützt sich auf AIDev. Agentenfassungen, die im Oktober 2026 im Einsatz sind, erfassen beide Auswertungen damit nicht.

Die Provimedia GmbH ist ein Online-Verlag mit Sitz in der Region Stuttgart. Wir schaffen wertvolle Informationen in unterschiedlichen Branchen um Wissen schnell und einfach zugänglich zu machen. Wir haben uns auf übersichtliche Webseiten und Auffindbarkeit von Informationen spezialisiert.