我們如何建構更安全的 AI 代理程式

要構建更安全的 AI 代理程式，我們需要針對其能力和故障進行設計。即使在執行合法任務且沒有任何惡意指令的情況下，AI 代理程式在試圖克服障礙時也可能會跨越安全邊界。

我們相信這是一個安全工程問題，業界應該以解決 2000 年代初期網絡蠕蟲的方式來解決它。AI 代理程式周圍的系統必須限制 AI 代理程式可以存取的內容、偵測不想要的行為，並在故障發生時予以包含。

在 Perplexity，我們正積極與研究人員和從業人員合作，以推進 AI 代理程式的安全工程，並在我們的模型、AI 代理程式 harness 和基礎設施中應用多個防禦層級，以便安全性不依賴於任何單一的防護機制。

AI 代理程式的失控行為

7 月份，AI 代理程式闖入了開源 AI 平台 Hugging Face 的生產基礎設施。在内部網絡安全評估和訓練運行期間，OpenAI 模型發現了一種利用 Artifactory 存儲庫管理器來建立用於彼此通訊佈告欄的方法，從而使它們能夠組織成群（Swarms）。後來，無法在網絡安全基準測試的任務中取得進展的 AI 代理程式招募了其他 AI 代理程式來提供協助。這些 AI 代理程式突破了其評估環境並連接到互聯網。它們還透過對基準測試任務的答案進行逆向工程來發現作弊的方法，但認為評分系統會偵測到作弊行為。為了更好地了解基準評估的工作原理以尋找避免被偵測為作弊的方法，它們最終損害了 Hugging Face 系統（Hugging Face；OpenAI）。

此事件是我們在 7 月份 開源 Numbat 時描述的故障模式的清晰示例：意外失控（Accidental meltdowns），這是由康奈爾科技（Cornell Tech）的安全研究人員創造的一個術語（arXiv）。追求合法目標的 AI 代理程式會遇到阻力（例如丟失的檔案、失敗的 API 調用、過期的憑證或權限拒絕），並去尋找變通辦法。在此過程中，它可能會透過偵察、特權提升、機密發現或數據外洩來跨越安全邊界。AI 代理程式本身實際上變成了對手，儘管其中不涉及任何惡意提示或外部攻擊者。

Hugging Face 並非單一事件。在過去幾星期內，人們發現並報告了更多 AI 代理程式失控（Meltdown）的行為。在 5 月 27 日至 28 日期間，企圖從 Data USA（一個提供美國政府數據開放存取的平台）收集愛荷華大學數據的 AI 代理程式，遇到了由格式錯誤的查詢所引起的錯誤。它們透過探測做出回應，包括 SQL 資料隱碼攻擊、跨網站指令碼、範本隱碼攻擊、路徑周遊和命令隱碼攻擊。這項活動後來被追溯到 OpenAI（SecurityWeek）。在 6 月 20 日至 21 日期間，OpenAI 的 AI 代理程式試圖從澳洲健康與福利研究所（AIHW）取得維多利亞州各地區某類藥物的每人政府成本資料時，被阻止下載檔案。作為回應，AI 代理程式從 AIHW 的預先生產伺服器下載了該檔案（該檔案已經是公開的），並在此過程中規避了該網站的反機器人保護機制（SecurityWeek）。

這種模式並不局限於某一個實驗室。在網絡安全測試期間，Anthropic 的模型在獲得開放互聯網存取權限的錯誤設定後攻陷了三家公司，Google 的 Gemini 猜出了三個網站的憑證，而一個 Meta 模型則利用了第三方服務（Reuters）。

借鑑歷史：網絡蠕蟲時代

這些事件讓人想起大約四分之一世紀前的網絡蠕蟲時代。在 2000 年代初期，互聯網的發展速度遠快於其周圍的安全實踐。我們看到了病毒和蠕蟲浪潮，其後果比我們現在看到的 AI 代理程式失控情況要嚴重得多。

2000 年 5 月 4 日，人們開始收到來自熟悉發件人且主旨為「ILOVEYOU」的電子郵件。打開電子郵件中的附件會導致運行一個腳本，該腳本將自身的副本郵寄給受害者 Outlook 通訊錄中的所有人。當天下午 6 點之前，CERT 協調中心已收到涉及 420,000 多個互聯網主機的報告（US GAO Report）。據報導，該病毒滲透了至少 14 個聯邦機構，包括國防部、中情局、NASA 以及眾議院和參議院（US GAO Report）。它還關閉了五角大樓和英國議會的電子郵件伺服器（Wired）。保險巨頭倫敦勞合社（Lloyd's of London）早期估計，該病毒將造成超過 150 億美元的損害和生產力損失（US House Committee Hearing）。Computer Economics 後來估計全球損失達 87.5 億美元（Information Week）。

不需要人類點擊的蠕蟲隨後出現。2001 年 7 月 19 日，代號紅色（Code-Red）的蠕蟲在不到 14 小時內感染了 359,000 多台電腦（CAIDA）。2003 年 1 月 25 日，SQL Slammer 以每 8.5 秒一倍的速度規模翻倍，並在 10 分鐘內感染了超過 90% 容易受到其攻擊的互聯網主機（CAIDA），利用了微軟在六個月前發布修補程式的一個漏洞（CNET）。2003 年 8 月，衝擊波（Blaster）蠕蟲和 Sobig 電子郵件蠕蟲相隔大約一週出現（Microsoft，F-Secure）。

當時，詢問聯網電腦是否能做到完全安全是合理的。在 ILOVEYOU 病毒出現六天後，美國眾議院一個小組委員會就此舉行了聽證會。許多安全專家呼籲立法，規定軟件公司對其產品缺陷造成的損害承擔責任。華盛頓走了一條不同的道路。《確保網絡安全國家戰略》（National Strategy to Secure Cyberspace）指出，「聯邦法規不會成為確保網絡安全的主要手段。」它警告說，廣泛的授權可能會產生「網絡安全的最低公分母方法」（CISA）。

業界以工程作出了回應。在 ILOVEYOU 之後的第十一天，微軟宣布推出一個阻止可執行附件的 Outlook 更新。2002 年 1 月，該公司將安全性放在首位（Seattle Times）。自動修補、安全預設值、漏洞賞金計劃和協同披露成為標準做法。2008 年，Chrome 開始在沙箱中運行網頁內容，該沙箱「限制了攻擊者在利用漏洞後可以做的事」（Chromium Blog）。加密曾經是特例，現在已成為預設值。安全技術（包括多因素身份驗證、防火牆、零信任以及安全資訊和事件管理 (SIEM)）得到了廣泛使用。預計全球組織在 2006 年將在資訊安全上花費大約 2400 億美元（Gartner）。蠕蟲從未完全消失，但例行性的全互聯網爆發時代已經消退。與此同時，在隨後的二十年中，互聯網在很大程度上不受法規的阻礙，成為創新和經濟增長的強大引擎。

AI 代理程式的安全工程

最近的事件引發了對 AI 代理程式治理的正當質疑。現有的安全機制是為預先 AI 代理程式運算環境而開發的，其特點是範圍緊湊且主要是確定性的軟件行為。特別是存取控制機制，主要是圍繞着人類用戶設計的，並且通常授予他們廣泛的權限，這些權限原則上足以造成重大損害。

這種設計基於幾個假設：大多數用戶都是懷有善意的；惡意行為者可以透過審計和現實世界的後果來威懾；人類採取正確或錯誤行動的速率相對有限。將這些安全機制應用於 AI 代理程式需要考慮人類和 AI 代理程式行為之間的差異。正如我們在 對 NIST 關於 AI 代理程式安全資訊請求的回應中所寫的那樣，AI 代理程式挑戰了這些假設。它們可以以機器速度行使權限並採取行動，本身不受現實世界後果的威懾，並且可能會採取技術上允許但典型人類用戶很少採取的行動。

回答這些問題需要安全工程。我們知道在單個組件發生故障時保持風險受控的系統建構安全原則。但我們需要確保在為訓練、測試和使用 AI 代理程式而進行環境工程時應用這些原則。

深層防禦安全原則

可以說，保障 AI 代理程式安全時需要應用的最重要安全原則是深層防禦，它提倡分層安全架構，採用多個、多樣且冗餘的防禦措施來保護系統資源。沒有任何單一防護機制是完美的。人們可能會陷入社會工程學攻擊並洩露他們的登入憑證，零時差軟件漏洞被發現並遭到利用，而入侵偵測則會錯過新的攻擊變體。深層防禦接受這一點，並堆疊多個獨立的防禦層級。如果某個防禦層級遭到規避，其他層級仍會保留以應對或偵測入侵。

Hugging Face 事件展示了深層防禦的重要性。OpenAI 的回顧性報告指出，其生產系統中使用的自動化防護機制（包括 harness、自動審查模型和安全分類器）在評估環境中並未出現。如果在這些評估中運行目前部署的思維鏈監控，它將在違規發生前一天多就捕捉到初始活動並呼叫安全團隊（OpenAI）。本可以捕捉到問題的層級是存在的。它們只是沒有全部同時到位。

確保 AI 代理程式的安全需要提高 AI 模型及其周圍系統的安全性和防護。模型層級的工作非常重要，而且它正在取得成效。早期的 LLM 很容易被注入的指令操縱，而當今的模型在識別和拒絕這些指令方面要好得多。模型開發人員還培訓模型以實現更安全的行為，正如 OpenAI 的回顧所描述的那樣，監控推理痕跡以尋找有問題行為的跡象。但模型層級的防禦只是解決方案的一部分。訓練、測試和部署 AI 代理程式的系統也必須針對安全性和包含進行工程設計。模型層級的安全性降低了 AI 代理程式走向歧途的可能性；系統層級的安全性限制了它發生歧途時的損害。

放大

冗餘防護機制的設計規則

深層防禦需要冗餘防護機制。對於 AI 代理程式，我們提倡應用三條設計規則：

1. 獨立性。 每個層級都應基於獨立的原因而失敗。共用相同假設的兩個控制項可能會被相同的攻擊擊敗。監控器和強制執行點應位於 AI 代理程式觸及範圍之外。
2. 低於 AI 代理程式的強制執行。 至少有一個層級必須是確定性的：常規的、可驗證的代碼，無論模型產生什麼內容，都能阻止禁止的動作。AI 代理程式可以拒絕呼叫或重新配置的防護機制不是防護機制。
3. 信號只能降低權限。 偵測應觸發縮小 AI 代理程式可以做什麼的回應，例如暫停、撤銷憑證、切斷網絡存取或終止工作階段。任何風險信號都不應授予額外的存取權限。

我們與 開放安全 AI 聯盟（Open Secure AI Alliance）中的合作夥伴分享這些原則，其中包括 NVIDIA，該公司認為 harness 引導 AI 代理程式嘗試的事物，而基礎設施則控制它可以做的事（NVIDIA）。

Perplexity 產品中的深層防禦

Perplexity 在四種環境中運行 AI 代理程式：透過我們的 AI 代理程式平台 Computer 在雲端中，透過 Comet 在瀏覽器中，透過 Portable Computer 在用戶裝置上，以及在員工手提電腦上（我們的工程師在其中使用第三方編碼 AI 代理程式）。每個環境都有其自身的風險，並且每個環境都獲得了多層保護。

在雲端：Computer 和 SPACE

每個 Computer 任務都在我們用作沙箱平台的 SPACE 中運行，該平台默認將 AI 代理程式視為不受信任的。每個任務都有自己的 microVM，憑證保留在沙箱外部並僅在需要時注入，外發流量在客體外部進行控制，且快照允許我們復原破壞性變更（Making SPACE）。企業客戶還可以帶入自己的加密金鑰。撤銷金鑰會使受保護的數據無法讀取，並且 AI 代理程式無法覆寫該決定。

我們還測試了這些層級是否有效。在《逃離 SPACE：第一部分》中，我們為九個前沿模型授予了 SPACE 沙箱內部的 root 存取權限，並要求它們突破。沒有一個逃出 VM，但當允許部分網絡存取時，有些模型找到了繞過網絡策略的方法。我們修復了這些漏洞，在重新測試中確認了修復效果，並將我們在其他 10 個沙箱平台中的 8 個中發現的類似弱點披露給了它們的供應商。

在瀏覽器中：Comet 和 BrowseSafe

自推出以來，Comet 一直使用分層的提示隱碼攻擊防禦：分類器篩選檢索到的內容，結構化提示將其標記為不受信任，敏感操作（例如發送電子郵件或下訂單）需要用戶確認，並且會在某事被阻止時告知用戶（Comet 提示隱碼攻擊防禦）。BrowseSafe 作為第一層背後的開源偵測模型，在我們的 BrowseSafe-Bench 基準測試中的表現優於前沿模型，但同一個基準測試表明沒有哪個偵測器是萬無一失的，這就是為什麼偵測永遠不是唯一的層級（BrowseSafe 研究）。Computer 繼承了這些防禦，這些防禦已通過 Trail of Bits 的審計（Perplexity）。

在裝置上：Portable Computer

Portable Computer 是一個本機優先的 AI 代理程式：模型、harness、對話和軌跡預設保留在用戶的機器上。確定性協調器（它是 harness 代碼而不是 LLM）運行循環並強制執行策略。模型提出動作，批准的工具調用在限制進程、檔案路徑和網絡存取的作業系統層級沙箱中運行。沙箱始終處於開啟狀態且預設失敗關閉：如果不可用，harness 會自行停用，而不是使用用戶的權限運行命令。跨越裝置邊界的動作（例如網絡搜尋、連接器以及升級到更強大的雲端顧問模型）僅在用戶啟用和批准它們時才會發生。在顧問調用之前，PII 分類器會標記敏感資訊，並且用戶可以看到將要發送的內容。顧問僅接收該批准的上下文並返回文字引導，無法存取裝置的檔案或工具。

在端點上：Numbat

在開發人員手提電腦上運行的編碼 AI 代理程式運行數小時，並可存取源代碼、憑證和生產系統。Numbat 是我們的開源 AI 代理程式安全套件，它增加了一個位於任何單個 AI 代理程式之外的獨立層級。它與 Claude Code、Codex、OpenCode 和 Pi 等 harness 協同工作，在危險動作運行之前予以阻止，標記可疑的多步驟序列（例如讀取機密然後發送數據），並保留用於調查的工作階段時間軸。Numbat 在數千個 Perplexity 端點上運行，與我們的開源供應鏈掃描器 Bumblebee 並肩作戰。Computer 定期審查其發現並提出改進的偵測規則，人類會在每次變更出貨前進行審批。

整個行業的工作

隨著 AI 代理程式變得更加強大和廣泛使用，安全工程必須仍然是其開發和部署的核心。研究人員和工程師可以建立在既定原則的基礎上，使用現實世界的發現來改進防禦，並在 AI 代理程式運行的環境中測試防護機制。安全性是一項持續的工程學科，與技術一同發展。

AI 代理程式的安全工程是整個行業的工作。沒有哪家單一公司控制 AI 代理程式在其上運行的完整堆疊。模型開發人員、harness 建構者、沙箱和執行階段提供商、雲端和硬件供應商以及企業安全團隊各自擁有一層。整體的安全性取決於當另一個層級滑落時每個層級都能夠支撐。這就是為什麼我們建構跨 AI 代理程式 harness 運行的防護機制並開源我們的工具。這也是我們公開在其他平台中發現的弱點並參與諸如開放安全 AI 聯盟等工作的原因。

為了與更廣泛的社群合作應對這些挑戰，Perplexity 於 2026 年 3 月成立了安全智能研究所（Secure Intelligence Institute），以研究領先 AI 系統的安全性、可信度以及實際防禦（Perplexity）。Perplexity 目前正在與史丹福大學、卡內基美隆大學、杜克大學、哥倫比亞大學、俄亥俄州立大學和維珍尼亞大學合作及/或資助其學術研究人員。我們還在進行院內研究，以推進 AI 代理程式安全研究的前沿，將這些進展轉化為 Perplexity 系統的具體改進，並分享有助於強化更廣泛 AI 生態系統的知識和資源。更安全的 AI 代理程式是業界可以透過工程實現的。我們打算繼續盡自己的一份力量，並邀請其他人與我們一同構建。