產品 · 控制與安全 層
FinGuard
動作網關
AI 代理出錯的方式往往很普通：逾時後重複寫入，一次重試演變成重試風暴，長任務忘了自己已做過甚麼。每一次都落在記錄系統上。FinGuard 位於 AI 代理和企業系統之間，決定每一個具體動作此刻是否應該發生。AI 代理從不持有真實憑證。每次寫入都記入日誌，重複請求直接返回已儲存的結果，而不會寫入兩次。
在技術堆疊中的位置
FinAI OS 的動作網關
FinGuard 治理的是動作：AI 代理的一次調用變成 CRM、ERP、工單系統或內部 API 中一處變更的那一刻。它可前置 REST、SOAP、JSON-RPC 和 MCP，只需配合 PostgreSQL 即可獨立部署。其他網關判斷的是提示詞是否安全、工具能否存取；FinGuard 判斷的是這一次寫入此刻是否應該發生，以及是否已經發生過。FinGuard 與 FinSAFE 互不構成建置依賴：FinGuard 治理動作，FinSAFE 約束執行動作的進程。要令 FinGuard 成為每個動作的必經之路，就由它持有你的系統認可的憑證，並以 FinSAFE 的網絡白名單令 FinGuard 成為 AI 代理唯一能連接的系統。FinAI OS 把伺服器端 AI 代理、桌面端 AI 代理和技能直接接入 FinGuard。
可單獨購買，亦可與其他 FinAI OS 產品整合。
- Hermes
- Codex
- dsh
- pi-agent
- 等
能力
FinGuard 做什麼
AI 代理與記錄系統之間的五道控制。它們適用於你已在運行的 AI 代理，毋須修改 AI 代理程式碼。
- 1
寫入操作只執行一次
冪等台賬記錄每一次寫入。帶同一個鍵的重複請求會取回已儲存的回應，而不會產生第二次寫入。逾時的嘗試會先核實，再決定是否重試。
- 2
AI 代理從不持有的憑證
企業憑證經過輪換，FinGuard 成為唯一持有者。AI 代理獲得的是 FinGuard 範圍內的身份，只有當動作獲准時，FinGuard 才從你的密鑰庫注入真實密鑰。繞過 FinGuard 的 AI 代理，手上沒有任何目標系統會認可的東西。
- 3
高風險動作的試行與人工審批
高風險動作可以先試行並作風險檢查，作為待處理動作擱置，直至有人透過 FinGuard 的審批 API 批准或拒絕。AI 代理不能批准自己的請求。
- 4
重試預算與熔斷
每個動作都有重試預算，目標系統持續出錯會觸發熔斷，一個有問題的依賴不會把 AI 代理變成重試風暴。
- 5
防篡改的審計記錄
哈希鏈日誌覆蓋每一次放行和拒絕，內置的校驗功能可以顯示當中是否有內容在事後被改動。
獨立使用 · 組合更強
單獨可用。納入技術堆疊更強。
FinGuard 的設計就是可以率先部署，放在你已在運行的 AI 代理前面。為它編寫的策略和日誌，在加入其他 FinAI OS 產品後照樣可用，毋須改動。
單獨使用 FinGuard
單獨使用 FinGuard：為你已在運行的 AI 代理設置動作網關
- 不需要其他 FinAI OS 產品
- 毋須修改 AI 代理程式碼
- 可前置 REST、SOAP、JSON-RPC 和 MCP
- 接入你的身份提供者（OIDC JWT）和密鑰庫
- 雲原生容器，部署於貴機構自有數據中心或私有雲，只需另配 PostgreSQL
與以下組合
把你的系統認可的憑證交給 FinGuard，平台上的 AI 代理就只有一條路通往這些系統。平台把其 AI 代理及其安裝的技能直接接入 FinGuard。
FinDesk 的桌面端 AI 代理經由與伺服器端 AI 代理相同的 FinGuard 網關存取貴機構的企業系統。
FinGuard 決定一個動作是否應該發生；FinSAFE 約束它如何運行。你可以設定 FinSAFE 的網絡白名單，令 FinGuard 成為 AI 代理唯一能連接的地方。
在財富解決方案中
FinGuard 在個人財富 AI 代理方案中
動作範圍、超出策略的動作由持牌顧問審批，以及哈希鏈審計記錄。適當性由貴機構自己的模型和規則判斷，而非由 FinGuard 判斷。
客戶應用與 持牌顧問控制台見解決方案頁。
- 步驟 1
評估
把 FinGuard 部署在你的第一個記錄系統前面，在審計記錄中查看 AI 代理發送了甚麼，並在正式執行前，以已記錄的流量回放策略變更。
- 步驟 2
打好基礎
接入你的身份提供者和密鑰庫，輪換第一個服務憑證，接入第一個系統。
- 步驟 3
交接
開啟審批和策略，校驗審計記錄，交接營運手冊。