DuckDB Extension Allowlists for Embedded Agent Analytics

Embedded analytics stops being small the moment an agent can load new code into the query path.

Local execution still needs a perimeter

DuckDB is useful because it can run close to the data, inside notebooks, applications, CLIs, and local agent workflows. That local footprint is a feature. It also means extension behavior becomes part of the trust boundary.

An extension can add file format support, network access, storage integrations, or domain-specific functions. For an embedded agent, that means an innocent query surface can become an access surface. The right control is not fear of extensions. The right control is an explicit allowlist for which extensions can be installed, loaded, and used for each workflow.

DuckDB makes extensions a first-class mechanism

The DuckDB extension documentation describes dynamically loaded extensions that add features such as new file formats and domain-specific functionality. The DuckDB extension security documentation describes signed extension behavior and the risk of allowing unsigned extensions.

Those controls are useful, but the agent architecture still needs a policy layer. A platform should know which extension names, repositories, versions, signatures, and network behaviors are allowed for each embedded use case.

Govern extension loading like data access

• Define approved extensions by workflow, not by developer preference.
• Pin extension versions where reproducibility matters.
• Block unsigned extensions unless the environment is explicitly marked for development.
• Record extension load events beside query, file, and policy evidence.
• Separate local file analytics from network-capable extension workflows.

This extends DuckDB and local-first analytics, governed data access for agents, and ODI for AI agents. Local does not mean unmanaged. Local means the control plane has to be closer to the work.

What breaks first

• An agent installs a convenient extension that changes network or file access behavior.
• Two environments load different extension versions and produce different results.
• The audit log records the query but not the extension that made the query possible.
• Development settings leak into production embedded analytics.

Questions to ask before embedding DuckDB

• Which extensions can each agent workflow load?
• Who approves new extension sources and versions?
• Can execution evidence show which extensions were active for a result?
• Does the environment separate file-only work from network-capable work?

Sources to start with

These primary sources anchor the technical claims in this guide.

• DuckDB extension overview
• DuckDB securing extensions
• DuckDB installing extensions

Agent analytics can be local and still have a perimeter.