安全與合規 · GembaOS

GembaOS 是企業 AI Agent 的治理執行平台：以政策判定權限、以綁定參數的單次放行令授權每一個動作、以可追責的簽署鏈記錄人的審批，部署於企業本地機房或私有 VPC。本頁只寫截至 2026 年 9 月（v0.2）的事實，不寫未取得的認證：截至該日，GembaOS 未取得 SOC 2、ISO 27001 或同類第三方認證。我們提供設計與測試證據，評估由貴司及其審計師作出。

GembaOS 在哪裡運行？甚麼會離開我們的網絡？

GembaOS 以一個附有自己資料目錄的 Linux 單一二進制檔案，運行於貴司控制的基建上，本地機房或私有 VPC 皆可。除非貴司配置了對外路徑，否則沒有任何東西離開該網絡。

組件	運行位置	離開貴司網絡的內容
執行平台、政策引擎、能力閘道	貴司伺服器	無
審批人與操作員使用的控制台	同一個二進制檔案；以自有證書提供 TLS，或置於貴司反向代理之後	無
模型	自託管，或貴司選擇的雲端供應商	自託管：無。雲端：只限 playbook 允許的提示內容，並受下述上限約束
業務系統	由貴司網絡內呼叫的 Adapter：REST、檔案、SQL，或以雙向 TLS 連接的 worker	經批准的那一次呼叫
渠道（電郵、Teams、Slack、電話、網頁小工具）	以貴司自己的憑證配置的連接	該渠道的訊息內容

「送出上限」是每個租戶、每個 playbook 的一項聲明：哪一類模型供應商（自託管、私有雲、公共 SaaS）可以接收哪一級資料分類。無論 Agent 屬於甚麼角色，playbook 都不能送出高於上限的資料。自託管模型與 SaaS 模型因此按資料敏感度混用，而不是按部門劃分。

Agent 不持有憑證，如何執行動作？

GembaOS 把業務系統的憑證留在能力閘道，不放進任何提示詞。Agent 只看到能力名稱與參數結構；每一次呼叫都按同一次序經過閘道。

步驟	誰	核對甚麼
1. 申請	以指定員工名義行事的 Agent	能力存在，參數符合其結構
2. 政策	主機	授權表、路線、前提條件、工單上的風險標記
3. 簽章	受委託的核查由 Agent 簽；路線要求之處由持通行密鑰的人簽	所顯示的審批單本身：事實、參數、理由
4. 放行令	主機	綁定已批准參數雜湊值的單次放行令
5. 執行	主機與 Adapter	重新讀取前提條件，與審批人所見比對；有變則退回申請而不執行
6. 記錄	主機	工單上的雜湊鏈事件

讀取同樣經過閘道，按欄位級規則進行：Agent 只看到其角色可見的欄位，而被拒絕的讀取本身也是一項記錄在案的事實。

已批准的動作如何防止被篡改？

GembaOS 把每張放行令綁定到已批准參數的雜湊值（argsHash），只簽發一次，並設有效期。參數不同的呼叫與放行令不符，會被拒絕；執行已批准的呼叫會消耗放行令，第二次嘗試同樣被拒。執行之前，主機重新讀取 playbook 指定的前提條件，與審批單上的事實比對；簽章後世界若已改變，申請退回申請人，而不是放行。簽章後更改的訂單，就是一宗新的申請。

GembaOS 如何看待 Prompt Injection？

GembaOS 把外部內容視為資料，絕不視為授權。電郵、聊天訊息、日誌行、文件或圖片內嵌的指令都不能授予任何能力，因為允許動作的決定由模型以外的政策作出。

疑似注入的內容會在工單上記為一項具類型的關注事項。主機把它變成風險標記；帶標記的動作不論 Agent 提議甚麼，都會交由人手處理。
寫在 playbook 內的升級規則由主機強制執行，不交給模型判斷。
圖片在接收時重新編碼；像素只在邊緣階段、且只在 playbook 與模型設定同時允許時才送到模型，而模型的輸出仍然是資料。
已記錄的紅隊案例（Prompt Injection、參數篡改、越權提升、憑證外洩）在每次變更時作為測試重放。我們會與貴司安全團隊逐一走一遍。

人如何簽章？身份如何確認？

GembaOS 把人的簽章綁定到簽章者本人持有的通行密鑰（WebAuthn）。租戶的簽章政策可以要求高風險路線使用硬件密鑰等級。員工透過貴司的身份供應商以 OIDC 登入；員工名錄由貴司自己的匯出檔案匯入，絕不憑空建立。本網站示範畫面中的模擬通行密鑰，在公開部署姿態下會被拒絕。

審計記錄包含甚麼？可以驗證嗎？

GembaOS 把工單的每一項事件依次序以雜湊鏈記錄：Agent 回合、政策判定、能力呼叫、簽章、放行令與執行。政策重放以現行政策重跑已記錄的判定，得出相同的路線與規則鏈；審計回放頁面把它顯示出來。客戶收到的正式回覆與內部審批記錄分開保存。多租戶部署下，每個租戶有自己的執行平台與儲存，每一次讀取都限於發出請求的工作階段。

哪些控制對應審計師使用的框架？

GembaOS 的機制可對應到審計師已在使用的控制項目；它不取代審計師的評估。

審計師會問的控制	GembaOS 的機制
最小權限、按需存取	每個動作一張單次放行令；Agent 不持有長期憑證
職責分離、雙人覆核（Maker-Checker）	路線保留人手步驟的簽署鏈；在員工權限內的代表執行
變更管理（CAB）	在沙箱草擬的變更集，只經審批套用
日誌完整性與不可否認	雜湊鏈事件；綁定通行密鑰的簽章；確定性重放
資料留存地（PDPO 保障資料原則第 4 原則：資料保安）	貴司基建上的單一二進制檔案；每個 playbook 與租戶的送出上限
模型風險管理	模型變更進入生產前的影子重放與黃金測試

金管局於 2024 年 8 月就使用生成式 AI 的消費者保障發出通函，列出管治與問責、公平、透明及披露、資料私隱及保障四項原則；私隱專員公署於 2024 年 6 月發布《人工智能：個人資料保障模範框架》。上表的簽署鏈、審計回放與送出上限，是貴司回應「管治與問責」及「資料私隱及保障」時可以拿出的機制與證據；是否符合，仍由貴司的合規部門判斷。

我們會與貴司安全團隊檢視甚麼？

貴司部署的架構走查：網絡位置、TLS 或代理、身份供應商、Adapter。
威脅模型與紅隊案例，即場對執行平台重放。
試點首兩週之後，貴司工作流程的黃金測試。
上面的資料流向表，按貴司每個接入系統與模型逐一填寫。
部署清單：systemd 服務、TLS、HSTS、代理之後的標頭、資料目錄備份。

相關：Design Partner 計劃、常見問題、詞彙表。