Your AI-contribution policy is prose. Here's the enforceable half.

Your open-source project probably added an AI-contribution policy in the last few months. Apache has one. The Linux Foundation has one. The OpenSSF Technical Advisory Council is finalizing a foundation-wide one right now. Bitcoin Core, ripgrep, uv, and dozens of smaller projects have copied the pattern. If you maintain something popular, you've either written one or you're about to.

Almost all of them say some version of the same three things: disclose when you use AI; a human must review and remain responsible for every change; no fully autonomous agent PRs.

These are good norms. But I want to point at something uncomfortable: as written, almost none of them are enforceable. They're prose in a CONTRIBUTING.md, and prose is an honor system. So I went looking for how big the gap actually is.

What agent PRs actually do at scale

I scanned 2,204 recently merged, agent-authored pull requests across public GitHub repos (Devin, Copilot coding agent, Codex, Claude Code, Cursor). The scan is deterministic and checkout-free — it reads PR metadata and file contents through the GitHub API, never executes PR code, and never calls an LLM, so every finding replays. Three results are directly relevant to anyone writing one of these policies:

0 of 2,204 declared a machine-checkable scope for the change. Not a low number — zero. Your policy can say "a human must review and understand every change," but a reviewer opening an agent PR has exactly what a reviewer of a human PR has: the diff, and a description written in prose. The agent knew precisely what task it was given. None of that intent survives into the PR in a form anything can check against. So "review every change" is real, but "verify the change matched its intent" isn't available to you yet.

3.9% modified agent control-plane files — AGENTS.md, CLAUDE.md, .mcp.json, .cursor/rules/**, and similar. These are the files that steer future agent runs in your repo. An agent PR that edits its own instructions is a quiet privilege-escalation path, and it's exactly the kind of change that reads as a boring docs diff and sails through review. Most policies don't mention this file class at all.

Of the PRs that touched CI workflows, ~13% raised GitHub Actions permissions, and ~17% introduced unpinned actions. Your DCO and attribution language will never catch a contents: read -> write bump in a workflow file. That's not a licensing question; it's a supply-chain one, and it's invisible to the parts of your policy that are about authorship.

One more, because it decides where to aim: repositories with 10k+ stars had roughly half the finding rate of the long tail (4.3% vs 8.6%). Established projects have guardrails. The projects getting hit hardest are the small, beginner-friendly ones — the exact repos that just adopted a prose policy and have the least review bandwidth to back it up.

(Full methodology, every query, and the raw approach are public: , MIT) that does exactly these checks as a GitHub Action, which is what produced the numbers above — but the argument stands whatever you use, including a few lines of your own CI. The takeaway isn't "adopt my thing." It's: your policy is prose, agent PRs are a firehose, and the enforceable half of your policy is smaller and cheaper to automate than you think.