Treat SQL like code, because DuckDB runs it with the full privileges of the user who started it. To reduce exposure, disable external access, restrict directories, stop extension auto loading, and lock the configuration. The DuckDB docs describe these as defense in depth, so still run untrusted SQL inside a sandbox.
Why DuckDB needs this
DuckDB is popular in notebooks and pipelines because it reads CSV, Parquet and JSON files straight from disk or the network with a single query. That convenience is also the risk. If someone else's SQL reaches the engine, it can read any file the process can read, unless you take access away.
The securing guide says to treat SQL in DuckDB like code in Bash or Python and to avoid executing untrusted SQL without proper sandboxing. It also says extensions run with the same privileges as the process.
The settings that matter
From the DuckDB securing overview:
| Setting | What it does |
|---|---|
enable_external_access = false | Blocks attaching file databases, COPY to or from files, and reading external sources with functions such as read_csv and read_parquet |
allowed_directories or allowed_paths | Limits file system access to named directories or files |
disabled_filesystems | Turns off individual file systems, for example the local one |
autoload_known_extensions and autoinstall_known_extensions set to false | Keeps you in control of which extensions load |
allow_community_extensions = false | Disables third party community extensions |
lock_configuration = true | Prevents further configuration changes |
allowed_configs | Keeps named settings, such as memory_limit and threads, adjustable while locked |
threads, memory_limit, max_temp_directory_size | Cap CPU, memory and temp disk |
The command line also has a safe mode, started with the -safe option, which blocks access to external files other than the database file.
Order matters
Set the restrictions first, then lock the configuration last. Locking earlier would stop you finishing the setup. After the lock, SQL in that session cannot undo your choices.
SET enable_external_access = false;
SET autoload_known_extensions = false;
SET autoinstall_known_extensions = false;
SET lock_configuration = true;
If a job genuinely needs a data directory, use allowed_directories for that path instead of turning access off completely.
Do not stop at settings
The guide is explicit that these settings are defense in depth and not a substitute for sandboxing. Use a container or virtual machine, drop credentials from its environment, block outbound network access, and give it a read only mount for the data. Sandboxing also limits denial of service, since hostile input can consume memory, disk and CPU.
A few more notes from the guide: persistent secrets are stored unencrypted on disk with restrictive permissions, allow_unredacted_secrets should stay off when running untrusted SQL, and there is no good reason to run DuckDB as root.
Where Safeguard fits
Safeguard's dependency scanning and SBOM generation can show which services embed DuckDB or its Python package, so you can check which of them accept outside SQL. A free scan gets you started.
Quick check
Is enable_external_access enough on its own?
No. It is one layer. The DuckDB docs recommend sandboxing as well.
Should extensions be auto installed in a locked down job?
The guide suggests disabling autoload and autoinstall so you decide what loads.
Sources
Last reviewed: 19 October 2026.
