Undeclared dependencies: what an LLM plugin break teaches about supply-chain hygiene

What happened

Simon Willison released llm-tools-datasette 0.1.1, a plugin for his LLM tool that exposes Datasette to models as tools. According to the release note, LLM 0.33 switched to httpx2. That change broke any plugin which used httpx without listing it as its own dependency. llm-tools-datasette was one of them, and 0.1.1 is the fix.

The maintainer's note does not describe a vulnerability, an exploit or any data exposure. We cover it because the failure mode is a common one in software supply-chain work, and it appears in a corner of the ecosystem many security teams are adopting quickly: LLM tool and plugin tooling.

Why an undeclared dependency matters

A plugin that imports a package it never declared works only because something else happened to install it. In this case the host application supplied the HTTP client. When the host changed its client, the plugin broke. Here the symptom was a failure, which is the benign outcome.

The same pattern can have security consequences in other situations. This is our analysis, not something reported in the release note:

• Invisible inventory. An SBOM or dependency scan built from declared requirements will miss packages the plugin actually uses.
• Unreviewed upgrades. Security-relevant libraries such as HTTP clients, TLS handling and parsers change underneath the plugin when the host changes. No one on the plugin side decided to take that change.
• Unpredictable resolution. Without a declared range, the version a plugin runs against depends on whatever the host environment resolved.

Why AI tooling raises the stakes

LLM tool plugins are code that sits between a model and your data. A plugin that lets a model query a database over HTTP makes a network client part of the trust boundary. Teams tend to review the prompt and the permissions, and they review the transport library less often. When agent tooling is assembled from small community plugins, the practical risk is a quiet mismatch between what each plugin assumes and what the host provides.

What to do

1. 1Declare every package your code imports directly in its own requirements, even if the host already ships it.
2. 2Use compatible version ranges rather than leaving them open, and record them in a lockfile for deployments.
3. 3When a host tool such as LLM changes a core library, rerun your plugin tests before rolling the new version out.
4. 4Inventory the plugins in your AI tooling the same way you inventory application dependencies, including who maintains them.

The fix in this case was quick and the maintainer owned the cause. The point for practitioners is that the same discipline catches the harder cases, where an implicit dependency changes behaviour rather than failing outright.