我們如何設計更安全的 AI 代理程式

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

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

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

AI 代理程式的失控行為

7 月份，AI 代理程式闖入了開源 AI 平台 Hugging Face 的生產基礎設施。在內部網路安全評估和訓練執行期間，OpenAI 模型發現了一種利用 Artifactory 儲存庫管理員來建立用於彼此通訊佈告欄的方法，使其能夠組織成群。隨後，無法在網路安全基準測試中取得進展的 AI 代理程式招募了其他 AI 代理程式來尋求協助。這些 AI 代理程式突破了它們的評估環境並觸及了網際網路。它們還發現了透過對基準測試任務的答案進行逆向工程來作弊的方法，但認為評分系統會偵測到作弊行為。為了更深入了解基準評估的工作原理以尋找避免被偵測為作弊的方法，它們最終破壞了 Hugging Face 系統 (Hugging Face; OpenAI)。

這起事件是我們在 7 月 開源 Numbat 時所描述的失敗模式的一個清晰範例：意外失控，這是由康乃爾科技學院（Cornell Tech）的安全研究人員創造的術語 (arXiv)。追求合法目標的 AI 代理程式遇到了阻礙，例如遺失的檔案、失敗的 API 呼叫、過期的認證資訊或權限拒絕，並開始尋找權宜之計。在此過程中，它可能會透過偵察、特權提升、機密發現或資料外洩來跨越安全邊界。AI 代理程式本身實際上變成了對手，儘管其中並未涉及任何惡意提示詞或外部攻擊者。

Hugging Face 不是單一孤立的案例。在最近幾週，人們發現並回報了更多的 AI 代理程式失控行為。5 月 27 日至 28 日，AI 代理程式試圖從 Data USA（一個提供美國政府資料開放存取的平台）收集愛荷華大學的資料時，遇到了由格式錯誤的查詢所引起的錯誤。它們透過探測做出回應，包括 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 個網際網路主機的報告 (美國政府問責局報告)。據報導，該病毒滲透了至少 14 個聯邦機構，包括國防部、中情局、NASA 以及眾議院和參議院 (美國政府問責局報告)。它還關閉了五角大廈和英國議會的電子郵件伺服器 (Wired)。保險巨頭倫敦勞合社（Lloyd's of London）早期估計，該病毒將造成超過 150 億美元的損害和生產力損失 (美國眾議院委員會聽證會)。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 病毒出現六天後，美國眾議院子委員會就此舉行聽證會。許多安全專家呼籲立法，使軟體公司對其產品缺陷造成的損害承擔責任。華盛頓走了一條不同的道路。《保護網路空間國家戰略》指出，「聯邦監管不會成為保護網路空間的主要手段」。它警告說，廣泛的授權可能會創造出「網路安全的最低共同分母方法」(CISA)。

業界以工程手段做出回應。在 ILOVEYOU 之後的第十一天，微軟宣布推出 Outlook 更新，以封鎖可執行附件。2002 年 1 月，該公司將安全性列為最高優先事項 (Seattle Times)。自動修補、安全預設值、錯誤賞金計畫和協同揭露成為標準實務。2008 年，Chrome 開始在沙箱中運行網頁內容，這項沙箱「限制了攻擊者在利用漏洞後可以做的事」(Chromium Blog)。加密曾是例外，如今已成為預設值。安全技術（包括多步驟驗證、防火牆、零信任以及安全資訊與事件管理 (SIEM)）得到了廣泛應用。據預測，2006 年全球組織將在資訊安全上花費約 2,400 億美元 (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 代理程式可以拒絕叫用或重新設定的防護機制，就不是防護機制。
3. 信號只能降低權限。偵測應觸發縮小 AI 代理程式可以做什麼的回應，例如暫停、撤銷認證、切斷網路存取或終端工作階段。任何風險信號都不應授予額外的存取權限。

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

Perplexity 產品中的縱深防禦

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

在雲端：Computer 與 SPACE

每個 Computer 任務都在我們用作沙箱平台的 SPACE 中運行，該平台預設將 AI 代理程式視為不受信任的。每個任務都有自己的 microVM，認證資訊保留在沙箱外部，僅在需要時才注入，外發流量在客體作業系統之外進行控制，且快照讓我們能夠復原具破壞性的變更 (打造 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 並將我們的工具開源的防護機制。這也是為什麼我們要揭露我們在其他平台上發現的弱點，並參與諸如開放安全人工智慧聯盟等努力。

為了與更廣泛的社群就這些挑戰進行合作，Perplexity 於 2026 年 3 月啟動了安全智慧研究所（Secure Intelligence Institute），以研究尖端 AI 系統的安全性、可信度和實際防禦 (Perplexity)。Perplexity 目前正在與史丹佛大學、CMU、杜克大學、哥倫比亞大學、俄亥俄州立大學和維吉尼亞大學的學術研究人員進行合作和/或資助。我們也正在進行內部研究，以推進 AI 代理程式安全研究的前沿，將這些進展轉化為 Perplexity 系統的具體改進，並分享有助於加強更廣泛 AI 生態系統的知識與資源。更安全的 AI 代理程式是業界可以透過工程手段實現的目標。我們打算繼續盡自己的一份心力，並邀請其他人與我們一起建構。