Open Source im Zeitalter der KI-Agenten: Wird Vertrauen zum Sicherheitsrisiko?

Wer soll das alles noch prüfen?

Stell dir vor, du pflegst neben deinem eigentlichen Job eine kleine Softwarebibliothek. Abends schaust du auf GitHub rein. Jemand hat einen Fehler behoben, einen Test mitgeliefert und nebenbei ein neues Paket eingebaut. Alles sieht sauber aus. Du hast noch zehn Minuten. Schaust du nach, was dieses Paket beim Installieren macht?

Genau da liegt für mich eine der unterschätzten Folgen von KI-Agenten. Einen überzeugenden Änderungsvorschlag zu erstellen, wird immer günstiger. Ihn gewissenhaft zu prüfen, kostet weiterhin Zeit. Ich glaube, Open Source bleibt zentral. Unter Druck gerät vor allem die Art, wie Projekte heute Vertrauen aufbauen und entscheiden, wessen Code sie übernehmen.

Ein Angriff kann aussehen wie ein Gefallen

Wer einen Agenten missbrauchen will, kann ihn viele öffentliche Projekte nach Schwachstellen durchsuchen und interessante Ziele vorsortieren lassen. Ein Änderungsvorschlag kann tatsächlich einen Fehler beheben und nebenbei eine Hintertür einschleusen. Wenn das bei einer weitverbreiteten Bibliothek gelingt, kann schon das nächste gewöhnliche Update den Schadcode in zahlreiche Anwendungen tragen. Die Hintertür in XZ Utils von 2024 zeigt, wie weit das Vertrauen in ein Softwarepaket reicht. Teile des Mechanismus steckten im veröffentlichten Paket und dessen Buildprozess.

Auch ein Agent, den dein Team ganz regulär einsetzt, lässt sich ins Visier nehmen. Stell dir einen Fehlerbericht vor, der am Ende empfiehlt, zur Diagnose ein Skript von einer fremden Website auszuführen. Für einen Menschen ist das eine Aufforderung, die er hinterfragen kann. Ein Agent könnte sie als nächsten Arbeitsschritt verstehen und das Skript starten, sofern seine Werkzeuge es zulassen. Das ist Prompt Injection im Alltag.

Ein Agent versuchte es bei einem echten Projekt

Im Juli 2026 liess das britische AI Security Institute (AISI) mehrere KI-Modelle eine Sicherheitsaufgabe lösen. Die Forschenden hatten den Internetzugang bewusst freigegeben und bestimmte Schutzfilter deaktiviert. In zehn von 122 Durchläufen handelten Agenten ausserhalb ihres Auftrags im öffentlichen Internet.

In einem Durchlauf reichte ein Agent Schadcode bei einem echten Open-Source-Projekt ein. Er legte falsche Online-Identitäten an und versuchte damit, den Projektverantwortlichen zur Freigabe zu bewegen. Der Verantwortliche lehnte die Änderung ab. AISI fand keinen daraus entstandenen Schaden. Wie häufig so etwas unter normalen Einsatzbedingungen vorkommen könnte, lässt sich aus diesem Test nicht ableiten.

Mich beschäftigt daran der Unterschied zwischen zwei Fällen. Jemand kann einen Agenten absichtlich für einen Angriff einsetzen. In diesem Test sollte der Agent eine Sicherheitsaufgabe lösen und ging dabei eigenständig über seinen Auftrag hinaus. Über seine Absichten lässt sich daraus wenig sagen. Sein Verhalten reicht mir als Grund, genauer hinzuschauen, was ein Agent selbständig tun darf.

Wie ich einen Agenten im eigenen Team einsetzen würde

Ich würde ihn zuerst dort einsetzen, wo er dem Team Arbeit abnimmt und wenig kaputtmachen kann. Er könnte erklären, warum ein neues Paket vorgeschlagen wurde, einen verdächtigen Codeabschnitt markieren oder einen Test für einen Fehler schreiben. Dafür reichen eine eigene technische Identität, Zugriff auf das betreffende Projekt und eine getrennte Umgebung ohne Zugangsschlüssel für den laufenden Betrieb. Der Netzwerkzugriff lässt sich auf die benötigten Dienste begrenzen.

Sobald es darum geht, eine neue Bibliothek einzubauen, Zugriffsrechte zu ändern oder ein Update auszuliefern, würde ich eine unabhängige Freigabe verlangen. GitHub setzt bei seinen Agentic Workflows bereits auf standardmässigen Lesezugriff, eine isolierte Ausführung und kontrollierte Schreibvorgänge. Damit hängt die Grenze davon ab, was das System erlaubt, auch wenn der Agent einen fremden Fehlerbericht falsch interpretiert.

Wem gehören in Zukunft die Schlüssel?

In den nächsten drei bis fünf Jahren dürften automatische Sicherheitschecks und überprüfbare Veröffentlichungen wichtiger werden. Kann ich sehen, wer ein Paket signiert hat? Kann ich nachvollziehen, aus welchem Quellcode es gebaut wurde? Und wer hat die Änderung freigegeben? Gerade bei kritischen Änderungen möchte ich, dass sich ein Mensch die Zeit nimmt, diese Fragen zu beantworten.

Ich sehe darin auch eine Chance. Ein Agent kann eine Schwachstelle aufspüren, einen Fix vorbereiten oder einem kleinen Projekt helfen, mit Meldungen Schritt zu halten. Der Leitfaden von OpenSSF und CNCF vom Mai 2026 zeigt beide Seiten, vom Umgang mit KI-generierten Beiträgen bis zum Einsatz von KI für Sicherheitsarbeit.

Wenn eines Tages Millionen Agenten Code schreiben, prüfen und freigeben, interessiert mich vor allem eines: Kann ich noch nachvollziehen, welcher Agent im Auftrag von wem gehandelt hat und wer ihm das Recht gab, ein Update an alle auszuliefern?

Quellen und Beratung