有界編譯與結構描述證據
輸入超過 4,194,304 個 UTF-16 單位、131,072 個非 End 詞法 token、8,192 層括號分組或 65,536 個 AST 節點時，編譯會拒絕。迭代式 AST 走訪與有界渲染在六種供應者上維持參數順序及無法證明安全即拒絕的原則，不保證任意深度的 SQL 都可接受。
資源上限包含每階段 8,000,000 工作單位、每次編譯 32,000,000 工作單位、每階段 30 秒、每次編譯 90 秒，以及每階段累計 536,870,912 位元組的受控記憶體配置。這些是編譯限制，不是資料庫查詢逾時或程序記憶體上限；超限會回傳具型別的資源診斷。
可選的不可變 schema snapshot 解析資料表、欄位名稱及可證明的型別家族，包含具順序的 CTE／衍生查詢投影，並將摘要繫結至計畫指紋。這是有限範圍的證明，並非完整資料庫型別檢查器。帶有 schema 證據的 DML 需要即時 freshness verifier；證據缺失或結構已變更時拒絕執行。預設不擷取快照；AddHsSqlAgentNativeDmlSchemaFreshness() 提供需明確啟用的原生支援。
hs-sql-agent 不會把 AI 產生的 SQL 直接當成可信任指令執行。真正執行前，SQL 會先經過解析、驗證、功能支援檢查、存取政策檢查，以及針對目標資料庫的編譯。
查詢執行流程
查詢大致會依照以下順序處理：
- 驗證 MCP 金鑰，並套用該金鑰限定的資料庫、資料表、工具與執行權限範圍。
- 把支援的 SQL 解析成結構化定義 / AST。
- 驗證語句與輸入 SQL 的語意是否位於支援範圍內。
- 檢查目標資料庫能否安全表達維持這些語意所需的功能。
- 為設定的資料庫編譯並產生對應 SQL。
- 在設定的執行限制內執行 SQL。
SQL 編譯器明確區分「驗證輸入 SQL 語意」與「確認目標資料庫支援能力」兩個階段。不支援的語法，或無法確認能安全維持相同語意的功能，會直接拒絕，不會偷偷替換成表面相似的結構。
為什麼採用「失敗即拒絕」（fail-closed）？
跨資料庫 SQL 有很多「看起來相同、實際含義不同」的情況，例如 NULL 行為、型別規則、運算子語意、分頁、識別項、函式與 DML 行為。
對 AI 開放的 SQL 執行入口若採用「盡力改寫」，可能讓語法仍然正確，卻在背景改變原意。因此 hs-sql-agent 寧可明確拒絕，也不會默默降低語意保證。
依資料庫產生 SQL
MCP 的公開介面是統一的，但最後產生的 SQL 會依資料庫而異。目前支援的資料庫包括：
- PostgreSQL
- MySQL
- SQL Server
- Oracle
- SQLite
- Firebird
支援範圍是刻意限定的。某個資料庫出現在支援清單中，不代表該產品提供的所有 SQL 語法都可以使用。只有當某項功能的語意能被內部表示並驗證時，編譯器才會把它納入支援範圍。