For most of its history, a serious security audit of an open-source project meant hiring a specialist firm or convincing a volunteer with deep context to spend a week reading the codebase. On September 11, 2026, Simon Willison published a post on his blog titled “Datasette 1.0a39 and 0.65.4 security releases” that documents a different workflow. Two developers and three frontier models spent almost a week auditing the Datasette codebase, found a set of permission and caching bugs that Willison calls “very subtle,” and shipped dual-branch fixes on the same day (Simon Willison).
This is worth paying attention to because Datasette is a small, single-maintainer-style project - exactly the kind of codebase that used to go unaudited. If three frontier models can run a useful audit on Datasette, the workflow is available to every small open-source team running software that touches user data.
What Datasette released
Datasette is a tool for exploring and publishing SQLite databases. It is widely used by journalists, researchers, and small teams to ship interactive data on the public web, which is also why its permission model matters. A bug that lets a viewer see a row they should not be able to see is not theoretical for this project (Datasette blog).
On September 11, 2026, Datasette shipped two releases at once: 1.0a39 on the alpha track and 0.65.4 on the stable 0.65.x branch. Willison advised users to upgrade if they run a Datasette instance on the public web, “in particular if that instance mixes both public and private tables” (Simon Willison).
The bugs being fixed are not glamorous. According to the 1.0a39 release notes on GitHub, the patches tighten permission checks across table and view lookups, full-text search index tables, sqlite_stat1 through sqlite_stat4 statistics tables, the ?_through= filter, foreign-key and incoming-relationship endpoints, and the CREATE VIEW path inside the write-SQL API. They also harden identifier and HTML escaping for column names from untrusted database schemas, restrict URL columns to validated HTTP and HTTPS links, switch personalized responses to Cache-Control: private, no-store, scope actor cookies to expire_after, block restricted actors from creating API tokens, and add clickjacking protection on the stored-query edit form. SQLite extension loading is now disabled after extensions supplied via --load-extension have been loaded.
In other words, this is the unsexy work that determines whether a permissions boundary actually holds. None of the bugs read as headline vulnerabilities. Several of them are the kind of issue a human reviewer can talk themselves out of.
The workflow: humans, three models, and a shared repo
The audit started with reports from Sevban Dönmez and Alex Garcia. From there, Willison and Garcia ran an “extensive audit of Datasette using Claude Fable 5.1, GPT-5.6 Sol, and GPT-6 Astra,” then spent almost a week working through fixes (Simon Willison).
The post describes a deliberately low-tech collaboration. The two developers worked in a shared private repository, and for most issues they split the work in half: “one of us would create the automated tests highlighting the issue, then the other would implement the fix.” Willison’s stated reason is that “this ensured that two separate humans had eyes on each of the issues, in addition to our coding agents running different models” (Simon Willison).
Two details matter here. First, three different frontier models were used rather than one. That does not mean each bug was found by all three, but it does mean that any single model’s blind spots had a chance of being caught by another. Second, the human-in-the-loop split is explicit and structural: one person writes the failing test, a different person writes the fix. A patch that only satisfies its own author’s mental model has to pass another developer’s eyes before it lands.
Willison’s forward-looking note is plain: the models “helped find some very subtle bugs,” and Datasette will be “incorporating security audits by frontier models into all of our development work going forward” (Simon Willison, Datasette blog).
What this looks like in practice
A few operational details from the release are worth noting because they are the parts small projects usually get wrong. The fixes were made on main first, then “backported selected fixes to the 0.65.x branch so we could release both versions on the same day” (Datasette blog). The fixes were already deployed to Datasette Cloud. And some of the new automated tests are being withheld from the public repository, the rationale being to give operators time to upgrade before full vulnerability details are disclosed.
That last point is the part most readers will not have seen a small open-source project do. Disclosure staging is something bigger projects with CVE pipelines and dedicated security mailing lists tend to have. Doing it on a personal project, with the help of a few model accounts, is new.
What this means
For readers who run a small open-source service, the relevant comparison is not “could frontier models have caught this in 2024.” It is “could I, this week, run something like this on my project.” The answer Willison’s post implies is yes, with two caveats he has already baked into his workflow.
The first caveat is human review. The failing-test and implementing-fix split is not a flourish. It is a guardrail against the failure mode where a coding agent generates a fix that satisfies its own test suite but does not match the threat model the audit was supposed to enforce.
The second caveat is model diversity. A single frontier model is a single opinion. Three models disagreeing on the same code is what an audit actually looks like, and Datasette’s release is closer to a panel review than a single reviewer. For a small team, replicating this does not require three paid seats - it requires the discipline to run more than one.
The bottom line
A widely used open-source data tool just shipped a same-day dual-branch security release, audited with three frontier models and a deliberately split human workflow. The bugs themselves were the kind that slip past normal review; the workflow that found them is the part to copy.