Yes, unless you have removed the capability. Analytical engines can fetch a URL from inside a query. That means a query is not only a question about your data, it is potentially an outbound request made by your server, on the caller's behalf, to an address the caller picked.
Why filtering alone is the weaker half. Every filter you write for this is a prediction about what a hostile query looks like, and predictions have gaps: a function you did not list, an encoding you did not decode, a feature the next engine version adds. One missed prediction is a server-side request to wherever the caller chooses, and the worst destination is the cloud metadata address, which hands out credentials to anything that asks from inside the machine.
Remove the capability instead of predicting the payload. The container that executes caller SQL gets no outbound network at all: a firewall rule keyed on that container refuses every destination except its own database and the internal log relay. Reject the cloud metadata addresses for every container by destination rather than by source, because a destination rule cannot go stale when containers move.
Keep the filter as well. This is defence in depth, not a replacement: the engine setting that disables external access and the query gates still do real work. Egress denial is the layer that holds on the day one of them misses.
Two operational details that decide whether it actually works:
- Verify from INSIDE the container, never by reading the rule. Exec in and try to reach a public address: it must fail. Then reach your own database: it must work. A rule that reads correctly and does nothing is the normal failure here.
- A container gets a new address on every redeploy, so a rule pinned to the previous address sits in the rule list looking perfectly healthy and protects nothing. Re-pin on container start, have a scheduled job re-check it, and if that job ever has to CORRECT the rule, your start handler missed one - that is worth an alarm.
The blocked container will still try to resolve external names, fail slowly, and hold a worker for its timeout, so bound that timeout too.
Related: the engine-level settings for DuckDB behind a public API, and securing a database exposed to an AI agent. Full checklist item and the firewall lines: the SQL and query-surface section.
Building something like this? How I work covers the rates, the availability and what I take on.