這起事件真正值得注意的，不是有人用 Rust 重寫了一套 PostgreSQL MCP Server，而是一個已被棄用、直接持有資料庫連線能力的橋接元件，仍被大量下載。當企業開始讓 AI 代理查詢營運資料，這類看似只是「開發工具」的套件，實際上已進入資料存取與權限控管的核心。
棄用不等於停止使用
原始文章指出，@modelcontextprotocol/server-postgres 最後一次發版是在 2024 年 12 月，且截至 2026 年 8 月 9 日的三十天內仍有 475,790 次下載。這項特定區間數字來自作者，無法由靜態頁面完整重現；不過 npm 頁面確實將套件標示為不再支援，查證時顯示每週下載量仍達 126,780 次，足以交叉證明它並非乏人問津的舊專案。原文：https://dev.to/eszetael/rebuilding-the-deprecated-postgresql-mcp-server-in-rust-safe-by-default-1eb；npm：https://www.npmjs.com/package/%40modelcontextprotocol/server-postgres?activeTab=versions
必須避免把下載次數直接換算成企業數或正式環境數量：CI 重建、快取失效及重複安裝都會放大數字。但「棄用警告沒有使下載歸零」仍是可確認的事實，代表舊教學、既有設定與自動化流程可能持續把它帶進新環境。
真正的安全邊界在資料庫，不在套件名稱
MCP Server 位於模型與 PostgreSQL 之間：模型產生查詢，伺服器拿著資料庫憑證執行，再把結果送回模型上下文。其風險至少包含三類：查詢造成資料或系統狀態改變、昂貴查詢拖垮資源，以及資料列內的文字被模型誤當成指令。
原文聲稱舊版另以 startsWith("SELECT") 做字串檢查，但封存倉庫目前可查到的 v0.6.2 原始碼並沒有這一層：程式直接執行呼叫端提供的 SQL，只先開啟 BEGIN TRANSACTION READ ONLY，最後再 ROLLBACK。因此，原文對「字串守門」的描述不應視為已證實事實；可確認的問題反而是安全性幾乎全押在 PostgreSQL 的唯讀交易。原始碼：https://raw.githubusercontent.com/modelcontextprotocol/servers-archived/main/src/postgres/index.ts
這道防線不是毫無作用。一般的 INSERT、UPDATE、DELETE、DDL 與多數破壞性敘述會被 PostgreSQL 阻擋。然而官方文件也明確說明，這只是「高階概念上的唯讀」，不保證阻止所有磁碟寫入；序列的 nextval 或 setval 變化也可能不因交易回滾而復原。這足以支持「不能只依賴 rollback」的核心論點，但原文所列特定管理函式及 874 筆異動仍屬作者測試結果，尚非獨立稽核結論。官方文件：https://www.postgresql.org/docs/current/sql-set-transaction.html、https://www.postgresql.org/docs/current/functions-sequence.html
Rust 重建版賣的不是效能，而是縱深防禦
新專案 postgres-mcp-hardened 的商業與工程邏輯，是假設每一層都可能失效：先把 SQL 解析成語法樹，只允許限定的查詢結構；再由資料庫設定唯讀、低權限角色與回滾；用 statement_timeout 限制執行時間，並以 EXPLAIN 成本預估攔截過重計畫。結果資料則標示為不可信內容並跳脫分隔符，網路部署可加 OAuth，所有工具決策寫入雜湊串接的稽核紀錄。
這些機制與測試、模糊測試語料、SBOM、簽章發布等資料可在專案倉庫看到：https://github.com/Eszetael/postgres-mcp-hardened。但它們目前主要仍是維護者提出並自行驗證的安全主張，不等同第三方滲透測試或成熟產品認證。
為何現在值得注意
傳統資料庫工具通常由人輸入 SQL；代理式系統則可能自動組合工具呼叫、讀取資料後繼續採取行動。這使資料列本身也可能成為間接提示注入來源。MCP 官方安全指南同樣要求最小權限、隔離本機伺服器，並提醒本機 MCP 程序可能繼承客戶端權限：https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices
作者觀點是：棄用套件的問題不只在「未來不會修補」，還在企業可能從未把它列入正式資產。套件若藏在個人 IDE、桌面 AI 工具或專案設定檔中，資安與 DBA 團隊甚至不知道多了一條通往資料庫的路。
容易忽略的限制
- 重寫不會自動消除供應鏈風險，只是把信任移交給另一位維護者、另一組依賴與發布流程。
- 語法樹允許清單與管理函式拒絕清單都可能有缺口；PostgreSQL 方言與擴充功能也會持續演進。
EXPLAIN成本只是估計，低估的查詢仍需靠逾時、併發限制和資料庫資源治理收尾。- 將工具輸出標成不可信內容只是訊號；若 MCP 客戶端把標記攤平成普通文字，提示注入防線仍可能失效。
- 專案仍在 0.1.x 階段，維護者也坦承外部實際資料驗證有限，不宜因「Rust」或測試數量就直接認定可上正式環境。
對台灣團隊的實際意義
台灣企業不必先決定要不要採用這個 Rust 版本；更急迫的是把 MCP 納入既有資料庫治理。盤點 IDE、桌面代理、容器映像與 CI 設定中的 MCP 套件；停用棄用版本；為代理建立獨立、不可寫且不得持有超級使用者或 BYPASSRLS 的角色；限制可讀 schema、資料表與敏感欄位；設定查詢逾時、列數、併發及網路邊界；正式替換前以真實查詢樣本做壓力與對抗測試。
尤其金融、電商、製造與 SaaS 團隊，應把「唯讀」拆成三個問題：能否改變狀態、能讀到哪些資料、讀取行為是否可追溯。唯讀交易主要回答第一題，不能取代欄位授權、資料遮罩與稽核。
後續觀察指標
- 棄用套件的每週下載量是否下降，以及舊教學與範例是否完成替換。
- Rust 重建版是否出現獨立安全稽核、外部部署案例與可重現漏洞報告。
- 對抗測試語料是否持續擴充，曾經放行的 SQL 是否永久加入回歸測試。
- 提示注入標記能否被主流 MCP 客戶端保留，而非降格成普通文字。
- 企業能否用資料庫端紀錄證明代理始終使用最小權限角色，而不是只相信 MCP Server 自稱「safe by default」。