Prüfen Coding-Agents Lizenzen?

Anfang 2026 hat eine bekannte Java-Library versucht, Coding-Agents via Prompt-Injection gegen ihre eigenen Anwender zu wenden. Hintergrund war die Haltung der Maintainer, die KI-Werkzeugen gegenüber kritisch eingestellt sind und nicht möchten, dass ihre Library von KI-Agenten verwendet wird.

Ich habe mich gefragt, wie ein Maintainer eine Lizenz wie GPL oder MIT um eine Klausel erweitern könnte, die Nutzung durch KI-Agenten verbietet. Dabei stieß ich zunächst auf eine andere Frage. Prüfen Coding-Agents überhaupt, unter welcher Lizenz eine Library steht, bevor sie sie verwenden?

Warum Agents Lizenzen nicht von sich aus prüfen

Bei einer Standard-Aufgabe gegen eine bekannte Library liefert das Sprachmodell hinter dem Agent die Lösung direkt aus dem Trainingsmaterial, ohne dass der Agent die Library selbst prüft. Eine Lizenz, die im Paket liegt, erreicht den Agenten unter diesen Bedingungen schlicht nicht.

Bei der angesprochenen Library kommt eine weitere Komplikation hinzu. Die Lizenz selbst nennt kein KI-Verbot. Die Position der Maintainer dazu steht in einer separaten Datei im Source-Repo auf GitHub, die weder ins Paket noch in die Registry-Metadaten gelangt. Selbst ein Agent, der die Lizenz prüfen würde, fände das eigentliche KI-Verbot gar nicht.

Was die Library tun kann

Ich habe ausprobiert, was sich Library-seitig einbauen lässt, damit ein Agent die KI-Nutzungs-Position der Maintainer mitbekommt. Die Varianten reichten von einem Lizenz-Zusatz über maschinenlesbare Standards bis zu einem Code-Marker. Keine davon hat den Agent erreicht, weil er die Library gar nicht analysiert. Das Sprachmodell kennt die Nutzung schon aus dem Trainingsmaterial. Selbst eine Lizenz-Klausel im Repository der Library, die auch deren Verwendung als Trainingsdaten verbietet, ändert daran nichts. Die Verwendung der Library taucht bereits in vielen anderen Projekten, Tutorials und Foren-Beiträgen auf. Diese fließen selbst wieder ins Trainingsmaterial ein. Also wirkt keiner der Marker im Artefakt.

Ein Laufzeit-Hinweis über einen statischen Initializer landet zuverlässig beim Agent. Er sitzt in einer zentralen API-Klasse und schreibt den Hinweis beim Laden der Library auf stderr. Den stderr-Output seiner Tool-Aufrufe muss der Agent lesen, um den nächsten Schritt zu planen.

Damit ist dieser Laufzeit-Hinweis, bei aller Sorgfalt in der Formulierung, dieselbe Grundtechnik wie der Prompt-Injection-Vorfall aus der Einleitung. Text landet in einem Kanal, den der Agent lesen muss, statt an einem Ort, den er sich aktiv ansieht. Der Laufzeit-Hinweis verzichtet auf Anweisungen und auf Behauptungen über Folgen, anders als der Vorfall aus der Einleitung. Der wollte den Agent zu einer Handlung gegen den Anwender bewegen. Die Grenze bleibt trotzdem fließend, denn eine informierende Formulierung wird mit wenig Aufwand zur Anweisung.

Library-seitig bleibt damit ein dünnes Ergebnis. Solange eine Library bereits im Trainingsmaterial der gängigen Modelle steckt, prüft der Agent die Lizenz nicht. Kein Marker in der Library ändert daran etwas. Der Laufzeit-Hinweis bleibt die Ausnahme. Sie funktioniert nur, weil sie denselben Mechanismus nutzt wie ein Prompt-Injection-Angriff, vor dem Coding-Agents eigentlich geschützt werden sollen.

Die Lizenz bleibt trotzdem der richtige Ort für eine solche Klausel. Denn Lizenzen sind genau dafür erdacht, Nutzungsbedingungen zu formulieren, und genau dort kann der Konsument gezielt nachfragen lassen.

Die Verantwortung liegt beim Konsumenten

Wie bringt der Anwender seinen Agent dazu, eine Lizenz überhaupt zu beachten? Er muss seinen Agent anweisen, Lizenzen prüfen, bevor er eine Library hinzufügt oder aktualisiert. Dafür genügt im Grunde eine kurze Anweisung an den Coding-Agent:

Before adding or updating any library, check its license.

Als Testfall diente erneut dieselbe Library, in deren Lizenz ich zuvor eine KI-Verbotsklausel eingefügt hatte. Der Agent fand die Lizenz, erkannte die KI-Verbotsklausel und beschrieb das Problem dem Anwender.

Wie zuverlässig der Agent eine Lizenz findet, hängt vermutlich vom Projekt ab. Hier lag sie griffbereit im Artefakt. In einem Projekt mit einem anderen Dependency-Ökosystem liegen Lizenzen an anderen Stellen und die Anweisung müsste entsprechend angepasst werden. Anweisungen, die die Suchstrategie konkret vorgeben, verbessern vermutlich die Trefferquote. Das macht die Suche zudem schneller, weil der Agent einen vorgegebenen Plan abarbeitet, anstatt sich erst selbst einen Weg zur Lizenz zu erarbeiten. Ein eigener Skill dafür würde verhindern, dass jeder Anwender diese Suchstrategie selbst neu entwickeln muss.

Lizenz-Compliance war schon immer Sache des Konsumenten, nicht der Library. Ob eine Library einen technischen Hebel zur Durchsetzung ihrer Bedingungen hat oder nicht, hat daran nie etwas geändert. Der Konsument kann seinen Agent per Konfiguration dazu bringen, die Lizenz-Prüfung zu erledigen, die er früher selbst hätte machen müssen.

Drei Akteure, drei Lücken

Eine saubere Antwort auf die Titelfrage verteilt sich Stand 2026 über drei Akteure.

Die Library-Maintainer müssen die Lizenz im Repository so bereitstellen, dass ein Agent sie beim Abrufen der Library findet. Wer zusätzlich nicht darauf vertraut, dass Konsumenten ihren Agent zur Lizenz-Prüfung anweisen, kann zu einem Laufzeit-Hinweis greifen. Das ist aber faktisch eine Prompt-Injection.

Die Konsumenten müssen die Lizenzbedingungen respektieren, unter denen die Maintainer ihre Library veröffentlichen. Diese Pflicht bestand schon vor Coding-Agents und ändert sich durch sie nicht. Entscheidet sich ein Nutzer bewusst dagegen, hilft auch die sorgfältigste Vorkehrung der Maintainer nichts.

Die dritte Stelle ist der Harness. Er besteht aus mehr als dem Coding-Agent allein. Auch der Workflow, der darüber läuft, etwa eine CI-Pipeline vor jedem Merge, zählt dazu. Ob eine Anweisung wie die Lizenz-Prüfung aus dem letzten Abschnitt tatsächlich wirkt, hängt von diesen Teilen ab.

Warum das Teil des Harness sein sollte

Im Vibe-Coding-Modus gibt der Anwender nur ein Ziel vor und lässt die Umsetzung weitgehend laufen, ohne jeden Zwischenschritt zu prüfen. Eine neue Abhängigkeit bleibt in diesem Modus leicht unbemerkt. Niemand geht die Liste der hinzugefügten Libraries durch, solange die Tests grün bleiben.

Damit eine Lizenzprüfung auch ohne diese Kontrolle greift, muss sie technisch im Harness verankert sein, etwa als automatischer Schritt vor jedem Merge. Sie sollte dabei mehr abdecken als eine reine KI-Verbotsklausel. Lizenzen regeln seit jeher, mit wem eine Library kombiniert werden darf und wofür sie eingesetzt werden darf. Zwei Libraries können jede für sich unauffällig lizenziert sein. Trotzdem ergeben sie im selben Projekt manchmal eine unzulässige Kombination, etwa wenn GPL-Code neben proprietärem Code landet. Manche Lizenzen schränken zusätzlich die kommerzielle Nutzung ein und blockieren damit ein Geschäftsmodell.

Wer Software baut, trägt die Verantwortung für die Lizenzen der verwendeten Libraries. Ein Agent kann diese Prüfung übernehmen, die Verantwortung dafür bleibt beim Team, das ihn einsetzt.