AI Agent 可以讀取企業資料庫，但不應直接拿管理員帳號自由產生 SQL。較安全的架構是將常用查詢封裝成參數化 Tool，搭配唯讀帳號、資料範圍限制、查詢成本控制與完整稽核。
三種常見架構
固定查詢 Tool
由工程團隊預先定義輸入與 SQL，安全、容易測試，適合正式環境的高頻問題。
語意層或核准 View
Agent 在限定資料集與指標中組合查詢，彈性較高，同時維持商業口徑。
自由 Text-to-SQL
探索速度快，但 Schema、權限、成本與錯誤風險較高，宜放在隔離環境並加上解析與政策檢查。
OWASP AI Agent Security Cheat Sheet強調 Tool 授權與執行時驗證；其SQL Injection Prevention與Database Security指引則支持參數化查詢、最小權限，以及避免使用 root 或資料庫擁有者等高權限身份。這些是安全基線，不代表只遵循清單就能解決資料口徑與業務語意問題。
實務情境框：「查某會員近一年訂單」看似簡單，仍涉及身份合併、退款、品牌與權限。若 Agent 任意 Join 原始表，可能同時造成重複計算與個資外洩；核准 Tool 可將這些規則固定。
一次查詢應經過哪些防線？
- 確認使用者與用途。
- 選擇允許的資料 Domain。
- 驗證參數、期間與回傳筆數。
- 以唯讀、限時身份執行。
- 遮罩敏感欄位並限制匯出。
- 記錄 SQL、資料版本、成本與結果摘要。
Agent 不能判斷的事
哪張表才是正式口徑、哪些欄位能組合、資料能保存多久，都需要企業先定義。資料庫連得上，不代表資料已準備好供 AI 使用。
LINKY CONNECT 可處理來源、Mapping 與查詢介面；LINKY REASON 再依角色選用 Tool。高風險寫入應拆成獨立流程並保留人工確認。
結論
安全的資料庫 Agent 應把模型放在「理解問題與選擇工具」的位置，而把權限、SQL、成本與資料政策放在可執行的系統控制中。
常見問題 FAQ
可以讓 Agent 直接寫 SQL 嗎？
探索環境可以受控測試；正式環境優先使用參數化 Tool、核准 View 與唯讀身份。
資料庫唯讀帳號就夠了嗎？
不夠，仍需限制表、欄位、資料列、查詢量與敏感資料輸出。
參考資料與延伸閱讀
以下為 OWASP 社群維護的應用安全指引，用於建立 Agent 與資料庫存取的安全基線。查閱日期：2026 年 9 月 16 日。
- OWASP｜AI Agent Security Cheat Sheet：Tool 授權、輸入驗證與 Agent 邊界。
- OWASP｜SQL Injection Prevention：參數化查詢與注入防護。
- OWASP｜Database Security：資料庫帳號、權限與連線安全。