部落格 發布於 AIA: 2026年4月18日

Bain Pyxis 平台被攻破：一組寫死在前端的密碼，讓攻擊者拿下 11 個資料庫加 Okta 的寫入權

這起事件其實很好懂：Pyxis 把一組真的能登入正式環境的 AI 服務帳號（service account）密碼，直接包進公開的前端 JS 檔裡。CodeWall 撿到這組密碼後，18 分鐘內就進到正式環境，接著再用會收原始 SQL 的 API 和平台上的 LLM 函式去查 11 個資料庫，最後還能透過另一條 GraphQL 路徑直接寫進 Bain 的 Okta 目錄。

這不是單純的資料外洩，而是同一把鑰匙同時打開了資料庫、對話紀錄、系統提示詞（system prompt）和身分系統。對防禦方來說，重點很簡單：AI 平台的服務帳號要用正式環境管理員的標準來管，密碼不能留在前端，權限不能一把抓，也不能讓它直接碰到 IdP 的寫入面。

Agentic AIIdentity & AccessData ExfiltrationEnterprise AI
5 項對應的 AIDEFEND 防禦手法
來源: How We Hacked Bain's Competitive Intelligence Platform 
作者 Paul Price (CodeWall) · 原文發布: 2026年4月13日

威脅分析

  • 第 1 步：先下載公開前端檔，直接撿到正式環境密碼。 Pyxis 的公開 JS bundle 裡寫死了一組真的能登入的 AI 服務帳號帳密。CodeWall 的自主 agent 下載 bundle、登入，18 分鐘就拿到正式環境 session。第一個失守點其實很單純：一組真正可用的密碼被放進任何人都能下載的前端檔案裡。
  • 第 2 步：接著發現，這組帳號幾乎什麼都看得到。 同一組服務帳號在 11 個資料庫都有讀寫權，還掛了上百個角色。它看得到消費交易資料、各客戶自己的 schema（資料庫內的資料分組）、AI 對話紀錄，甚至 Pyxis 的系統提示詞表。
  • 第 3 步：再把這個立足點變成直接查資料庫的能力。 Pyxis 有一個 API 端點會直接收原始 SQL，還會把資料庫錯誤訊息回給呼叫者；平台上的 LLM 函式也能直接去查正式環境資料表。對攻擊者來說，這代表拿到那組密碼後，AI 平台本身就變成資料庫的前門。
  • 第 4 步：最後從偷資料一路打到身分系統。 另一條 GraphQL 路徑允許同一個 session 直接建立帳號、改 Okta 目錄，而且不需要再過一次特權核准。攻擊者不只是在看資料，而是能把自己的長期存取寫進企業身分系統。
  • 為什麼這件事特別嚴重： 活動紀錄裡存了完整 JWT，匯出功能可以指定外送目的地，還有一個 API 能把整個資料庫複製出去。這不是單純的唯讀外洩，而是一條以單一高權限服務帳號為核心、同時具備竊取、竄改和持久化能力的完整攻擊鏈。

適用的 5 項 AIDEFEND 防禦手法

AID-H-004.002
Service & API Authentication
極高
整條攻擊鏈每一段都是 IAM 沒做好：一組 AI 服務帳號的密碼被打包在前端 bundle 裡，它在 11 個資料庫都有讀寫權、角色上百個，它的 JWT 效期 365 天又沒 MFA 而且整張存進活動紀錄，最後它的 session 還能呼叫一個可以改 Okta 目錄的 GraphQL 端點。AI 系統的 IAM 要做好：帳號密碼（尤其是特權帳號）絕對不能放在前端成品裡、服務帳號權限要按資產類別切分（不是按平台一把抓）、token 要短效期而且絕對不能把完整 JWT 寫進 log、AI 後端更不能直接觸及企業 IdP 的寫入面。
AID-H-019.002
Policy-Based Access Control
極高
Pyxis 讓 LLM 函式可以直接對正式環境資料表跑，8 個模型都能用——等於讓每一個 LLM 都變成一把鑰匙，能讀這組服務帳號能讀的所有資料；再加上平台上還有幾個高風險的 API——一個能把大量資料匯出到攻擊者指定的網址，另一個呼叫一次就能把整個資料庫完整複製一份。Policy-based 的存取控制意思是：模型要呼叫資料庫 API、匯出 API、或管理類 API 時，必須通過一層獨立的政策授權，依動作類型、資料類別、目的地分別評估；絕對不要有一個「對正式環境跑 SQL」的萬用工具在那邊。
AID-H-018.002
Least-Privilege Tool Architecture
高
Pyxis 在 AI 平台後面暴露了原始 SQL 和大量匯出這類高權限功能。把「什麼都能查」的資料庫工具，換成只針對已核准問題、schema 和匯出路徑的窄功能，可以在單一服務憑證外洩時縮小影響範圍。
AID-H-033.002
Cross-Tenant Serving-State Isolation
高
每個 Fortune 500 客戶各有自己的 schema，但都在同一個資料庫裡，而且都是同一組 AI 服務帳號可以存取。雖然有名義上的多租戶隔離，實際上卻沒有做好安全邊界。9,989 筆 AI 對話裡還包含各客戶員工寫的跨客戶競爭情報查詢，攻擊者只要拿下一組服務帳號，就能把這些全部讀到。真正的多租戶隔離是：每個客戶的資料背後要綁不同的身分、不同的 schema 邊界、不同的擷取策略，讓某個客戶發起的 LLM session 無論中間 agent 程式怎麼寫，都查不到另一個客戶的 schema。
AID-H-017
System Prompt Hardening
中
Pyxis 的系統提示詞有 18,621 個字元，內容包含整個平台的報告方法、SQL schema 定義、分析框架——而且任何通過驗證的呼叫者都能從對話 metadata 抓到它。這份提示詞同時是智財，也是偵察情報：裡面引用的 schema 名稱本身就是正式資料庫的藍圖。系統提示詞強化（System Prompt Hardening）的意思是：只透過受保護的內部管道把提示詞交給模型、絕對不能讓它出現在使用者可讀的回應或 metadata 裡，另外實施完整性控制（integrity controls，例如 hashing），讓被竄改過的版本不被系統使用。

身為資安防禦者，我們應該這麼做

  • 若發現攻擊的狀況，先輪換所有 AI 服務帳號的密碼，再盤點 git 歷史、前端 build 產物、config-as-code repo，把殘留的備份都清掉——我們要假設任何曾經可以被瀏覽器存取的資料都已外洩。
  • 把每個 AI 服務帳號的權限，依照最低權限原則（Least privilege principle），按資產類別給予其最小需要的權限。不要因為方便開發，就讓一組帳號橫跨整個 AI 資料層的讀寫。
  • 把 AI 平台的憑證和 IdP 的寫入路徑切開。AI 後端不該能自己動到 Okta、Azure AD、或 Google Workspace 的目錄。
  • 盤點平台對外暴露的每一個 LLM 函式和工具，按資料類別、動作類型、目的地分別控管。「對正式環境跑 SQL」的萬用工具、和可以讓攻擊者自選外送網址的大量匯出 API，一律停用。
  • 在前端 build 的上線關卡加上密碼掃描；把自主紅隊評估接進上線關卡和部署偏移檢查（比對正式環境實際狀態是否偏離核准的基線）。Bain 這組密碼在正式環境躺到連被動掃描都撿得到；而 Bain 過去的傳統 pentest 沒抓到這類問題。

2 個額外的防禦考量

前端打包產物的密碼偵測要列入上線關卡

除了上面 IAM 這些技術，跑 AI 平台的團隊還應該考慮一件事：每次前端 build 產出的成品，在推到正式 CDN 前都要先跑自動化的密碼掃描。Bain 這組被洩漏的密碼就坐在一份自主 agent 可以被動下載的 bundle 裡；任何一個跑過 bundle 的密碼掃描工具，都能抓到。
建議做法: 在前端 CI pipeline 接進 gitleaks / trufflehog 這類掃描器，一旦比對到高信心度的密碼就擋 build；再加上每週一次對已上線 bundle 的掃描，以及正式環境一發現外洩密碼就啟動的標準事件流程。

自主攻擊測試納入常規控制

CodeWall 的自主 agent 幾小時就串出整條攻擊鏈，傳統 scoped pentest 一個都沒抓到。跑 AI 平台的防禦方可以再加一層：用機器速度持續做紅隊評估，涵蓋驗證覆蓋率、SQLi、IdP 寫入路徑、LLM 工具面、以及密碼外洩。
建議做法: 把自主測試 agent 接進上線關卡和正式環境的偏移檢查——當成傳統 AppSec 之上的第二層，不要讓 checklist 式 pentest 成為你能抓到的上限。

結論

Bain Pyxis 這案說明，AI 平台最先失守的往往不是模型，而是模型背後那個身分。只要前端漏出去的不是一般帳號，而是能碰資料庫、提示詞、匯出功能和 Okta 的服務帳號，整個平台就會一起被打穿。AIDEFEND  在 IAM、工具授權、多租戶隔離、系統提示詞強化這幾塊都有直接對應；營運上的重點則是把 AI 平台的服務帳號，當成正式環境最關鍵的管理員帳號來切權限、做稽核、做監控。