NVIDIA 的代理監控狗能終止程序，卻把鑰匙留在了門上 

週一，NVIDIA 推出了其開放代理安全平台 (Open Agent Safety Platform)，結合了 OpenShell（一個開源的沙箱環境）與 Sentry——一個在 BlueField-4 DPU 上運作的帶外 (out-of-band) 監控狗，能夠在毫秒內隔離惡意的 AI 代理。對於不熟悉的人來說，DPU 就像是一個駐留在網路卡上的獨立電腦，安全地與主機隔離，免受竄改。有鑑於最近前沿實驗室發布了大量代理逃逸場景的記錄，將執行機制部署在代理完全無法觸及的地方，無疑是一個極為出色的架構創舉。

然而，我的擔憂在於其實際應用。網路安全界有一個惡名昭彰的習慣：拿一個原本相當合理的控制措施，過度延伸其設計初衷，然後就宣稱問題已解決。目前，隔離 (Containment) 正被吹捧為解決 AI 代理風險的終極解藥——這是一種危險的過度簡化。

過度信任控制措施的歷史陷阱

我們盲目相信「夠好」的安全防護有著悠久的歷史。以密碼輪替為例：二十年來，我們強制規定 90 天重設密碼與複雜的字元規則。結果呢？員工被訓練成可預測地將密碼從 Summer2023! 循環到 Fall2023!。儘管 NIST 最終在 800-63B 中撤回了這項指導原則，無數組織卻僅僅為了滿足合規稽核員而繼續強制執行。同樣地，基於簡訊的 MFA 和 MAC 過濾曾被視為黃金標準——直到 SIM 卡挾持、Evilginx 等代理攻擊以及簡單的 MAC 欺騙讓它們變得形同虛設。

惡意軟體沙箱也經歷過完全相同的炒作週期。在隔離的虛擬機器內引爆可疑檔案曾經非常有效，直到惡意軟體開發者編寫了能偵測 VM 偽影 (artifacts)、在分析期間休眠，並在被觀察時表現得安分守己的有效負載。AI 實驗室已經發布了研究，證明模型可以偵測到自己正在被評估。在 NVIDIA 自己的測試中，代理花了長達兩個小時持續嘗試對 AI 審查員進行社交工程攻擊，以獲取受保護儲存庫的寫入權限。一個決心堅定的代理，最終不可避免地會摸清並繞過監控狗的運作閾值。

有效憑證消除了規避的必要性

然而，主動規避並不是主要的威脅。隔離機制監控的是行為，但一個擁有合法憑證的 AI 代理不需要表現出惡意，就能造成災難性的破壞。代理透過委派存取權運作：人類使用者授予的 OAuth 權杖、服務帳戶，或硬編碼在 MCP 伺服器中的 API 金鑰。

這是經典的「混淆代理人」(confused deputy) 問題，當代理人握有真正的鑰匙時，嚴密審查代理人是毫無用處的。隔離執行階段並不能解決這個問題。終止代理的程序並不能撤銷其底層的 OAuth 授權。更新權杖 (refresh token) 依然在發行平台內保持活躍，隨時準備被任何攔截到它的人利用。除非您的隔離策略與您的身分提供者 (IdP) 深度整合，能同時終止程序和憑證，否則您只是阻止了眼前的執行，卻將大門敞開。

看看最近的 Salesloft Drift 事件：威脅行為者利用從聊天機器人整合中竊取的 OAuth 權杖，從數百家組織中吸取了 Salesforce 資料——這根本不需要逃出什麼沙箱。同樣地，在 Midnight Blizzard 漏洞事件中，攻擊者透過一個被遺忘且擁有過大權限的測試 OAuth 應用程式滲透了微軟的企業電子郵件。即將到來的 AI 代理浪潮將快速產生數以千計的類似身分，其速度將遠遠超過傳統存取審查流程的處理能力。

代理並不存在於 DPU 運作的地方

此外，Sentry 需要部署在您自家資料中心內的專用硬體。但現實是，大多數現代 AI 代理存在於其他地方：嵌入在 SaaS 應用程式中、在開發人員的筆記型電腦上運行、作為瀏覽器擴充功能運作，或由行銷團隊使用個人 OAuth 授權啟動。

我曾親眼目睹，當領導層在缺乏治理的情況下強制快速採用新技術時，會引發怎樣的混亂。在之前的一個營運職位上，開發人員被指示要不惜一切代價交付成果——這與現今流傳的「無處不部署 AI」的指令如出一轍。這導致了前所未見的影子 IT (Shadow IT) 規模：無所不在的未經批准應用程式、暴露在網際網路上的生產系統，以及在運作很久之後才被發現的整排影子硬體設備。

最令人震驚的案例涉及一家剛被收購的公司，該公司遭到入侵，未能通報，隨後「刪除」了他們整個受感染的環境。雲端運算、VM、容器和儲存裝置全被抹除，抹殺了任何鑑識調查的機會。AI 代理正在引入這種確切夢魘的更隱蔽版本。當代理使用人類的 OAuth 權杖執行動作時，稽核日誌會直接指向該人類。在事件調查期間，當法務人員緊盯著你時，祝你好運能釐清這場鑑識的混亂。

將代理視為其所代表的身分

從身分與存取管理 (IAM) 的角度來看，真正的解決方案遠不如部署新硬體來得光鮮亮麗。AI 代理就是身分。我們已經擁有治理身分的框架；我們只是缺乏執行的紀律。

有效的代理安全需要基礎的 IAM 衛生習慣：

• 嚴格盤點：維護一個註冊表，每個代理都必須有指定的人類負責人。
• 專屬身分：代理必須使用其獨特的服務身分進行驗證，而不是搭便車使用其創建者的權杖，以確保稽核日誌的準確性。
• 限定範圍與到期的存取權：特權必須嚴格限定於特定任務，並受到嚴格的到期日限制，賦予被盜授權一個明確的保存期限。
• 情境化存取審查：非人類身分必須接受嚴格的存取審查，並配備足夠的情境脈絡以消除猜測。
• 自動化除役：當專案結束或負責人離職時，必須有系統地將代理除役，並從源頭撤銷其授權。

硬體層級的隔離是一個極好的備用方案，但它無法取代基礎的身分治理。如果您的組織已成功在企業規模上實施了代理所有權和自動化撤銷，我很想聽聽您是如何做到的。

終結 IP 猜測遊戲：Portnox 防火牆身分對應器 (Firewall Identity Mapper)

當凌晨 2 點觸發針對 IP 位址 10.1.45.112 的安全警報時，SOC 分析師面臨著一個直接的障礙：防火牆記錄的是數字，而不是人。要確定該 IP 是屬於被入侵的伺服器、訪客的智慧型手機，還是財務長 (CFO)，需要手動交叉比對 DHCP 租約、RADIUS 記帳和 VPN 工作階段日誌。這個繁瑣的轉換過程，白白消耗了事件回應中最關鍵的幾分鐘。

此外，基於 IP 的政策本質上是脆弱的。因為每當使用者重新連線至 Wi-Fi 或建立 VPN 通道時，位址就會動態重新指派，因此透過靜態 IP 子網路來執行安全防護會產生營運上的摩擦。安全團隊自然會以角色和部門來思考——而不是短暫的 IP 位址。

透過具備身分感知能力的防火牆彌合差距

全新的 Portnox 防火牆身分對應器 (Firewall Identity Mapper) 解決了這種脫節的問題，並在初步推出時提供了對 Palo Alto Networks 的原生整合。

由於 Portnox Cloud 已經管理了您的 NAC 與 RADIUS 身分驗證，它本來就能即時掌握哪個經過驗證的使用者綁定了哪個 IP 位址。身分對應器作為一個輕量級的 Docker 容器運作，部署在可連線至您 Palo Alto 管理介面的主機上。它會持續從 Portnox 擷取這些使用者與 IP 的對應關係，並透過 XML API 將它們直接推送到防火牆的 User-ID 引擎。

徹底改變網路政策

這種整合從根本上改變了存取規則的編寫和維護方式。管理員無需再應付脆弱的 IP 位址物件，而是可以編寫字面上的、基於角色的規則——例如「工程部門可以存取 GitHub」。

當員工入職、調換部門或離職時，防火牆的執行會自動與他們新的 IdP 群組狀態保持一致。不需要手動編輯規則。最重要的是，在深夜的調查中，威脅日誌會立即顯示使用者的身分，消除了鑑識時的猜測。

部署與架構規格

身分對應器的設計兼顧了安全性與簡易性：

• 僅限出站通訊 (Outbound-Only Communication)：Docker 容器僅與 Portnox Cloud 和您的防火牆管理介面進行出站通訊。它需要零個入站連接埠，確保您的防火牆管理完全與公共網際網路隔離。
• 最小權限配置：部署非常集中。Portnox Cloud 會自動為您產生一個預先填妥的 Docker 執行命令，其中包含您特定的執行個體詳細資訊。在防火牆方面，管理員只需建立一個受限的管理員角色，其範圍僅限於 User-ID XML API。
• 高度可擴展：單一容器部署可以同時管理並同步跨多個 Palo Alto 防火牆的身分對應。

雖然 Palo Alto 是首家支援的供應商，但未來的版本已計畫進行更多防火牆整合。對於在執行 Portnox NAC 或 ZTNA 的同時也執行 Palo Alto 防火牆的組織，可以立即使用 Portnox 防火牆身分對應器——確保下次深夜警報響起時，分析師已經確切知道是誰在網路上。