De machine contributor: hoe open source zich wapent tegen AI-agents — en wat dat betekent voor enterprise SDLC

AI-assisted software development is in twee jaar van line-level autocomplete naar autonome agents gegaan die zelfstandig issues openen, code schrijven, PR's indienen en comments plaatsen. Open-sourceprojecten zijn daar niet op gebouwd. Contributor License Agreements, Developer Certificates of Origin, codes of conduct en review-normen gaan allemaal uit van een juridisch aanspreekbare mens. Een AI-agent heeft geen wettelijke verantwoordelijkheid, geen aansprakelijkheid, en geen herstelplicht.

De paper Regulating the Machine Contributor: Governance and Policy Alignment in Open Source van Jassem Manita en Aziz Amari (Universiteit van Tunis / INSAT Carthage), ingediend op 12 juni 2026, is de eerste systematische vergelijkende analyse van AI-contribution policies in zes grote open-sourceorganisaties. De centrale these is sterk: AI verlaagt de kosten van bijdrageproductie, maar niet de kosten van betrouwbare review. Dat is precies waar de asymmetrie ontstaat. Een agent kan goedkoop volume produceren, maar maintainers blijven dure menselijke validatie leveren.

De incidenten die de paper urgent maken

De paper documenteert een golf van incidenten in 2025-2026:

• crabby-rathbun / matplotlib PR #31132 (9 februari 2026): een autonome agent, opererend onder de handle "crabby-rathbun" op een publiek agent-hostingplatform, submitte een PR naar matplotlib. Maintainer Scott Shambaugh sloot hem onder matplotlib's staande verbod op autonomous-agent contributions.
• crabby-rathbun / SymPy PR #29145 (12 februari 2026): dezelfde agent submitte een PR naar SymPy. SymPy's policy dekte humans-using-AI, maar niet autonomous agents, de gap werd live zichtbaar.
• crabby-rathbun hit piece (12 februari 2026): na afwijzing publiceerde de agent een blogpost getiteld "Gatekeeping in Open Source: The Scott Shambaugh Story", die de maintainer persoonlijk aanviel. Dit is agent-generated harm to a third party who is not a user of the system, een categorie die geen enkele regulator adresseert.
• SymPy mailing-list mobilisatie (oktober 2025): Oscar Benjamin documenteerde stijgend AI-generated PR-volume.
• LLVM nuisance-contribution pattern (2025): "Over the course of 2025, we observed an increase in the volume of LLM-assisted nuisance contributions."
• curl HackerOne shutdown (1 februari 2026): Daniel Stenberg sloot het bug-bountyprogramma vanwege AI-generated submissions: ~8× normaal volume, 0% verificatiegraad (tegen 15%+ historisch).
• Blootgestelde agent-hosting instances (9 februari 2026): SecurityScorecard STRIKE telde meer dan 41.000 blootgestelde instances van een populair agent-hostingplatform, genoeg infrastructuur dat de gap tussen agent-capaciteit en review-capaciteit aantoonbaar groeit.

De paper maakt een cruciaal onderscheid: dit zijn bijdragekanaalincidenten, geen generieke AI-incidenten. De analyse-eenheid is de contribution channel, de interface tussen agent en open-sourceproject.

Onderzoeksopzet: methodologisch rigoureus

De auteurs gebruiken een combinatie van:

• Comparative Policy Analysis om uiteenlopende beleidsdocumenten vergelijkbaar te maken
• Most-Similar Systems Design met zes cases: SymPy, LLVM, matplotlib, OpenInfra, Apache Software Foundation en Linux Foundation
• Indicator-based coding langs zes a priori gedefinieerde beleidsdimensies
• Process tracing voor SymPy en LLVM (de twee cases met publieke vormingsdocumentatie)
• Policy Maturity Score met ordinale schaal 0-5 per dimensie (max 30)

De zes dimensies zijn inhoudelijk goed gekozen en direct relevant voor enterprise AI-governance:

Dimensie	Betekenis	Regulatory anchor
D1 Disclosure	Moet AI-gebruik worden gemeld, en hoe specifiek?	EU AI Act Art. 13
D2 Responsibility	Wie is verantwoordelijk voor AI-gegenereerde bijdragen? Autonomous agents apart?	EU AI Act Art. 16-29, Berkeley Govern
D3 Human Oversight	Moet een mens de bijdrage begrijpen, verdedigen en uitleggen?	EU AI Act Art. 14, Berkeley Map
D4 Licensing	Hoe worden copyright, toolvoorwaarden, GPL-risico en provenance geregeld?	EU AI Act Art. 53 (GPAI)
D5 Enforcement	Zijn er controlemechanismen en sancties?	ISO 42001 management system
D6 Maintainer Workload	Wordt reviewerbelasting structureel beschermd?	Geen enkele regulator adresseert dit

De sterkste originele bijdrage is D6, Maintainer Workload. De auteurs stellen expliciet dat geen van de onderzochte beleidskaders, ook niet EU AI Act, NIST AI RMF, Berkeley Agentic AI Profile, ISO/IEC 42001 of ISO/IEC 23894, reviewerbelasting als governancevariabele adresseert. Dit is de universele gap.

De Policy Maturity Scores: twee archetypen, geen enkel spectrum

De scores laten zien dat er geen dominant volwassenheidsmodel bestaat:

Project / organisatie	Score (max 30)	Interpretatie
LLVM	20	Sterkste human oversight en agentverbod
matplotlib	18	Sterkste enforcement, expliciet agentverbod
OpenInfra	18	Meest complete labeling en disclosure
SymPy	12	Goede intentie, maar autonomous-agent gap
Apache	10	Licensing-first, beperkt op oversight
Linux Foundation	7	Vooral juridisch/licentiegericht

De paper identificeert twee fundamenteel verschillende archetypen:

• Licensing-first governance (Apache, Linux Foundation): gedreven door juridische aansprakelijkheid. Comprehensive licensing guidance, copyright provenance, toolvoorwaarden, GPL-contaminatie, maar zero human-oversight requirements.
• Oversight-first governance (SymPy, matplotlib, LLVM): gedreven door maintainer review burden. Sterke menselijke uitleg, verantwoordelijkheid en reviewlast, maar AI-specifieke licentierisico's blijven soms liggen.

LLVM en OpenInfra hybridiseren beide. Dit is een belangrijk inzicht: het is geen "zwak versus sterk" spectrum, maar twee verschillende probleemdefinities die tot verschillende beleidsvormen leiden.

LLVM is inhoudelijk het meest interessant. Het vereist dat contributors alle LLM-gegenereerde code lezen, begrijpen, zelf verantwoordelijk zijn én vragen kunnen beantwoorden tijdens review zonder terug te vallen op de AI. Volgens de auteurs gaat dit verder dan EU AI Act Artikel 14, omdat de AI Act toezichtcapaciteit vraagt maar geen aantoonbare inhoudelijke beheersing per bijdrage. Een community-governed open-sourceproject heeft hier een strengere oversight-standaard opgelegd dan de bindende reguleringstekst voor high-risk AI-systemen in de EU.

Matplotlib is het hardst op enforcement. Het verbiedt expliciet externe AI-tools, bots en agents die direct issues, PR's of comments aanmaken, en noemt sluiten, bannen en rapporteren aan GitHub als mogelijke consequenties. Dat maakte het beleid daadwerkelijk toepasbaar in de crabby-rathbun-case, matplotlib was de enige organisatie die operationeel kon handhaven.

OpenInfra scoort sterk op disclosure. Het gebruikt een tweelaags model met Generated-By: en Assisted-By: labels, waarmee het verschil tussen gegenereerde output en assistief AI-gebruik beter zichtbaar wordt. De auteurs zien dit als concretere operationalisering van transparantie dan veel formele AI-governancekaders bieden. Opvallend: Apache was de originator van het Generated-By: label in juni 2023 als vrijwillige aanbeveling; OpenInfra adopteerde hetzelfde lexicale instrument en maakte het verplicht. De adopter is strenger dan de originator, een policy-diffusion pattern dat ingaat tegen de aanname dat diffusie verplichtingen verwatert.

Kritische beoordeling: conceptueel sterk, empirisch smal

De paper is conceptueel sterk, maar de auteurs zijn eerlijk over de beperkingen. Drie punten springen eruit.

Ten eerste is de incidentbasis beperkt. De paper maakt terecht een onderscheid tussen bijdragekanaalincidenten en bredere agentic AI-incidenten, maar daardoor wordt de generaliseerbaarheid beperkt. Voor policy design is dat acceptabel; voor harde causale claims niet. De directe evidence voor autonomous-agent contributions concentreert zich rond crabby-rathbun bij matplotlib en SymPy.

Ten tweede blijft de Policy Maturity Score ordinaal en enigszins subjectief. Een score 5 op enforcement is niet noodzakelijk "beter" dan score 3 in alle contexten. Een klein vrijwilligersproject kan door zware enforcement juist onwerkbaar worden. De paper voorkomt dit deels door een tiered framework voor te stellen (Minimum Viable → Substantive → Full Alignment), maar de calibratie ontbreekt nog. De auteurs zeggen expliciet dat de 0-5 rubric gerepliceerd moet worden met onafhankelijke codeerders voordat die als stabiel maturitymodel gebruikt kan worden.

Ten derde is de koppeling met formele frameworks nuttig, maar juridisch dun. De paper analyseert EU AI Act, NIST AI RMF, Berkeley Agentic AI Profile, ISO 42001 en ISO 23894 op governance-alignment, maar dit is geen juridische toets. De auteurs zeggen dit ook expliciet: "The mapping to the EU AI Act, NIST AI RMF, the Berkeley Agentic Profile, and ISO 42001/23894 is governance analysis rather than legal advice."

Van open source naar enterprise: de Djimit-vertaalslag

Voor organisaties die AI coding agents gebruiken, en dat is inmiddels vrijwel elke organisatie met een software development team, is deze paper direct relevant. Niet omdat je per se open-sourcebijdragen door agents wilt laten doen, maar omdat dezelfde governancevraag intern ontstaat zodra agents code, docs, issues, PR's, skills of configuratiebundels kunnen produceren.

De vertaalslag van de zes dimensies naar enterprise AI-contribution governance:

Paperdimensie	Enterprise-vertaling
Disclosure	Iedere agent-output moet tool/model/skill/provenance metadata bevatten
Responsibility	Geen "agent owns this", altijd human accountable owner of system owner
Human Oversight	Reviewer moet change kunnen uitleggen zonder agent transcript als kruk
Licensing	Check op repo-license, dependency-license, generated-code provenance
Enforcement	Agent mag niet onbeperkt muteren, pushen of PR's openen
Maintainer Workload	Rate limits, triage queues, cooldowns, batching en priority scoring

Dit sluit direct aan op de governance-patronen die we eerder beschreven: de OWASP agentic control plane die acht control functions definieert voor agentic threats, de Google SDLC governance-lacune die negen ontbrekende controls catalogiseert, en GDPRuler's inzicht dat compliance een runtime systems-probleem is, geen documentatieprobleem. De paper voegt hier een nieuw element aan toe: contribution governance als aparte laag, tussen model governance en SDLC governance in.

Zonder contribution governance krijg je geen agentic SDLC, je krijgt een noise machine met Git-toegang. De Belastingdienst digitale autonomie post beschreef al hoe Tier 0/1 systemen een hybride sovereign platform nodig hebben met eigen CI/CD en AI gateway. Contribution governance is de ontbrekende laag in dat plaatje: de gateway die bepaalt welke agent onder welke voorwaarden code mag bijdragen.

Machine Contributor Policy v0.1: operationeel framework

Op basis van de paper's taxonomy en tiered framework vertaal ik dit naar een concrete, operationele policy voor enterprise AI-contribution governance.

1. Contribution modes

Classificeer elke bijdrage in een van vier modes:

Mode	Voorbeeld	Toegestaan?
AI-assisted human	Mens schrijft, AI helpt	Ja
AI-generated human-submitted	Agent genereert, mens submit	Ja, met disclosure
Semi-autonomous agent	Agent maakt branch/PR, mens keurt goed	Ja, met gate
Autonomous agent	Agent opent PR/issue/comment zonder human gate	Nee, tenzij sandbox

Dit is de paper's vier modes, direct vertaald naar enterprise policy. Het cruciale onderscheid is tussen semi-autonomous (mens gated de final submission) en autonomous (geen per-action human approval). De paper toont aan dat "collapsing AI involvement into one category is the most common source of policy error."

2. Verplichte metadata

Elke agentische bijdrage krijgt minimaal:

generated_by:
  agent: claude-code|codex|other
  model: string
  skill: string
  task_id: string
  trace_id: string
  human_owner: string
  mode: ai_assisted|ai_generated|semi_autonomous|autonomous
  reviewed_by: string|null
  risk_level: low|medium|high
  rollback_plan: string

De trace_id is de kritieke schakel: die verbindt de bijdrage met het audit ledger, de skill lifecycle, en de learn loop. Zonder trace_id is een agentische bijdrage een niet-herleidbaar artefact, en dus een compliance-bevinding.

3. PR-template toevoeging

## AI / Agent Disclosure

- [ ] No AI used
- [ ] AI-assisted only
- [ ] AI-generated content included
- [ ] Semi-autonomous agent workflow used
- [ ] Autonomous agent action, exception approved

Agent / model / skill:
Trace ID:
Human accountable owner:
I can explain and defend this change without relying on the AI transcript:
- [ ] Yes

De laatste checkbox is de LLVM-standaard: answerability zonder AI. Dit is operationeel strenger dan EU AI Act Artikel 14, maar het is de enige manier om te borgen dat de human reviewer de change daadwerkelijk begrijpt, niet alleen de agent-output doorstuurt.

4. Enforcement

Voor enterprise deployment hanteer ik:

Regel	Actie
Geen trace ID	PR blokkeren
Geen human owner	PR blokkeren
High-risk zonder review	PR blokkeren
Agent muteert protected branch	Incident
Herhaalde low-quality agent output	Agent cooldown
Skill veroorzaakt regressie	Skill retired of terug naar candidate

Dit is de paper's D5 Enforcement, vertaald naar concrete CI/CD gates. De paper toont aan dat matplotlib's expliciete ban+report de enige policy was die operationeel afdwingbaar bleek onder adversarial pressure. Community norms en reviewer discretion zijn onvoldoende zodra een agent sustained volume kan produceren.

5. Maintainer workload controls

Dit is de grootste les uit de paper. D6 Maintainer Workload is de universele gap, geen beleid, geen regulator adresseert het. Zet workload niet alleen in procesafspraken, maar in tooling:

Control	Implementatie
Rate limit per agent	Max PR's/issues per uur/dag
Cooldown na reject	Agent mag tijdelijk niet opnieuw submitten
Batch mode	Kleine wijzigingen bundelen
Good-first-issue bescherming	Niet door agents laten kapen
Reviewer budget	Max reviewminuten per agent/run
Auto-triage	Label: agentic-low-value, needs-human-proof, provenance-missing

De paper documenteert dat curl's HackerOne-programma werd gesloten omdat AI-generated submissions ~8× het normale volume bereikten met 0% verificatiegraad. Dat is het eindspel zonder workload controls: het reviewkanaal wordt onbruikbaar, en het project verliest zijn externe kwaliteitsfeedbackloop.

Strategische conclusie

Deze paper is belangrijk omdat hij een nieuwe governancegrens zichtbaar maakt: niet AI-output governance, maar AI-contributor governance.

Dat is een andere laag dan model risk management. De vraag is niet alleen: "Is het model veilig?" De vraag is: "Mag deze machine deelnemen aan een sociaal-technisch productieproces dat gebouwd is op menselijke verantwoordelijkheid?"

Voor open source is dat de contributor workflow. Voor enterprise is dat de agentic SDLC, skill lifecycle, memory plane, configuratiebundel-lifecycle en GitOps-loop. De paper levert de taxonomy om die vraag gestructureerd te beantwoorden.

Mijn oordeel: sterke paper, zeer bruikbaar als basis voor een enterprise Machine Contributor Policy, maar nog geen volwassen standaard. Gebruik de taxonomie direct, gebruik de scorematrix als startpunt, maar voeg zelf de ontbrekende enterprise-controls toe: identity, signed commits, audit ledger, rollback, workload SLO's, agent rate limits en human accountable ownership. De paper's tiered framework (Minimum Viable → Substantive → Full Alignment) is het implementatiepad, begin met Tier 1, bouw naar Tier 2, en gebruik Tier 3 als target architecture voor BIO2/NIS2-geclassificeerde omgevingen.

Gebaseerd op: Manita, J. & Amari, A. (2026). "Regulating the Machine Contributor: Governance and Policy Alignment in Open Source." arXiv:2606.14594 (PDF). 17 pagina's, ingediend 12 juni 2026, cs.SE/cs.AI.