實證研究發布於 AIA: 2026年4月18日

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

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

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

Credential TheftData ExfiltrationIdentity & AccessEnterprise AIAgentic AI

4 項對應的 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 能把整個資料庫複製出去。這不是單純的唯讀外洩，而是一條以單一高權限服務帳號為核心、同時具備竊取、竄改和持久化能力的完整攻擊鏈。

適用的 4 項 AIDEFEND 防禦手法

AID-H-004.002

Service & API Authentication

極高

所有後端、資料庫與 GraphQL 呼叫都必須提出可驗證的 machine identity，並核對 issuer、audience、route binding 與憑證新鮮度；服務帳號密碼不能打包進前端 bundle，也不能把完整 JWT 寫進 log。這項控制只證明呼叫者身分；該身分能否讀資料庫或修改 Okta 目錄，另由 AID-H-018.002 決定。

AID-H-018.002

Policy-Based Access Control

極高

Pyxis 讓 LLM 函式可以直接對正式環境資料表跑，8 個模型都能用 - - 等於讓每一個 LLM 都變成一把鑰匙，能讀這組服務帳號能讀的所有資料；再加上平台上還有幾個高風險的 API - - 一個能把大量資料匯出到攻擊者指定的網址，另一個呼叫一次就能把整個資料庫完整複製一份。Policy-based 的存取控制意思是：模型要呼叫資料庫 API、匯出 API、或管理類 API 時，必須通過一層獨立的政策授權，依動作類型、資料類別、目的地分別評估；絕對不要有一個「對正式環境跑 SQL」的萬用工具在那邊。

AID-H-017.002

Least-Privilege Tool Architecture

高

Pyxis 在 AI 平台後面暴露了原始 SQL 和大量匯出這類高權限功能。把「什麼都能查」的資料庫工具，換成只針對已核准問題、schema 和匯出路徑的窄功能，可以在單一服務憑證外洩時縮小影響範圍。

AID-H-016.001

System Prompt Structure & Instruction/Data Separation

中

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 平台的服務帳號，當成正式環境最關鍵的管理員帳號來切權限、做稽核、做監控。