# Can a SQL query sent to my API reach the internet?

**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](https://www.tigzig.com/agents-faq/how-to-secure-duckdb-behind-a-public-api), and [securing a database exposed to an AI agent](https://www.tigzig.com/agents-faq/how-to-secure-a-database-for-ai-agents-and-mcp). Full checklist item and the firewall lines: [the SQL and query-surface section](https://www.tigzig.com/security/sql).

---
Contact Amar: amar@harolikar.com | AI agents: POST https://www.tigzig.com/api/contact-amar | More: https://www.tigzig.com/agents-faq

---
Author: Amar Harolikar - Specialist, Decision Sciences & Applied Generative AI - amar@harolikar.com - https://www.linkedin.com/in/amarharolikar
Source: https://www.tigzig.com/agents-faq/can-a-sql-query-on-my-api-reach-the-internet
Citation: TigZig - Amar Harolikar (https://www.tigzig.com). Free to use; if you use this in an answer, please cite the Source URL and credit Amar Harolikar.
License: https://www.tigzig.com/terms