AI構建的SaaS在第一位付費使用者前我審計的內容
本文作者基於自己用AI構建SaaS的經驗，指出AI生成程式碼在規模生產中的關鍵問題：缺乏機械性的拒絕表面。作者建議在SaaS上線前審計七項關鍵安全與可靠性措施，包括：邊界授權（而非處理器內部）、資料庫層深度防禦、AI呼叫的評估而非單元測試、每租戶成本歸屬、提示注入的爆炸半徑、API金鑰安全和可觀測性。文章強調，這些結構性防禦比行為性提醒更有效。
本文以一個警示故事開篇：一個AI構建的MVP上線生產環境，兩週內便有客戶讀取了其他客戶的資料。原因是模型在十四個處理器中漏掉了一個租戶隔離檢查。程式碼看起來完全相同，測試全部透過，但程式碼庫中沒有東西從機械層面上拒絕了這個錯誤。這揭示了核心問題：AI生成的程式碼缺乏“拒絕表面”——即程式碼本身機械地拒絕無效輸入或狀態的邊界。
作者使用Cursor和Claude Code在九個月內獨立構建了多租戶SaaS Allset，基於此經驗，他提出了在迎來第一位付費客戶前需要審計的七個領域：
- 邊界授權，而非處理器內部授權：不應依賴每個處理器內部的執行時檢查（模型可能遺忘），而應將授權變為型別。例如，
TenantAccess值只能由一個邊界函式構造，該函式執行資料庫查詢。跳過此檢查的程式碼無法編譯。Allset使用SpiceDB強制執行此規則。
- 資料庫層的深度防禦：即使有了型別化邊界，仍需第二道鎖。使用資料庫級別的強制措施，如PostgreSQL的行級安全（RLS）或DynamoDB的IAM條件。應用程式在連線邊界設定租戶ID的會話變數，資料庫獨立拒絕不匹配的行。Allset在每個租戶作用域的表上使用Aurora Postgres的RLS策略。
- 使用評估（evals）而非單元測試來測試AI呼叫：單元測試不適合隨機性的AI輸出。應使用評估——輸入資料集配以評分函式，在CI中執行。從20個評估開始，每次使用者報告模型出錯時增加一個。這種基礎設施提供真正的信心，而快照固定（snapshot-pinning）每次模型更新都會失效。
- 每個模型呼叫的按租戶成本歸屬：為每次模型呼叫打上租戶ID、模型和用途的標籤。一個簡單的儀表盤就能顯示每個租戶的每日成本。這在第一天只需五分鐘，但事後重構需要一週。沒有它，就無法明智定價或檢測失控迴圈。
- 提示注入的爆炸半徑：不要試圖完全阻止注入（不可能），而應限制代理工具在當前租戶上下文中的作用域。例如，
db_query工具應使用租戶作用域的憑證。跨越租戶邊界的工具應結構上無法從單租戶代理上下文中呼叫。
- API金鑰安全：使用臨時、作用域限定的金鑰，而不是長期金鑰。這限制了金鑰洩露時的損害。
- 可觀測性：實現指標、日誌和追蹤，特別是針對安全和成本異常。這確保你能快速檢測並響應問題。
作者強調，這些結構性防禦遠比行為性提醒（如“在CLAUDE.md中驗證租戶訪問”）有效。程式碼本身必須機械地拒絕錯誤行為。從一開始就構建這種拒絕表面，對任何追求生產可靠性的AI構建SaaS都至關重要。