我在維護一個開源（MIT）、可以自架的網頁版資料庫工具 LibreDB Studio，最近在做「AI Agent 只能讀資料庫」的功能，遇到一個 PostgreSQL 權限的問題想請教。

在 PostgreSQL 18 上實測，用 superuser 連線時，下面三種操作在 BEGIN READ ONLY 裡都會成功：

• COPY (...) TO '/path/to/file'：把查詢結果寫到伺服器上的檔案
• COPY (...) TO PROGRAM 'cmd'：用資料庫的作業系統帳號執行 shell 指令
• SELECT pg_read_file('/path/to/file')：讀取伺服器上的檔案

我知道標準答案是「不要給 superuser」。我們的難處是：連線帳號是使用者自己填的，工具端要怎麼確認它真的是低權限？

目前的做法是建立連線時先檢查角色，只要是 superuser，或是 pg_read_server_files、pg_write_server_files、pg_execute_server_program 其中任何一個的成員，就拒絕連線。另外，每個交易只允許跑一條 statement，跑完一律 rollback，所以就算 SET TRANSACTION READ WRITE 生效了，後面也沒有第二句可以寫入。

這樣還有兩個缺口我自己也覺得不太妥。一是檢查只在建立連線時做一次，之後如果角色被加了權限，連線池裡已經通過檢查的連線還是會繼續被拿來用，直到閒置被清掉為止。二是它檢查的是角色成員身分，不是實際權限：如果有人直接 GRANT EXECUTE ON FUNCTION pg_read_file(text)，四項檢查（superuser 加三個角色）都會是 false，但它還是讀得到資料目錄和 log 目錄裡的檔案。

想請教一下：大家讓 BI 或 AI Agent 連 PostgreSQL 時，防線是設在交易、角色，還是兩邊都做？上面兩個缺口有沒有比較好的補法，例如每次取用連線時重新檢查，或改用 has_function_privilege 直接查？除了這三個，還有哪些不需要 superuser 也碰得到伺服器的路？

我們建議的角色設定寫在這裡：PostgreSQL 唯讀設計說明