Das Problem mit der Co-Autor-Fassade

Führen wir ein kleines Experiment durch. Öffne dein Terminal und tippe:

git commit --allow-empty -m "Kritischen Security-Bug behoben"
git commit --amend --no-edit --trailer "Co-authored-by: Linus Torvalds <linus@kernel.org>"

Gratulation. Du hast gerade einen Commit zusammen mit dem Erfinder von Linux erstellt. Niemand hat dich aufgefordert, irgendetwas zu beweisen. Niemand hat überprüft, ob du wirklich mit Linus gesprochen hast. Der Kernel-Maintainer vertraut dir jetzt, oder?

Natürlich nicht. Aber genau das passiert täglich in tausenden Unternehmen – wenn KI-Coding-Agents "Co-authored-by: Claude" oder "Co-authored-by: Copilot" schreiben und jemand downstream diese Zeile als aussagekräftige Attribution behandelt.

Das Attributionstheater-Problem

Hier ist die unbequeme Wahrheit: Dieser "Co-authored-by"-Trailer am Ende deiner KI-unterstützten Commits ist keine Attribution. Es ist ein Textstring. Er ist standardmäßig fälschbar – das ist in Ordnung, solange er nur kosmetisch ist. Aber er wird zunehmend für etwas weitaus Gewichtigeres verwendet.

Wenn KI-Coding-Agents von der Dokumentation und Experimenten weiter zu Produktionscode, Merge-Pipelines und Infrastruktur übergehen, hört die Frage "welcher Agent hat das produziert?" auf, nebensächlich zu sein. Sie wird zu einer Frage der Software Supply Chain. Und wenn Plattformen beginnen, unverifizierte Attribution-Metadaten für Vertrauensentscheidungen zu nutzen – etwa PRs automatisch zu genehmigen basierend darauf, wer sie angeblich erstellt hat – dann hast du eine Angriffsfläche mitten im Blickfeld.

Der Proof-of-Concept ist wirklich beunruhigend. Forscher haben gezeigt, dass gefälschte Autor-Metadaten automatisierte Review-Workflows dazu bringen können, bösartige Commits als vertrauenswürdig zu behandeln. Zwei Git-Config-Befehle, keine Exploits nötig. Der Agent sieht einen "bekannten" Autor und fährt fort. Die Payload landet.

Das ist kein Git-Bug. Git hat dir schon immer erlaubt, beliebige Autoren zu setzen – deshalb gibt es GPG-Signing. Der Bug liegt in der Annahme, dass das Autorenfeld etwas bedeutet, was es nicht tut.

Warum das für deinen Stack relevant ist

Wenn du ein Startup betreibst, wird dir Folgendes nahegehen: Dein KI-unterstützter Entwicklungsworkflow erzeugt wahrscheinlich Dutzende oder Hunderte Commits pro Woche. Deine CI/CD hat vermutlich Automatisierungen, die bestimmten Contributoren mehr vertrauen als anderen. Vielleicht hast du Branch-Schutz konfiguriert, der bestimmte Checks für "bekannte" Autoren überspringt. Vielleicht gewichtet dein KI-Review-Agent den Ruf von Contributoren.

All dieses Vertrauen basiert auf einer Grundlage aus fälschbaren Strings.

Das Attribution-Problem wird besonders kritisch, wenn du Multi-Agent-Workflows betrachtest. Moderne Entwicklung verkettet oft Agenten miteinander – ein Agent schreibt Code, ein anderer reviewed ihn, ein dritter kümmert sich ums Deployment. Jeder Schritt beansprucht Autorschaft. Ohne kryptografische Absicherung nimmst du im Grunde ihre Worte an. Und Agenten können, wie jede Software, prompt-injiziert, fehlkonfiguriert oder manipuliert werden.

Du würdest keine Bestellung mit einer handgeschriebenen "vom CFO genehmigt"-Notiz und keiner Unterschrift akzeptieren. Warum akzeptierst du dann KI-generierte Commits ohne Identitätsnachweis?

Das fehlende Puzzlestück: Kryptografische Provenienz

Die Lösung ist nicht, Attribution zu entfernen – sondern sie bedeutsam zu machen. Was das Ökosystem braucht, ist eine Producer-Attribution-Schicht, bei der Behauptungen darüber, welcher Agent ein Artefakt produziert hat, durch kryptografische Beweise und nicht nur Text abgesichert werden.

Das bedeutet, KI-Coding-Agents so zu behandeln, was sie sind: Software-Prinzipale, die ihre eigene Identitätsinfrastruktur brauchen. Jeder Agent-Prinzipal bekommt einen Signing-Key. Commits werden mit diesem Key signiert. Die Verifizierung passiert gegen den Public Key, nicht das Autorenfeld. Der Git-Trailer wird zur Behauptung; die Signatur wird zum Beweis.

Die praktische Implementierung hat mehrere Ebenen:

Plain-Text-Attribution bleibt wichtig, weil Menschen sie lesen müssen. Der Unterschied ist, dass diese Ebene zur Behauptung wird, die man verifiziert, nicht eine Behauptung, der man vertraut. Strukturierte Trailer – Agentenname, Modellversion, Session-ID, Provider – geben dir den Audit-Trail, den du brauchst. Die Session-ID ist besonders nützlich: Sie ermöglicht es, von "dieser Commit wurde von Agent X geschrieben" zu "hier ist die exakte Konversation und der Kontext, der zu diesem Code führte" zu wechseln.

Kryptografisches Signing ist der Durchsetzungsmechanismus. Mit SSH Commit Signing (jetzt nativ von GitHub und GitLab unterstützt) hat jeder Agent-Prinzipal ein Schlüsselpaar. Der Private Key befindet sich in der Ausführungsumgebung des Agenten. Wenn er einen Commit signiert, beweist er seine Identität kryptografisch. Jeder kann verifizieren: Dieser Commit wurde tatsächlich von diesem Agenten produziert, weil nur dieser Agent den zugehörigen Private Key besitzt.

Hardware-geschützte Keys machen es robust. Für Produktionssysteme sollte der Signing-Key in einem Hardware Security Module oder mindestens in einer dedizierten Enklave liegen. Das verhindert, dass eine kompromittierte Agent-Runtime den Key stiehlt und gefälschte Commits signiert. Der Key verlässt die sichere Umgebung nie; der Agent ruft ihn zum Signieren auf.

Vertrauensketten für KI-Output aufbauen

Hier wird es interessant für Plattform-Builder. Wenn du kryptografische Provenienz für KI-generierte Artefakte hast, schaltest du Fähigkeiten frei, die mit gefälschten Metadaten unmöglich sind.

Audit Trails mit Biss. Du kannst definitiv beantworten, "welches Modell hat diesen Code produziert?" – für Compliance, Debugging oder Incident Response. Die Antwort ist von jedem verifizierbar, nicht nur durch Glauben akzeptiert.

Trust Routing. Zukünftige Systeme könnten Retrieval-Augmented Generation nach verifiziertem Producer gewichten. Code von einem Modell mit nachgewiesener Erfolgsbilanz könnte anders behandelt werden als anonymer Output. Das erfordert die Provenienz-Schicht, nicht nur Behauptungen.

IP-Grenzen. Für Entwickler, die sowohl an Open-Source als auch an proprietärem Code arbeiten (oder angestellte Entwickler, die KI-Tools mit unklaren Bedingungen nutzen), trennt kryptografische Attribution menschenautorisierte von KI-unterstützter Arbeit. Wenn dein Arbeitsvertrag sagt "keine proprietären Commits in öffentliche Repos", macht verifizierbare Attribution Compliance überprüfbar.

Modell-Evaluation. Das Korrelieren von Signing-Prinzipalen mit Ergebnissen ermöglicht es dir zu messen, welche Modelle, Provider oder Prompting-Strategien tatsächlich besseren Code produzieren. Du kannst nicht verbessern, was du nicht messen kannst, und du kannst Attribution nicht messen, wenn sie fälschbar ist.

Das große Bild: KI-Agents brauchen Identitätsinfrastruktur

Dieses Attributionsproblem ist ein Symptom einer größeren Lücke: KI-Coding-Agents werden in kritische Infrastruktur integriert, bevor wir die Identitäts- und Vertrauensinfrastruktur aufgebaut haben, um sie sicher zu handhaben.

Wir haben PKI für Menschen. Wir haben OAuth für Services. Wir haben Hardware-Tokens für sensible Operationen. Aber für KI-Agents, die Code berühren, Tickets modifizieren und Änderungen deployen? Wir vertrauen mostly auf einen Textstring, der sagt "Ich bin, wer ich sage".

Das ist kein Kritik an den Agents – sie tun, was wir von ihnen verlangt haben. Es ist eine Systemdesign-Lücke. Wenn KI-Agents zu erstklassigen Akteuren in deinem Entwicklungsworkflow werden, brauchen sie erstklassige Identitätsinfrastruktur.

Für die Entwickler-Community bedeutet das, dass man anfangen sollte, Agent-Prinzipale so zu betrachten wie Service-Accounts. Jeder braucht seine eigenen Credentials, bereichsbezogene Berechtigungen, Audit-Logging und Rotationsrichtlinien. Die Commit-Signatur ist nur das sichtbare Artefakt dieser Infrastruktur.

Für Plattformen und Tool-Builder bedeutet das, Verifizierung in den Review-Workflow einzubauen. Vertraue dem Autorenfeld nicht – verifiziere die Signatur. Behandle unverifizierte Metadaten so, wie du unverifizierte Inputs behandelst: Bereinige sie, oder ignoriere sie.

Die "Co-authored-by"-Zeile wird nicht verschwinden. Sie ist nützliche, menschenlesbare Metadaten. Aber sie als mehr als eine Behauptung zu behandeln – besonders bei Vertrauensentscheidungen – ist ein Risiko, das die Branche sich nicht mehr leisten kann zu ignorieren.

Die Tools existieren. Die Standards reifen. Die einzige Frage ist, ob wir die Infrastruktur aufbauen werden, bevor ein erster schwerwiegender Vorfall es dringend macht.

Spoiler: Normalerweise braucht es einen Vorfall. Mal sehen, ob wir bei diesem einen vorausschauen können.

Vibe Hosting von NameOcean bietet KI-unterstützte Entwicklungsumgebungen mit integrierten Signing-Workflows für Teams, die Produktionscode mit KI-Agents ausliefern. Denn kosmetische Attribution reicht nicht, wenn die Einsätze hoch sind.