安全優先設計

Triggerfish 建立在一個前提之上：LLM 沒有任何權限。它請求行動；策略層決定。每個安全決策都由 AI 無法繞過、覆寫或影響的確定性程式碼做出。

本頁解釋 Triggerfish 為何採取這種方法、它與傳統 AI 代理平台的區別，以及在哪裡找到安全模型每個組件的詳情。

為什麼安全必須在 LLM 之下

大型語言模型可以被提示注入。精心製作的輸入——無論是來自惡意的外部訊息、被汙染的文件，還是被入侵的工具回應——都可能導致 LLM 忽略其指示並採取被告知不應採取的行動。這不是理論風險。它是 AI 產業中記錄完善、尚未解決的問題。

如果您的安全模型依賴 LLM 遵守規則，一次成功的注入就能繞過您建立的所有防護。

Triggerfish 透過將所有安全執行移到位於 LLM 之下的程式碼層來解決這個問題。AI 永遠看不到安全決策。它永遠不會評估某個行動是否應該被允許。它只是請求行動，而策略執行層——作為純粹的確定性程式碼執行——決定這些行動是否繼續。

安全性 LLM 層沒有覆寫、跳過或影響策略執行層的機制。沒有「解析 LLM 輸出中的繞過指令」邏輯。這個分離是架構性的，不是行為性的。 :::

Triggerfish 中的每個設計決策都源自一個不變量：

相同輸入始終產生相同的安全決策。無隨機性、無 LLM 呼叫、無自由裁量。

這表示安全行為是：

原則	含義	詳情頁面
資料分類	所有資料攜帶敏感度等級（RESTRICTED、CONFIDENTIAL、INTERNAL、PUBLIC）。分類在資料進入系統時由程式碼分配。	架構：分類
禁止降級寫入	資料只能流向相同或更高分類等級的通道和收件者。CONFIDENTIAL 資料無法到達 PUBLIC 通道。沒有例外。	禁止降級寫入規則
工作階段 Taint	當工作階段存取某個分類等級的資料時，整個工作階段被汙染到該等級。Taint 只能提升，永不降低。	架構：Taint
確定性 Hook	八個執行 hook 在每個資料流的關鍵點執行。每個 hook 是同步的、有記錄的、不可偽造的。	架構：策略引擎
程式碼中的身分	使用者身分在工作階段建立時由程式碼確定，而非由 LLM 解讀訊息內容。	身分與驗證
代理委派	代理間呼叫由加密憑證、分類上限和深度限制管治。	代理委派
密鑰隔離	憑證儲存在作業系統金鑰鏈或保險庫中，永遠不在設定檔中。Plugin 無法存取系統憑證。	密鑰管理
稽核一切	每個策略決策都以完整上下文記錄：時間戳記、hook 類型、工作階段 ID、輸入、結果和評估的規則。	稽核與合規

大多數 AI 代理平台依賴 LLM 來執行安全。系統提示說「不要分享敏感資料」，然後信任代理會遵守。這種方法有根本性的弱點。

Triggerfish 不聲稱 LLM 不可靠。它聲稱 LLM 是安全執行的錯誤層級。精心提示的 LLM 在大多數時候會遵循其指示。但「大多數時候」不是安全保證。Triggerfish 提供保證：策略層是程式碼，程式碼每次都做被告知的事情。 :::

Triggerfish 實作十三層防禦。沒有單一層是單獨足夠的；它們一起形成安全邊界：