Simon Willison's AI-Augmented Datasette Ecosystem: Agent, Apps, and Plugins

Simon Willison is building a cluster of AI-native plugins for Datasette, his open-source SQLite data tool. The active components as of mid-June 2026 are datasette-agent (an LLM-powered assistant that can now execute write operations against SQLite databases [1]), datasette-apps (sandboxed HTML/JS mini-applications backed by Datasette's parameterized stored-query system [5]), and datasette-tailscale (an early-alpha plugin exposing a Datasette instance over a Tailnet [3]). Willison uses AI tools — Claude Code for implementation research and Claude Fable 5 for security review — throughout the development process itself [4][5].

The project illustrates a specific pattern: an individual developer using LLMs both to accelerate difficult implementation research (e.g., navigating SQLite C-API internals) and to stress-test security — a combination that found a real privilege-escalation vulnerability before public release [5]. The datasette-apps sandboxing model (CSP-locked iframes with database write access restricted to pre-approved parameterized queries) is a practical, replicable design for LLM-generated web artifacts that need persistent data storage without opening arbitrary SQL write paths.

Simon Willison has been building Datasette since 2017 as an open-source tool for exploring and publishing SQLite databases. In 2026, he has been layering AI capabilities directly into the ecosystem — both by creating LLM-powered plugins and by using LLMs extensively as development and security tools.

The centerpiece of the current work is datasette-agent, a plugin that lets an LLM interact with a Datasette instance through a defined set of tools. Version 0.3a0, released June 15, adds an execute_write_sql tool that prompts the user for approval before modifying the database, with an --unsafe flag that bypasses approval entirely for power users who want to chat their way into direct database modification [1]. datasette-apps (at 0.1a2) provides a system for hosting self-contained HTML+JavaScript applications inside sandboxed iframes within Datasette; write access to the database is constrained to pre-approved parameterized stored queries, and CSP configuration for those apps now requires a dedicated apps-set-csp permission, with an optional allowed_csp_origins allow-list for non-privileged users [2]. A third plugin, datasette-tailscale, arrived at 0.1a0 on June 16 using Python bindings for the experimental tailscale-rs Rust library to expose a local Datasette server over a Tailnet [3].

AI tooling has played a direct role in developing these plugins. To investigate column provenance — mapping SQLite query result columns back to their source table.column — Willison used Claude Code running Opus 4.8, which surfaced three working approaches: one using the apsw library, one calling the SQLite C API directly via ctypes (since Python's standard sqlite3 module does not expose sqlite3_column_table_name()), and one parsing EXPLAIN output [4]. For Datasette Apps, Willison ran a full security evaluation using Claude Fable 5 before the public announcement; the model found a path where a low-privileged user could create a malicious app to exfiltrate data from an administrator who visited it. Willison fixed the vulnerability — the CSP meta tag injected into each iframe is immutable once set, preventing JavaScript running inside the frame from removing the policy — and shipped the feature [5].

A detail threading through these posts: Claude Fable 5 performed the datasette-apps security evaluation before being banned by the US government; by the time Willison did the later column provenance research, the model was unavailable and he used Opus 4.8 instead [4][5]. Willison has also embedded a copyable LLM prompt containing the database schema directly in the datasette-apps plugin, so users can generate new apps by pasting it into any chat interface without Datasette-specific knowledge [5].