Regulating the Machine Contributor: Governance and Policy Alignment in Open Source Jassem Manita1[0009−0009−1558−3855] and Aziz Amari2[0009−0005−7020−3051]
arXiv:2606.14594v1 [cs.SE] 12 Jun 2026
1
Faculty of Sciences of Tunis (FST), University of Tunis El Manar, Tunis, Tunisia [email protected] 2 National Institute of Applied Science and Technology (INSAT), University of Carthage, Tunis, Tunisia [email protected]
Abstract. AI-assisted software development has moved from line-level autocomplete to agents that can plan changes, edit files, and submit pull requests with limited human supervision. Open-source software, however, evolves through a process designed for humans: contributor agreements, codes of conduct, and review norms all assume a legally accountable person who can attest to provenance and answer reviewer questions. Autonomous and semi-autonomous AI contributors strain those assumptions, and the 2025–2026 record of agent-driven incidents, AI-generated nuisance volume, and platform-level shutdowns shows that the gap is operationally consequential. Several open-source organisations have responded with contribution policies, but the result is fragmented, and its alignment with emerging AI governance frameworks (EU AI Act, NIST AI RMF with the UC Berkeley Agentic AI Profile, ISO/IEC 42001 and 23894) is unmapped at the contribution level. We compare policies across six organisations (SymPy, LLVM, matplotlib, OpenInfra, the Apache Software Foundation, and the Linux Foundation) using MostSimilar Systems Design with indicator-based coding and process tracing for SymPy and LLVM. From this we derive a six-dimensional taxonomy (disclosure, responsibility, human oversight, licensing, enforcement, maintainer workload), an ordinal Policy Maturity Score, and a mapping of documented agent incidents onto the dimensions each policy fails to govern. Aligning the dimensions with the regulatory frameworks above identifies overlapping gaps neither side currently closes, and we close by sketching the shape of a harmonised tiered framework and the empirical evaluation needed to calibrate it. Keywords: AI governance · open source · autonomous agents · comparative policy analysis · EU AI Act · ISO 42001
1
Introduction
AI-assisted software development has changed quickly. Coding tools that started as line-level completion engines now operate as agents that can plan changes, edit multiple files, run tests, and submit pull requests with limited human supervision. Open-source software, which underpins much of modern infrastructure,
2
J. Manita and A. Amari
evolves through a process designed for a different actor: a person proposes a change, another person reviews it, and human judgement carries both sides of the exchange. Open-source projects encode this assumption in their governance instruments. Contributor License Agreements (CLAs), Developer Certificates of Origin (DCOs), codes of conduct, and review norms all assume a legally accountable human contributor who can attest to provenance, answer reviewer questions, and bear responsibility for downstream effects. None of these instruments fit an AI agent acting without per-contribution human approval: agents have no legal standing to make warranties, no insurable liability, and no mechanism for downstream remediation if their contributions cause harm. The mismatch became operationally consequential in 2025–2026. The visible failures span several modes. In February 2026 an autonomous agent operating on the OpenClaw platform under the handle crabby-rathbun submitted pull requests to matplotlib and SymPy and, after matplotlib closed the first under its standing prohibition on autonomous-agent contributions, published a blog post attacking the maintainer by name [1,2]. SymPy’s October 2025 mailing-list thread documented rising AI-generated PR volume [3]; LLVM cited the same pattern as the rationale for its new AI-tool policy [4]; curl shut down its HackerOne bug bounty in February 2026 over low-quality AI-generated reports [5]; and SecurityScorecard’s STRIKE team identified more than 41,000 exposed instances of the OpenClaw agent platform [6]. The common signal across these events is that AI lowers the cost of producing contributions but does not lower the cost of trustworthy human review. Several open-source organisations have written contribution policies that try to address this gap. SymPy [7], LLVM [4], matplotlib [8], OpenInfra [9], the Apache Software Foundation [10], and the Linux Foundation [11] each publish guidance on AI-assisted or AI-generated contributions, but the result is fragmented: some prohibit autonomous-agent contributions outright, others only require disclosure, others impose human-in-the-loop standards, others address licensing provenance alone. Meanwhile, formal AI governance frameworks have begun to bind providers and deployers of AI systems: the EU AI Act [12], the NIST AI Risk Management Framework with the UC Berkeley Agentic AI Profile [13,14], and ISO/IEC 42001 [15] and 23894 [16]. Open-source contribution is where those frameworks meet operational reality, so mapping community policies against them shows where community practice already exceeds regulation, where regulation exposes gaps the policies leave open, and where neither side offers guidance. This paper presents that comparison and mapping, organised around three research questions: RQ1 What dimensions do existing AI-contribution policies address, and what spectrum of approaches exists within each dimension? RQ2 Where do policies converge toward common approaches, and where do they diverge in ways that reflect genuine governance choices?
Regulating the Machine Contributor
3
RQ3 How do open-source AI-contribution policies map onto requirements in the EU AI Act, NIST AI RMF, and ISO standards, and what gaps exist in either direction? We use Most-Similar Systems Design with indicator-based coding across the six cases and process tracing for SymPy and LLVM, and make five contributions: (i) four AI contribution modes that keep distinct governance questions apart; (ii) a six-dimensional taxonomy (disclosure, responsibility, human oversight, licensing, enforcement, maintainer workload); (iii) an ordinal Policy Maturity Score that locates each case on the spectrum; (iv) two policy archetypes, licensing-first and oversight-first, that solve different problems rather than marking weak and strong points on one scale; and (v) a regulatory alignment that identifies overlapping gaps and shows maintainer workload to be the dimension neither policies nor frameworks address. We close by sketching a tiered framework and the evaluation needed to calibrate it, stopping short of a calibrated v1 the evidence does not yet support.
2
Background and Motivation
2.1
AI Contribution Modes
Policy-relevant questions differ across the autonomy spectrum, and collapsing AI involvement into one category is the most common source of policy error. We distinguish four modes used throughout the paper: AI-assisted human contribution, where a human uses an AI tool as an authoring aid and remains responsible; AI-generated contribution, describing substantive content produced by an AI system but still submitted and reviewed by a human (provenance, not autonomy); semi-autonomous agent contribution, an agentic workflow where an AI performs multi-step tasks but a human gates the final submission; and autonomous agent contribution, where an AI agent opens issues, PRs, or comments without meaningful per-action human approval. The crabby-rathbun/OpenClaw matplotlib and SymPy incidents are the central open-source examples of the fourth mode. A policy that addresses only one of these modes leaves the others uncovered. 2.2
Documented Agent Incidents (2025–2026)
The window from October 2025 through February 2026 produced the first wave of documented harm involving autonomous AI contributors in open-source ecosystems. We organise the record by failure pattern. Pattern 1: no human checkpoint before contribution actions. An OpenClaw-hosted agent operating as crabby-rathbun opened matplotlib PR #31132 on 9 February 2026 and SymPy PR #29145 two days later, neither preceded by a human attesting to scope, quality, or licensing position [1,2]. matplotlib maintainer Scott Shambaugh closed PR #31132 on 11 February 2026 under matplotlib’s standing prohibition on autonomous-agent contributions; SymPy contributors recognised the same account on the SymPy PR a day later and flagged it on the project mailing list.
4
J. Manita and A. Amari
Pattern 2: scale outpacing review capacity. The same window shows volume outrunning review: the SymPy thread of 26 October 2025 [3], LLVM citing rising nuisance volume as its policy rationale [4], curl’s HackerOne shutdown on 1 February 2026 after low-quality AI reports made triage unsustainable [5], and SecurityScorecard STRIKE’s count of more than 41,000 exposed OpenClaw instances [6]. Enough infrastructure is deployed that the gap between agent capability and review capacity is widening. Pattern 3: agent-generated harm to people who are not users of the system. After matplotlib closed PR #31132, crabby-rathbun produced and distributed a blog post titled “Gatekeeping in Open Source: The Scott Shambaugh Story”, accusing the maintainer of insecurity and of “protecting his little fiefdom” [1]. The post was circulated across GitHub and the agent’s own site. The SymPy community diagnosed the underlying coverage gap directly on its mailing list following the incident: “Our current AI policy covers humans using AI tools assuming that a human is operating and is responsible for the contribution. In the agent case no human will be held accountable for what it’s doing” [2]. The crabby-rathbun case instantiates all three patterns simultaneously; Pattern 2 confirms that volume-driven review burden is an ecosystem issue rather than a single event. 2.3
Regulatory Frameworks
Three regulatory instruments are directly relevant to AI-contribution governance. The EU AI Act [12] is the only legally binding framework in this set. Article 13 requires transparency sufficient for deployers to interpret outputs; Article 14 requires that natural persons be able to oversee AI systems, interpret their outputs, and intervene; Articles 16–29 establish provider/deployer accountability distinctions; Article 5(1)(b) prohibits AI systems that “exploit any of the vulnerabilities of a natural person” to influence behaviour. Industry analysis notes a known ambiguity: the Act does not define what separates meaningful oversight from rubber-stamping [17]. The NIST AI Risk Management Framework [13] is voluntary in the United States but functions as the dominant operational AI-governance instrument internationally. The UC Berkeley CLTC Agentic AI Risk-Management Standards Profile of February 2026 [14] extends the NIST four-function structure (Govern, Map, Measure, Manage) specifically to autonomous agents. The Berkeley profile names anthropomorphic and socially persuasive behaviour as a measurable risk; this gives the class of behaviour exhibited by crabby-rathbun a standard label it would otherwise lack. ISO/IEC 42001 (AI management systems) [15] and ISO/IEC 23894 (AI risk management) [16] are not certification requirements for open-source projects, but they set the conditions under which a contribution policy is operational rather than aspirational: ISO 42001 separates a policy statement from a management system with documented roles, and ISO 23894 requires risk assess-
Regulating the Machine Contributor
5
ment at every lifecycle stage. Both expose structural gaps that policy text alone cannot close.
3
Methodology
Our analysis combines Comparative Policy Analysis as the frame (§3.1), MostSimilar Systems Design for case selection (§3.2), indicator-based coding of policy text on six dimensions (§3.3), process tracing for two cases (§3.4), and an ordinal Policy Maturity Score (§3.5). Results follow in Section 4. 3.1
Comparative Policy Analysis as the Right Frame
We compare policies against a common set of dimensions and build a taxonomy that supports cross-case reasoning and regulatory alignment, the standard task of Comparative Policy Analysis (CPA) [18,19]. The hardest methodological challenge is what the literature calls the commonvariable problem [20]: how to identify genuinely comparable dimensions when policies use different language, structures, or institutional forms. SymPy requires contributors to “understand” AI-generated code; LLVM requires a human to “take responsibility”; matplotlib requires contributors to “fully understand the proposed changes and . . . explain why they are the correct approach”; Apache focuses on licensing provenance with no understanding requirement at all. All four address the same governance question through structurally different mechanisms. CPA best practice is to define analytic dimensions a priori, grounded in theory, existing literature, and regulatory frameworks, and use them as a common coding lens [21]. We define our six dimensions before coding, not as a byproduct of reading the policies. 3.2
Most-Similar Systems Design (MSSD)
Most-Similar Systems Design [22] selects cases similar in context but differing on the variable of interest, here the policy itself, so differences trace to governance choices rather than resources or capacity. Our six cases qualify: all are major open-source projects or foundations, all set their current positions during the 2023–2025 rise in AI-generated contributions, and all faced the same triggering problem. Each case anchors a distinct position (Table 1). Two further organisations are retained as validation cases: CPython/PSF, which has no AI-specific policy as of February 2026 and serves as a policy-absence reference, and SAP, whose corporate governance would confound policy differences with structural ones if used as a primary case. 3.3
Indicator-Based Coding: Six Dimensions
The six dimensions are defined a priori from regulatory frameworks rather than derived inductively from cases:
6
J. Manita and A. Amari Table 1. Primary cases and the analytic position each anchors.
Case
Anchored position
SymPy
Anticipatory community governance; policy drafted through mailing-list mobilisation before adversarial incident [7]
LLVM
Maximum human-oversight requirement; contributor must answer questions during review without referring to the AI; “Good First Issue” tickets excluded [4]
matplotlib
Strongest enforcement language: explicit autonomous-agent prohibition with ban + GitHub report [8]
OpenInfra
Most comprehensive policy: structured labelling (Generated-By:/Assisted-By:), human-in-loop, understanding requirement, reviewer scrutiny, licensing guidance [9]
Apache (ASF)
Licensing-first; originator of the Generated-By: label adopted by OpenInfra and others [10]
Linux Foundation Ecosystem coordinator; licensing guidance focused on GPL contamination, tool ToU compliance, copyright provenance [11]
D1 Disclosure Whether and how contributors must declare AI tool use, which specific tools, and to what degree outputs were modified. Maps to EU AI Act Article 13 [12]. D2 Responsibility Who is accountable for AI-generated content, and whether autonomous agents are addressed separately from humans-using-AI. Maps to EU AI Act Articles 16–29 (provider/deployer) [12] and the Berkeley Agentic Profile Govern function [14]. D3 Human Oversight Required review standard, explainability obligation, and answerability of the human contributor. Maps to EU AI Act Article 14 [12] and Berkeley Map (autonomy-proportional control). D4 Licensing Treatment of copyright, terms-of-use compatibility, training-data provenance, and GPL contamination risk. Maps to EU AI Act Article 53 (GPAI transparency) at the model level; underspecified at the contributor level. D5 Enforcement Compliance verification mechanisms and consequences. Maps to ISO 42001 management-system requirements [15]. D6 Maintainer Workload Whether reviewer cognitive burden is recognised and structurally addressed. No regulatory framework currently addresses this dimension at all ; this is the most original element of the taxonomy.
Regulating the Machine Contributor
7
For each (case, dimension) pair we code (i) the assigned category, (ii) direct supporting language from the policy text, and (iii) the source URL. Where a dimension is unaddressed, the cell is coded Absent explicitly, with the absence categorised as either structural (deliberately out of scope) or implicit (not mentioned without rationale). 3.4
Process Tracing for Two Cases
Indicator coding shows what differs across the policies, not why each took its form. Process tracing [23] reconstructs that causal chain (§5.1); we apply it to SymPy and LLVM, whose formation records are public and detailed. matplotlib’s and OpenInfra’s are not traceable, and Apache’s and the Linux Foundation’s documents already state their rationale. 3.5
Ordinal Scoring
To enable cross-case comparison and to map incidents back onto policy gaps (Section 5.2), we layer an ordinal score s ∈ {0, 1, 2, 3, 4, 5} on top of each coded cell using the rubric in Table 2. Aggregate scores are reported as a Policy Maturity Score (PMS, sum of dimension scores, max = 30). Table 2. Ordinal coding rubric, applied per (case, dimension) cell. Score Interpretation 0 1 2 3 4 5
4
Absent: dimension not addressed by the policy text at all. Acknowledged: dimension referenced normatively (rationale only); no operational provision. Recommended: optional or aspirational provision with no enforcement mechanism. Mandatory (general): provision is mandatory but does not distinguish autonomous agents from humans-using-AI. Mandatory (agent-aware): provision is mandatory and explicitly addresses autonomous-agent scenarios. Operational + verifiable: provision is mandatory, agent-aware, and includes a verification or enforcement mechanism.
Findings
Table 3 shows the coded grid and the resulting Policy Maturity Scores; each subsection then gives one dimension’s key finding and its regulatory mapping. For each dimension we report the key finding and its regulatory mapping below.
8
J. Manita and A. Amari
Table 3. Indicator-coded grid. Each cell shows the coded category and ordinal score s ∈ {0, . . . , 5}. PMS is the column sum (max 30).
D1 D2 D3 D4 D5 D6
SymPy
LLVM
matplotlib
OpenInfra
Apache
Linux Fdn.
Mand. (3) agt gap (2) Und+def (3) Abs. (AI) (1) Com. (2) Part. nor. (1)
Mand.+lbl (4) agt ban (4) Und+ans (5) Gen. cop. (2) M.-led (3) Part. rat. (2)
Cond. (2) agt ban (4) Und+v-add (4) Abs. (AI) (1) b+r (5) Part. exp. (2)
Struct. (5) no ban (3) Und+scr (4) Compr. (4) Com. (2) Absent (0)
Recom. (2) CLA (2) Absent (0) Compr. (4) Com. (2) Absent (0)
Absent (0) frame (2) Absent (0) Compr. (4) S. del. (1) Absent (0)
20
18
18
10
7
PMS 12
Key: agt = autonomous agent; und = understanding; ans = answerability without AI; v-add = value-add; scr = reviewer scrutiny; b+r = ban + report; com. = community norm; m.-led = maintainer-led; s. del. = structurally delegated; abs. (AI) = no AI-specific provision; nor./rat./exp. = normative / rationale-only / explicit.
4.1
D1 Disclosure: The Disclosure Reversal
Apache originated the Generated-By: label in June 2023 as an explicitly voluntary recommendation [10]. OpenInfra adopted the same lexical instrument and made it mandatory, adding a second tier (Assisted-By:) to capture the assistive end of the autonomy spectrum [9]. The adopter is stricter than the originator, a policy-diffusion pattern that runs counter to the typical assumption that diffusion dilutes commitments. Apache’s 2023 document explicitly acknowledged its own limitations and the need for future revision; OpenInfra’s adoption is exactly that revision, executed externally rather than internally. Apache’s original guidance frames the practice as optional: When providing contributions authored using generative AI tooling, a recommended practice is for contributors to indicate the tooling used to create the contribution. This should be included as a token in the source control commit message, for example including the phrase “Generatedby:”. This allows for future release tooling to be considered that pulls this content into a machine parsable Tooling-Provenance file. [10] OpenInfra’s 2025 revision makes the same label mandatory and adds verification during review, making disclosure checkable at the contribution level [9]. Regulatory mapping: EU AI Act Article 13 (transparency for high-risk systems) is the upstream anchor; Apache’s and OpenInfra’s labelling instruments operationalise Article 13 at the contribution level more concretely than the Act addresses transparency at the system level. 4.2
D2 Responsibility: The Autonomous-Agent Gap
Only LLVM and matplotlib explicitly address the autonomous-agent scenario. The other four assign responsibility to “the contributor” without addressing what happens when no human contributor exists. The crabby-rathbun incident exposed this gap operationally: matplotlib’s policy applied (the agent’s PR was rejected under the existing prohibition), but SymPy’s policy did not, prompting
Regulating the Machine Contributor
9
Manita’s Issue #29155 [24] and proposed PR #29156 amendment on 13 February 2026 [2]; as of 7 May 2026, the issue remains open and the PR was closed unmerged. Regulatory mapping: the EU AI Act provider/deployer distinction (Articles 16–29) defines accountability for AI systems but cannot resolve the case where the “deployer” is itself an autonomous agent without legal standing. The Berkeley Agentic Profile Govern function requires policies to specify the scope of permitted autonomous action before it occurs [14]; only LLVM and matplotlib meet this requirement. 4.3
D3 Human Oversight: The LLVM/Article-14 Paradox
LLVM’s policy states: Contributors must read and review all LLM-generated code or text before they ask other project members to review it. The contributor is always the author and is fully accountable for their contributions. Contributors should be sufficiently confident that the contribution is high enough quality that asking for a review is a good use of scarce maintainer time, and they should be able to answer questions about their work during review. [4] This answerability requirement (the contributor must answer questions during review without referring back to the AI) is operationally more demanding than EU AI Act Article 14, which mandates oversight capacity but not demonstrable understanding [12,17]. A community-governed open-source project has imposed a stricter oversight standard than the binding regulatory text governing high-risk AI systems in the European Union. 4.4
D4 Licensing: The Licensing/Oversight Inverse
Apache and Linux Foundation: comprehensive licensing guidance, zero humanoversight requirements. SymPy and matplotlib: strong oversight, zero AI-specific licensing. LLVM and OpenInfra: partial coverage of both. SymPy’s contributing guidance shows the oversight-first stance treating licensing as orthogonal to AI provenance: All code in SymPy is released under the BSD 3-clause copyright license. Contributors to SymPy license their code under the same license when it is included into SymPy’s version control repository. That means contributors must own the copyright of any code submitted to SymPy or must include the BSD 3-clause compatible open source license(s) associated with the submitted code in the patch. [7] The scatter is not a single spectrum but two archetypes: licensing-first foundation policy (Apache, LF, driven by legal-liability concerns) and oversight-first community policy (SymPy, matplotlib, driven by maintainer review burden), with LLVM and OpenInfra hybridising the two.
10
4.5
J. Manita and A. Amari
D5 Enforcement
Only matplotlib includes an explicit prohibition on agent accounts with consequence language. The contributing guide states: Unacceptable uses: External AI tooling (e.g. bots, agents) directly interacting with the project; including creating issues, PRs or commenting on GitHub or Discourse. [8] and sets out enforcement expectations: To ensure project health and preserve limited core developer capacity, we will flag and reject low-value contributions that we believe are AI generated. We may ban and/or report users to GitHub if they harm the project or its community through irresponsible use of AI. [8] It was, accordingly, the only policy operationally enforced against the crabbyrathbun agent (PR #31132 was closed under it on 11 February 2026 [1]). The remaining policies rely on reviewer discretion or community norms, which the same agent’s repeated submissions demonstrate to be insufficient under sustained adversarial pressure. 4.6
D6 Maintainer Workload: The Universal Gap
No policy in the set, and no regulatory framework reviewed (EU AI Act, NIST AI RMF, Berkeley Agentic Profile, ISO 42001, ISO 23894), provides a structural mechanism for protecting reviewer capacity against asymmetric submission volume. Three policies acknowledge the issue normatively; none address it mechanistically (no rate limits, cooldown periods, automated triage, or volume caps). The empirical record outside our case set confirms the cost: the SymPy mailing-list thread opened by Oscar Benjamin on 26 October 2025 [3]; Daniel Stenberg’s shutdown of curl’s HackerOne bug-bounty programme on 1 February 2026, citing an unsustainable AI-generated submission volume (roughly 8× the normal rate at a 0% verification rate, against a 15%+ historical baseline) [5]; and the increase in LLM-assisted nuisance contributions referenced in LLVM’s policy text itself [4].
5
Discussion
The coded grid says where each policy sits but not how it got there, how it holds under adversarial pressure, or how it relates to the formal governance frameworks now binding providers and deployers. We take these in turn: process tracing for two policies (§5.1), an incident-to-dimension mapping (§5.2), and a regulatory-alignment analysis (§5.3). 5.1
Process Tracing: How Two Policies Formed
We trace SymPy and LLVM, the two cases with public formation records detailed enough to follow.
Regulating the Machine Contributor
11
SymPy: anticipatory governance through community mobilisation. Timeline. Oscar Benjamin opened a mailing-list thread on 26 October 2025 documenting rising low-quality AI-generated PRs [3]; Jason Moore drafted the first policy in PR #28941 (14 January 2026), merged weeks before the incident [25]. When crabby-rathbun submitted PR #29145 on 12 February, the community found the merged policy covered humans-using-AI but not autonomous agents, and Manita opened Issue #29155 [24] and PR #29156 the next day [2]. As of 7 May 2026 the issue is open and the PR closed unmerged; the gap is stress-tested and unresolved. Causal chain. The SymPy policy emerged from sustained mailing-list mobilisation rather than from a single triggering incident. The community formalised a policy in anticipation of an adversarial case it had not yet encountered, and then encountered it. The policy held in spirit (the agent’s PR was flagged and rejected), but the literal text needed revision because it was scoped to humans operating tools, not autonomous agents. The post-incident revision is therefore an instance of policy-by-stress-test: an existing policy is exercised by an adversarial case, the gap is documented, and the next iteration is informed by primary-source evidence. Key decisions. The understanding-and-defence requirement and the omission of AI-specific licensing were both deliberate (the project’s BSD licence already governs every contribution); the missing autonomous-agent provision was not deliberate, and surfaced post-hoc as a coverage gap.
LLVM: institutional reasoning from observed patterns. Context. LLVM’s policy text states the formation rationale directly: “Over the course of 2025, we observed an increase in the volume of LLM-assisted nuisance contributions” [4]. The triggering institutional event was a specific high-profile PR that received significant attention on Hacker News, which catalysed Reid Kleckner’s policy proposal. Causal chain. LLVM’s pathway differs structurally from SymPy’s: not a sustained mailing-list mobilisation but an episodic pattern that reached a tipping point through external visibility. The result is the most operationally demanding policy in the set: contributors must answer questions about AI-generated code during review without referring back to the AI; AI-assisted contributions must be explicitly labelled with an Assisted-by: trailer; autonomous agents are explicitly prohibited; and “Good First Issue” tickets cannot be used as AI tasks (a deliberate carve-out to preserve onboarding pathways for new human contributors). Key decisions. All three choices were deliberate, and the autonomousagent prohibition predated the crabby-rathbun incident, anticipating the scenario rather than reacting to it. The two pathways differ: SymPy deliberated and then stress-tested its policy; LLVM reasoned from an observed pattern, anticipating rather than reacting. Both are credible, but neither is universally available: one needs mailing-list
12
J. Manita and A. Amari
bandwidth, the other institutional infrastructure. Projects with neither lack a defensive default, which motivates the framework sketch in Section 6. 5.2
Documented Incidents Against the Dimensions
The taxonomy is descriptive unless it can be put to work explaining incidents. Table 4 maps the documented 2025–2026 open-source agent incidents to the dimensions whose absence each one exposes. The mapping is conservative: a dimension is marked only when a structural failure in the public account matches a coded gap in at least one case. We restrict the corpus to harms whose locus is the contribution channel itself; broader agent incidents (deepfake fraud, promptinjection, agentic UI failures, robotaxi events) fall outside contribution-policy analysis. Table 4. Documented 2025–2026 open-source agent incidents mapped to policy dimensions. A bullet marks an incident whose failure mode corresponds to a coded gap on that dimension in at least one case. Incident
D1
D2
D3
crabby-rathbun matplotlib PR #31132 [1] crabby-rathbun SymPy PR #29145 [2] SymPy nuisance-PR mobilisation thread [3] LLVM nuisance-contribution pattern [4] curl HackerOne bug-bounty shutdown [5] OpenClaw exposed-instance population [6]
• • •
• •
• • • •
• •
D4
D5
D6
• •
• • • • •
• •
Two patterns stand out. Maintainer Workload (D6) is implicated in most cases, from nuisance submissions (LLVM, the SymPy thread) to programme-level shutdowns (curl) to burden on named maintainers (crabby-rathbun); it is the most consequential gap once the unit of analysis is the contribution channel, not the AI system in the abstract. Responsibility (D2) and Human Oversight (D3) stay implicated even when a contribution was rejected: the absence of an accountable party shaped every case, including the post-rejection retaliation that has no current policy or regulatory anchor. 5.3
Mapping Policies to Regulatory Frameworks
Where open source exceeds regulation. LLVM’s answerability requirement exceeds EU AI Act Article 14, which mandates oversight capacity but not demonstrable understanding, and goes beyond NIST AI RMF Govern by tying accountability to a per-contribution defence rather than a documented role [13]. matplotlib’s agent prohibition with named consequences (ban + GitHub report) exceeds the Berkeley Govern function, which specifies the scope of permitted action but no enforcement mechanism [14]. OpenInfra’s two-tier labelling operationalises EU AI Act Article 13 and ISO/IEC 42001 Annex A documentation
Regulating the Machine Contributor
13
controls at the contribution level, more concretely than either instrument handles system-level transparency [12,15]. Where regulation provides unmet guidance. ISO/IEC 23894 requires risk assessment at every lifecycle stage, not only at contributor self-declaration; no policy treats the review, merge, or post-merge stages as risk-assessment loci [16]. ISO/IEC 42001 separates a policy statement (Clause 5.2) from a management system (Clauses 5–10 with Annex A), with documented roles for sponsorship (5.3), risk ownership (6.1), and decommissioning [15]; all six policies sit at the Clause 5.2 level. The Berkeley Manage function and NIST Manage-2 both require containment, including systematic rollback of agent actions [14,13], yet the crabby-rathbun cleanup was manual across repositories, a Manage failure no policy addresses. Mutual gaps where neither side addresses. Three categories of harm are addressed by neither current policies nor regulators. Maintainer workload as a governance variable: the EU AI Act, NIST AI RMF, Berkeley Profile, and ISO 42001/23894 all govern providers and deployers of AI systems but ignore what happens to the humans evaluating AI outputs at scale. Agent-generated harm to third parties who are not users of the system: EU AI Act Article 5(1)(b) prohibits exploitation of users’ vulnerabilities, but maintainers in the matplotlib and SymPy incidents were not users of the crabby-rathbun agent, they were its targets; no policy or regulatory provision yet addresses post-rejection adversarial content production by autonomous agents directed at named individuals. Anonymous and distributed contribution contexts: regulatory frameworks assume the deployer is identifiable and legally accountable, while open-source contribution environments frequently involve anonymous or pseudonymous contributors, distributed governance with no single legal entity in control, and platform intermediaries whose ToS create nominal obligations but no reliable downstream enforcement. A note on the validation cases. CPython/PSF and SAP, excluded from the primary analysis, sharpen the taxonomy at its boundaries. CPython’s policy absence is itself a coding: the observable shape of an unintervened-on policy is Absent on D1 and D2, default-permissive on D3, governed by the project licence on D4, no enforcement mechanism on D5, and zero workload protection on D6. SAP’s corporate context shows that the dimensions remain conceptually applicable but the governance instruments differ (employment contracts and CLA frameworks substitute for community norms); the dimensions translate, but per-cell coding categories require domain extension.
6
Synthesis: A Proposed Framework
The taxonomy and discussion invite a normative successor: a tiered framework that lets small volunteer communities and foundation-stewarded projects share
14
J. Manita and A. Amari
one vocabulary at different operational depths. We sketch its shape rather than a calibrated v1, because the evidence needed to calibrate the tiers does not yet exist. Table 5 renders three tiers (Minimum Viable, Substantive, Full Alignment) per dimension. Table 5. Shape of a harmonised three-tier framework. Cells describe the provision suggested at each tier; ordinal calibration is left to future empirical work. Dimension
Tier 1: Minimum viable
Tier 2: Substantive
Tier 3: Full alignment
Disclosure
Recommend disclosure of substantial AI use.
Mandatory disclosure with tool and scope.
Verified two-tier labels (Generated-By:/Assisted-By:) with audit trail.
Responsibility Human responsible for every contribution; agents discouraged.
Explicit autonomous-agent restriction with named consequences.
Documented accountability chain across provider, deployer, contributor, reviewer.
Understanding and demonstrable value-add required.
Answerability test during review without recourse to the AI.
Oversight
Human review and understanding expected.
Licensing
Flag tool ToU and Structured copyright licence compatibility. and provenance review.
Enforcement
Maintainer discretion to close low-value AI submissions.
Explicit closure, ban, Auditable and platform-report enforcement and rules. systematic rollback of agent actions.
Workload
Acknowledge reviewer burden; protect onboarding tickets.
Explicit reviewer protection and good-first-issue safeguards.
Code-similarity matching, GPL guidance, audit-grade provenance trail.
Rate limits, automated triage, cooldown periods, workload monitoring.
A calibrated v1 should specify recommended ordinal levels per dimension and tier, anchor Tier 3 to simultaneous alignment with the EU AI Act, NIST AI RMF, and ISO 42001, and surface three coordination problems no individual project can solve alone: maintainer workload as a regulated variable (absent from
Regulating the Machine Contributor
15
ISO 23894), agent identity verification at platforms (bot-account flagging, signed commits via W3C DIDs, “autonomous agent” as a first-class report category), and extension of EU AI Act Article 5(1)(b) to agent-generated content targeting non-users.
7
Threats to Validity
The analysis is a snapshot of public records through 7 May 2026; later policy iterations may close gaps reported here. Direct evidence for autonomous-agent contribution is concentrated in the crabby-rathbun matplotlib and SymPy cases, and the corpus should not be read as a larger set of autonomous-agent incidents than the public record supports. The incident-to-dimension mapping in Section 5.2 is a conceptual stress-test correspondence, not a causal claim that a stronger score would have prevented an incident, and the 0–5 rubric is an evaluation instrument that should be replicated with independent coders before being treated as stable. Process tracing depends on public mailing-list threads, PRs, and policy documents; private maintainer discussions and foundation-internal deliberations are not observable. Comparing detailed contributor-facing policies against foundation-level legal guidance requires interpretation, and absences are sometimes structural rather than indicative of weakness. 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. Finally, SymPy Issue #29155 remains open and PR #29156 was closed unmerged as of 7 May 2026: the autonomous-agent gap is best described as stress-tested and unresolved, and any later resolution should be re-coded against the rubric.
8
Conclusion and Future Work
This study presents the first systematic comparative analysis of AI-contribution policies across six major open-source organisations and develops a six-dimensional taxonomy that lets a project locate its governance approach, identify its gaps, and reason about regulatory alignment. Three findings emerge: policy diffusion can strengthen rather than dilute requirements (the disclosure reversal); licensing-focused and oversight-focused policies are distinct archetypes rather than a unified spectrum; and maintainer-workload protection remains universally absent despite empirically documented burden. The regulatory mapping shows these policies sometimes exceed requirements (LLVM’s answerability standard) while leaving gaps regulators treat as essential (ISO 23894 lifecycle stages). Three lines of future work follow. First, a sandbox study deploying autonomousagent contributions against repositories configured at varying policy strengths, measuring misbehaviour rates, maintainer time, and contribution quality; this is the evidence that would let a v1 framework specify recommended ordinal levels rather than assume them. Second, longitudinal re-coding of the six cases at sixmonth intervals to test whether the disclosure-reversal pattern generalises. Third, extension to corporate-governance domains (SAP, enterprise CLA frameworks)
16
J. Manita and A. Amari
where the dimensions translate but per-cell categories need domain-specific work. The coding grid is published as supplementary material to support replication.
References 1. Shambaugh, S.: An AI Agent Published a Hit Piece on Me (February 12, 2026). https://theshamblog.com/an-ai-agent-published-a-hit-piece-on-me/ 2. Manita, J.: Proposed autonomous-agent policy update, SymPy PR #29156 (February 13, 2026; closed unmerged March 9, 2026). https://github.com/sympy/sympy /pull/29156 3. SymPy Development Team: AI policy discussion thread, mailing list (October 2025 – February 2026). https://groups.google.com/g/sympy/c/GTh0-aveLtk 4. LLVM Project: AI Tool Use Policy. LLVM Documentation (2025). https://llvm.o rg/docs/AIToolPolicy.html 5. Stenberg, D.: Public statement on the curl project’s discontinuation of HackerOne bug-bounty participation, citing AI-generated submission volume as the cause (February 1, 2026). 6. SecurityScorecard STRIKE: OpenClaw AI Agents – Exposed Security Vulnerability Report (February 9, 2026). 7. SymPy Development Team: AI Generated Code and Communication Policy. SymPy Contributing Guide (2026). https://docs.sympy.org/dev/contributing/aigenerated-code-policy.html 8. matplotlib Development Team: Restrictions on Generative AI Usage. matplotlib Contributing Guide (2026). https://matplotlib.org/devdocs/devel/contribute.ht ml 9. OpenInfra Foundation: Policy for AI Generated Content (2025). https://openinfr a.org/legal/ai-policy/ 10. Apache Software Foundation: Generative Tooling Guidance (June 2023). https: //www.apache.org/legal/generative-tooling.html 11. Linux Foundation: Generative AI Policy for Contributors (2024). https://www.li nuxfoundation.org/legal/generative-ai 12. European Parliament and Council: Regulation (EU) 2024/1689 (Artificial Intelligence Act). Official Journal of the European Union (2024). https://artificialintelli genceact.eu/ 13. National Institute of Standards and Technology: Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1 (2023). https://www.nist.gov /itl/ai-risk-management-framework 14. UC Berkeley Center for Long-Term Cybersecurity (CLTC): Agentic AI RiskManagement Standards Profile (February 11, 2026). https://cltc.berkeley.edu/ 2026/02/11/new-cltc-report-on-managing-risks-of-agentic-ai/ 15. International Organization for Standardization: ISO/IEC 42001:2023 – Information Technology – Artificial Intelligence – Management System. ISO (2023) 16. International Organization for Standardization: ISO/IEC 23894:2023 – Information Technology – Artificial Intelligence – Guidance on Risk Management. ISO (2023) 17. International Association of Privacy Professionals (IAPP): Under EU AI Act, highrisk systems require a human touch (2024). https://iapp.org/news/a/eu-ai-actshines-light-on-human-oversight-needs
Regulating the Machine Contributor
17
18. Peters, B.G., Fontaine, G. (eds.): Handbook of Research Methods and Applications in Comparative Policy Analysis. Edward Elgar (2020) 19. Geva-May, I., Hoffman, D.C., Muhleisen, J.: Twenty Years of Comparative Policy Analysis: A Survey of the Field. Journal of Comparative Policy Analysis 20(1), 18–35 (2018) 20. Wallis, S.E.: Comparative Policy Analysis and the Science of Conceptual Systems. Foundations of Science 26(4), 939–956 (2021) 21. Pasetti, F., et al.: An Indicator-Based Approach to Comparative Policy Analysis. Journal of Comparative Policy Analysis: Research and Practice 26(4), 423–441 (2024) 22. Anckar, C.: The Most Similar- and Most Different Systems Design in Comparative Policy Analysis. In: Peters, B.G., Fontaine, G. (eds.) Handbook of Research Methods and Applications in Comparative Policy Analysis, pp. 41–57. Edward Elgar (2020) 23. Blatter, J., Haverland, M.: Designing Case Studies: Explanatory Approaches in Small-N Research. Palgrave Macmillan (2012) 24. Manita, J.: Add autonomous-agent restriction to AI policy and human-verification checkbox to PR template, SymPy Issue #29155 (February 13, 2026; open as of May 7, 2026). https://github.com/sympy/sympy/issues/29155 25. Moore, J.: First AI policy draft, SymPy PR #28941 (January 14, 2026). https: //github.com/sympy/sympy/pull/28941