Datasette fixed a leaky model list. Allowlists need testing as security boundaries

Simon Willison released datasette-llm 0.1a10 on November 4. It fixes a bug on his agent.datasette.io demo where the available LLMs were not correctly restricted to the models named in the configuration.

Version 0.1a10 put models outside the configuration back out of reach

The primary release note is brief. It confirms the product, version, affected demo and nature of the bug. It does not describe the technical cause, duration or specific user impact. It also provides no basis for claiming that every datasette-llm installation had the same problem.

This is the tenth alpha release in the 0.1 series, not a broad security advisory. Even so, the bug affected a boundary on which an operator relies: the configuration is meant to determine which models an agent can offer at all.

Model choice controls cost, data handling and operating policy

A model allowlist is more than a user-interface preference. Operators may permit individual LLMs based on price, capability, region or data-handling rules. If the runtime exposes a model outside that list, declared policy and actual system behavior diverge.

The source does not show that the demo suffered a financial or security incident. The practical conclusion is narrower: teams cannot treat a configured list as an effective control until they verify that a forbidden model cannot be selected or invoked through another route.

The short changelog leaves the bug's reach unknown

The release note does not say whether the flaw affected only the list shown in the interface or server-side enforcement when a model was called. Without that detail, claims of data exposure, unauthorized access or billing bypass would go beyond the evidence.

The alpha label also supplies useful context. Early software changes quickly, and its interfaces and security boundaries are still settling. That is precisely why restrictions need tests just as much as features do.

The next release should reveal whether the allowlist gained a regression test

The most useful next signal is simple: a documented test that requests a disallowed model and expects rejection. In an agent interface, enforcement should occur on the server for every request, not only when the browser builds a menu.

Current operators should upgrade to 0.1a10 and compare their configuration with observed behavior. The release fixed one specific demo. Only a test of each deployment can show whether its own boundary holds.

Lilith's verdict

A sign saying approved models only stops nobody unless a barrier stands behind it. Datasette repaired the barrier; now it needs a test that deliberately drives into it on every release.