Waarom die "Co-Authored-By" in je commits eigenlijk nep is

Open je terminal en probeer dit eens:

git commit --allow-empty -m "Fix critical security bug
Co-authored-by: Linus Torvalds <linus@kernel.org>"

Gefeliciteerd. Je hebt zojuist een commit gemaakt waar de maker van Linux officieel aan meewerkte. Niemand vroeg om bewijs. Niemand controleerde of je überhaupt met Linus hebt gesproken. Die kernel-maintainer vertrouwt je nu, toch?

Natuurlijk niet. Maar dit is precies wat er elke dag gebeurt in duizenden organisaties wanneer AI-assistenten "Co-authored-by: Claude" of "Co-authored-by: Copilot" genereren en iemand die later naar die regel kijkt, denkt: dit is attribution.

Het probleem met neppe attributie

Die "Co-authored-by" trailer onderin je door AI geholpen commits is geen echte attribution. Het is een tekststring. Je kunt hem zomaar verzinnen, en dat is prima als het puur cosmetisch is. Maar steeds vaker wordt deze string gebruikt voor iets serieuzers.

Nu AI-assistenten steeds vaker productiecode aanraken, merge pipelines beheren en infrastructuur wijzigen, wordt de vraag "welke agent heeft dit gemaakt?" ineens relevant. Het wordt een vraag over je software supply chain. En zodra platforms onverifieerde attributie-metadata gebruiken om beslissingen te nemen — zoals het automatisch goedkeuren van pull requests op basis van wie er zogenaamd aan meewerkte — heb je een serieus beveiligingsrisico dat gewoon in het zicht ligt.

Het proof-of-concept hiervan is ongemakkelijk. Onderzoekers hebben aangetoond dat vervalste auteur-metadata geautomatiseerde review-werkstromen kunnen misleiden om kwaadaardige commits als vertrouwd te behandelen. Een paar git config-commando's, geen exploits nodig. De agent ziet een "herkende" auteur en gaat verder. De payload landt.

Dit is geen bug in git. Git heeft altijd al toegestaan dat je elke auteur instelt — daarom hebben we GPG-signing. De bug zit in de aanname dat het auteur-veld iets betekent wat het niet betekent.

Waarom dit jouw stack raakt

Als je een startup runt, hier komt het probleem: je door AI geassisteerde development-werkstroom produceert waarschijnlijk tientallen of honderden commits per week. Je CI/CD heeft vast automatisering die bepaalde contributors meer vertrouwt dan anderen. Misschien heb je branch protection ingesteld die bepaalde checks overslaat voor "bekende" auteurs. Misschien laat je AI-reviewagent rekening houden met contributor-reputatie.

Al dat vertrouwen rust op een fundament van vervalsbare strings.

Het probleem wordt extra scherp wanneer je kijkt naar multi-agent werkstromen. Moderne ontwikkeling koppelt vaak agents aan elkaar: één agent schrijft code, een andere reviewt het, weer een andere handelt deployments af. Elke stap claimt authorship. Zonder cryptografische onderbouwing neem je gewoon aan wat ze zeggen. En agents, zoals alle software, kunnen prompt-injected, verkeerd geconfigureerd of gemanipuleerd zijn.

Je zou geen inkooporder accepteren met een handgeschreven "goedgekeurd door CFO" zonder handtekening. Waarom accepteer je dan wel door AI gegenereerde commits zonder enig bewijs van identiteit?

De ontbrekende schakel: cryptografische herkomst

De oplossing is niet om attributie weg te halen — het is om attributie betekenisvol te maken. Wat het ecosysteem nodig heeft, is een producer-attribution laag waarbij claims over welke agent iets heeft gemaakt worden ondersteund door cryptografisch bewijs, niet zomaar tekst.

Dit betekent dat we AI-assistenten moeten behandelen zoals ze zijn: software principals die hun eigen identity infrastructure nodig hebben. Elke agent krijgt een signing key. Commits worden ondertekend met die sleutel. Verificatie gaat via de public key, niet via het auteur-veld. De git trailer wordt een bewering om te verifiëren; de signature wordt het bewijs.

De praktische implementatie heeft een paar lagen:

Plain-text attributie blijft belangrijk omdat mensen het moeten kunnen lezen. Het verschil is dat deze laag nu een bewering wordt om te controleren, niet om zomaar te vertrouwen. Gestructureerde trailers — agentnaam, modelversie, session ID, provider — geven je de audit trail die je nodig hebt. Het session ID is specifiek handig: hiermee kun je schakelen van "deze commit was geschreven door agent X" naar "hier is het exacte gesprek en de context die tot deze code leidde."

Cryptografische signing is het handhavingsmechanisme. Met SSH commit signing (nu native ondersteund door zowel GitHub als GitLab) heeft elke agent een sleutelpaar. De private key leeft in de execution environment van de agent. Wanneer het een commit tekent, bewijst het cryptografisch identiteit. Iedereen kan verifiëren: deze commit is daadwerkelijk geproduceerd door deze agent, omdat alleen deze agent de bijbehorende private key bezit.

Hardware-backed keys maken het robuust. Voor productiesystemen zou de signing key in een hardware security module moeten leven, of minimaal in een dedicated enclave. Dit voorkomt dat een gecompromitteerde agent-runtime de sleutel kan stelen en vervalste commits kan tekenen. De sleutel verlaat de beveiligde omgeving nooit; de agent roept hem aan om te tekenen.

Vertrouwensketens bouwen voor AI-output

Hier wordt het interessant voor platformbouwers. Wanneer je cryptografische provenance hebt voor door AI gegenereerde artefacten, unlock je mogelijkheden die onmogelijk zijn met vervalste metadata.

Audit trails met tanden. Je kunt definitief beantwoorden "welk model produceerde deze code?" voor compliance, debugging of incident response. Het antwoord is verifieerbaar door iedereen, niet zomaar vertrouwd op basis van geloof.

Trust routing. Toekomstige systemen kunnen retrieval-augmented generation anders wegen op basis van geverifieerde producent. Code van een model met een bewezen kwaliteitstrackrecord kan andere behandeling krijgen dan anonieme output. Dit vereist de provenance-laag, niet zomaar beweringen.

IP boundaries. Voor developers die werken aan zowel open source als proprietary code (of werknemers die AI-tools gebruiken met onduidelijke voorwaarden), maakt cryptografische attributie het onderscheid tussen menselijk en AI-geassisteerd werk. Wanneer de IP-clausule in je arbeidscontract zegt "commit geen proprietary code naar publieke repos," maakt verifieerbare attributie compliance controleerbaar.

Model evaluatie. Het correleren van signing principals met uitkomsten stelt je in staat om te meten welke modellen, providers of prompting-strategieën daadwerkelijk betere code produceren. Je kunt niet verbeteren wat je niet kunt meten, en je kunt attributie niet meten als het vervalsbaar is.

Het Grotere Plaatje: AI-agents hebben identity infrastructure nodig

Dit attributieprobleem is een symptoom van een groter gat: AI-assistenten worden geïntegreerd in kritieke infrastructuur voordat we de identity en trust infrastructure hebben gebouwd om ze veilig te hanteren.

We hebben PKI voor mensen. We hebben OAuth voor services. We hebben hardware tokens voor gevoelige operaties. Maar voor AI-agents die code aanraken, tickets modificeren en changes deployen? We vertrouwen grotendeels op een tekststring die zegt "ik ben wie ik zeg dat ik ben."

Dat is geen批评 op de agents — ze doen wat we ze vragen. Het is een gap in systems design. Naarmate AI-agents first-class actors worden in je development workflow, hebben ze first-class identity infrastructure nodig.

Voor de development community betekent dit dat we moeten beginnen met nadenken over agent principals zoals we denken over service accounts. Elke agent heeft zijn eigen credentials, scoped permissions, audit logging en rotation policies. De commit signature is slechts het zichtbare artefact van die infrastructure.

Voor platforms en toolbouwers betekent dit dat verificatie in de review-werkstroom moet worden ingebouwd. Vertrouw het auteur-veld niet — verifieer de signature. Behandel onverifieerde metadata zoals je onverifieerde input behandelt: sanitiseer het, of negeer het.

Die "Co-authored-by" regel verdwijnt niet. Het is nuttige, door mensen leesbare metadata. Maar het behandelen als meer dan een bewering — vooral bij het nemen van trust-beslissingen — is een risico dat de industrie zich niet langer kan veroorloven te negeren.

De tools bestaan. De standaarden rijpen. De enige vraag is of we de infrastructure zullen bouwen voordat het eerste grote incident het urgent maakt.

Spoiler: meestal kost het een incident. Laten we proberen deze keer voor te zijn.

NameOcean's Vibe Hosting biedt AI-geassisteerde development-omgevingen met geïntegreerde signing-werkstromen voor teams die productiecode shippen met AI-agents. Omdat cosmetische attributie niet genoeg is wanneer de inzet real is.