03 / 安全與部署
安全與合規
GembaOS 是企業 AI Agent 的治理執行平台：以政策判定權限、以綁定參數的單次放行令授權每一個動作、以可追責的簽署鏈記錄人的審批，部署於企業本地機房或私有 VPC。我們提供設計與測試證據，評估由貴司及其審計師作出。
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 杜絕「先把整筆資料庫記錄或整批文檔餵給模型、再靠提示詞要求模型保密」的樂觀做法，在資料進入模型上下文之前完成邊界收窄。
- 欄位級裁剪（Field-Level Pruning）：未經授權的欄位（如信用卡號、身分證號、薪酬或內部評級）在閘道直接物理剔除，不流入提示詞；Agent 只接收其角色宣告所需的白名單欄位。
- 杜絕跨客戶讀取：資料庫存取只允許參數化程序或限定欄位的唯讀檢視，嚴禁自由拼接 SQL；查詢必須帶入當前工單所屬的客戶或租戶識別子，Agent 無法橫向探測或枚舉其他客戶的資料。
- 防嗅探的知識庫邊界：搜尋公司文檔時，Agent 只能檢索已審核發布的正式版本，草稿與未授權文檔一概不入索引；無權存取的機密文檔一律回覆「文檔不存在」，與真正不存在時完全一致，杜絕模型透過反覆嘗試進行嗅探。
- 代行授權上限：Agent 代表員工行事時，有效資料存取權限是「Agent 角色權限」與「當前登入員工本人權限」的交集。員工無權查閱的機密資料，Agent 絕不能代為讀取。
- 被拒絕的讀取同樣留痕：任何越權讀取嘗試均被閘道攔截並記錄在案，異常的高頻查詢直接觸發工單風險標記並通知管理員。
已批准的動作如何防止被篡改？
GembaOS 把每張放行令綁定到已批准參數的雜湊值（argsHash），只簽發一次，並設有效期。參數不同的呼叫與放行令不符，會被拒絕；執行已批准的呼叫會消耗放行令，第二次嘗試同樣被拒。執行之前，治理內核重新讀取 playbook 指定的前提條件，與審批單上的事實比對；簽章後世界若已改變，申請退回申請人，而不是放行。簽章後更改的訂單，就是一宗新的申請。
GembaOS 如何看待 Prompt Injection？
GembaOS 把外部內容視為資料，絕不視為授權。電郵、聊天訊息、日誌行、文件或圖片內嵌的指令都不能授予任何能力，因為允許動作的決定由模型以外的政策作出。
- 疑似注入的內容會在工單上標記為可疑輸入；帶標記的動作不論 Agent 提議甚麼，都會交由人手處理。
- 寫在 playbook 內的升級規則由治理內核強制執行，不交給模型判斷。
- 附件與圖片同樣是資料：圖片只在 playbook 允許時才送到模型，而模型對它的輸出仍然是資料。
- 已記錄的紅隊案例（Prompt Injection、參數篡改、越權提升、憑證外洩）在每次變更時作為測試重放。我們會與貴司安全團隊逐一走一遍。
人如何簽章？身份如何確認？
GembaOS 把人的簽章綁定到簽章者本人持有的通行密鑰（WebAuthn）。高風險路線可以規定必須使用硬件密鑰。員工透過貴司的身份供應商以 OIDC 登入；員工名錄由貴司自己的匯出檔案匯入，絕不憑空建立。本網站示範畫面以示範用的通行密鑰簽章；正式部署使用貴司員工自己的通行密鑰。代理人、上報對象與接管審批單的主管，同樣以自己的通行密鑰簽章，簽署鏈記錄代誰簽署。
審計記錄包含甚麼？可以驗證嗎？
GembaOS 把工單的每一項事件依次序以雜湊鏈記錄：Agent 回合、政策判定、能力呼叫、簽章、放行令與執行。政策重放以現行政策重跑已記錄的判定，得出相同的路線與規則鏈；審計回放頁面把它顯示出來。客戶收到的正式回覆與內部審批記錄分開保存。多租戶部署下，每個租戶有自己的執行平台與儲存。
哪些控制對應審計師使用的框架？
GembaOS 的機制可對應到審計師已在使用的控制項目；它不取代審計師的評估。
| 審計師會問的控制 | GembaOS 的機制 |
|---|---|
| 最小權限、按需存取 | 每個動作一張單次放行令；Agent 不持有長期憑證 |
| 職責分離、雙人覆核（Maker-Checker） | 路線保留人手步驟的簽署鏈；在員工權限內的代表執行 |
| 授權委派、缺席代理與離職 | 會簽、移交、上報、接管（每個都記錄理由，不會減少必需的簽章）；基於從員工名錄匯入的組織圖的缺席代理規則；離職時的權限交接 |
| 變更管理（CAB） | 在沙箱草擬的變更集，只經審批套用 |
| 日誌完整性與證據 | 雜湊鏈事件（任何改動在校驗鏈條時即會顯現）；綁定通行密鑰的簽章；按政策重新評估已記錄的判定。如需不可否認，另須貴司的 WORM 介質與證據保管制度 |
| 資料留存地（PDPO 保障資料原則第 4 原則：資料保安） | 貴司基建上的單一二進制檔案；每個 playbook 與租戶的送出上限 |
| 模型風險管理 | 模型變更進入生產前的影子重放與黃金測試 |
金管局於 2024 年 8 月就使用生成式 AI 的消費者保障發出通函，列出管治與問責、公平、透明及披露、資料私隱及保障四項原則；私隱專員公署於 2024 年 6 月發布《人工智能：個人資料保障模範框架》。上表的簽署鏈、審計回放與送出上限，是貴司回應「管治與問責」及「資料私隱及保障」時可以拿出的機制與證據；是否符合，仍由貴司的合規部門判斷。
我們會與貴司安全團隊檢視甚麼？
- 貴司部署的架構走查：網絡位置、TLS 或代理、身份供應商、Adapter。
- 威脅模型與紅隊案例，即場對執行平台重放。
- 試點首兩週之後，貴司工作流程的黃金測試。
- 上面的資料流向表，按貴司每個接入系統與模型逐一填寫。
- 部署清單：服務登記、TLS、反向代理、資料目錄備份。
相關：Design Partner 計劃、常見問題、詞彙表。
最後更新: · GembaOS v0.2