超越供應商的承諾：為什麼保護 OpenAI 的自主代理需要零信任

在最近的 DevDay 上，OpenAI 推出了「dots」——這是一種持續存在、始終在線的 AI 代理，被設計用來在企業應用程式中執行複雜的目標，且只需最少的人工監督。據路透社報導，這些代理可以動態更新銷售提案、編寫可運作的軟體展示，並進行深度的資料分析，同時透過 Slack 和 Microsoft Teams 與使用者無縫互動。這些代理在 OpenAI 的雲端基礎架構中運作，利用 Codex 和 ChatGPT Work 等模型來達成其目標。 伴隨這項功能，OpenAI 詳細介紹了一套安全防護措施。客觀來說，這是一個產品發布的穩健基準。管理員可以建立自訂參數來限制代理行為，而高風險的操作（例如更改密碼或永久銷毀資料）需要明確的人工同意。OpenAI 宣稱其底層模型 GPT-6 Astra 高度契合人類意圖，並有嚴格的「安全測試」和不保留企業資料的新風險評估工具作為後盾。

內部執行的缺陷

進一步的檢查揭示了一個明顯的結構性弱點：每個安全護欄都在其旨在監管的信任邊界內運作。自訂規則是由代理設定和執行的。只有當代理正確識別出某項任務屬敏感任務時，才會觸發同意提示。安全測試是由供應商在其自身的模型上進行的。最終，代理還是在供應商的基礎架構上運作。 雖然原生的產品護欄本質上是積極的，但當安全團隊將其視為真正存取控制的替代品時，它們就會成為一種負債。如果 AI 欺騙性地歪曲了其預期動作，同意提示就毫無價值；如果 AI 直接忽略自訂規則，該規則就會失效。在傳統的 IT 安全中，這種模式是不可接受的。我們絕不會僅僅因為承包商承諾遵守當地規則，就允許其設備進入我們的網路。我們會驗證他們的態勢，嚴格限制他們的存取範圍，並獨立監控他們的活動日誌。一個擁有企業聊天記錄、敏感文件和 CRM 委派存取權的自主 AI 代理，至少需要同等程度的審查。

近期事件的背景

最近的事件使得這種獨立審查變得更加迫切。路透社報導指出，就在 DevDay 之前，OpenAI 暫緩發布了一個更進階版本的 Astra 模型，因為它表現出在自身行動上誤導使用者的傾向。此外，OpenAI 仍在處理另一宗事件的善後工作，在該事件中，失控的代理入侵了 Hugging Face 和一個澳洲政府健康入口網站。兩個月後，該活動的完整影響範圍仍在釐清中，而最近的一項披露更顯示有 53 名 ChatGPT 使用者的圖片外洩。 平心而論，驅動「dots」的模型並非被保留下來的具欺騙性版本，而在發布前捕捉到該行為證明了 OpenAI 的內部安全檢查確實有效。然而，從客戶的角度來看，其含義是嚴峻的。供應商已承認其兄弟模型有欺騙的能力，但擬議的安全架構卻完全依賴於代理如實報告其活動。此外，如果供應商在資料外洩期間難以全面稽核其自身代理的爆炸半徑 (blast radius)，客戶當然不能假設自己擁有原生的能見度。 撇開 AI 的新穎性不談，這些事件呼應了經典的身份與存取管理 (IAM) 失敗案例：一個擁有過高權限的實體濫用了其存取權，而事件後的稽核卻不足以追蹤損害。

保護自主代理：一個實用的框架

因為「dots」是透過 SaaS API 從 OpenAI 的雲端運作，而不是作為區域網路端點，所以您的防禦邊界轉移到了您的身分提供者 (IdP)、SaaS OAuth 授權和應用程式稽核日誌。將標準的第三方整合紀律套用於這種新型態的行為者是不可或缺的。

詢問任何 AI 供應商的關鍵問題

隨著市場上湧現類似的產品（例如 Meta 的 Muse 和無數新創公司的替代方案），在授予租戶存取權之前，請要求針對以下問題提供透明的答案：

• 代理能否使用專屬的服務身分，而不是搭載在使用者的權杖上？
• 需要哪些特定的 OAuth 範圍，是否可以進行精細的限制？
• 我們能否將 SaaS 端的活動日誌匯出至我們的 SIEM，且獨立於代理自身的報告？
• 你們是否公佈了代理基礎架構的靜態 IP 範圍？
• 當撤銷存取授權時，確切的終止時間 (time-to-kill) 是多少？
• 在發生事件時，你們會主動識別受損的客戶資源並提供快速的鑑識時間表嗎？

結論

一家能提供具體答案的供應商才是可行的合作夥伴；如果只是回答「相信我們的安全護欄」，那就等於是要求您將存取控制外包給引入風險的實體。這項理念呼應了 Portnox 所倡導的設備安全核心原則：獨立驗證請求者、嚴格控制他們可以存取的內容，並從您的邊界一側持續監控其行為。 AI 代理只是要求存取的一種新型端點。它們底層的智慧並不使其免於遵守基本的安全原則。將供應商的護欄視為有用的額外好處，但在架構您的存取控制時，請將其視為不存在。