打破致命三重奏：Asana 如何看待代理式 AI 安全性
代理式 AI 帶來了一類業界尚未解決的安全風險。 以下是 Asana 對此的看法，以及我們在所有 AI 功能中保持的安全性不變項。
問題
代理式 AI 系統不僅僅是回答問題。 它們會閱讀文件、採取行動以及跨工具進行協調。 它們能做的事情越多，可能受攻擊的範圍就越大。
與傳統代碼不同，LLM 有一個特性，使這一點從根本上變得困難：它們無法可靠地區分指令和資料。 提供給 LLM 的所有內容都會進入同一個流，因此精心設計的資料可以像合法指令一樣劫持模型。 這是提示注入的根源，Simon Willison 稱之為基於 LLM 的應用程式的「原罪」。
這並非理論上的問題。 研究人員已經證明了這種攻擊類別可用於 Microsoft 365 Copilot、GitHub 的 MCP 伺服器、Slack AI 以及許多其他工具。 Bruce Schneier 直言不諱地說：業界尚未針對這類攻擊建立強大的防禦機制。
那麼，當業界尚未弄清楚基本原理時，您要如何負責任地建立代理式 AI 呢？
致命三重奏
Willison 將核心風險歸納為三種能力，這三種能力結合在一起，就會為傷害創造條件：
存取敏感資料。 代理程式可以讀取機密或私人資訊。
接觸不受信任的內容。 代理程式處理可能包含隱藏惡意指令的輸入。
與外部溝通的能力。 代理程式可以將資訊傳送到系統外部。
對第三個支柱的有用改進：這真的是產生副作用的能力，而不僅僅是向外溝通。 將資料外洩到攻擊者的伺服器是典型的例子，但悄悄地重新命名工作空間中每個專案的標題，或將敏感內容傳送到錯誤的內部頻道的惡意指令，也是同樣類型的問題。 我們使用「外部溝通」作為簡略說法，但我們實際上防禦的是更廣泛的版本。
三要素中的任何一個都可以管理。 即使是兩個部分同時存在，通常也是如此。 但當三者匯聚時，就會形成可行的攻擊路徑。
重要的深入解析：打破任何一個環節都能大幅降低整體風險。 我們不需要完美解決提示注入。 沒有人做得到。 我們需要確保這三個條件無法輕易同時存在。
Korny Sietsma 以此為基礎，將三大要素對應到緩解措施，例如沙盒、任務分解、最低特權以及人在迴圈中。 這些是構成要素。 問題是如何將其付諸實行。
情境、檢查點和控制項
我們圍繞三大支柱組織思維，這些支柱直接對應致命的三重奏。 每個支柱都限制一條腿。
Asana 有多個 AI 介面。 AI 隊友是代理參與者，在工作空間中擁有自己的成員資格和權限。 其他 AI 功能以使用者身分運作，其界限是該使用者已經可以存取的內容。 以下不變項著重於代理的情況，其中介面最大，我們將指出依介面而異的實施情況。
情境：管理 AI 可以查看的內容
Trifecta 部分：存取敏感資料
為了讓代理式 AI 發揮作用，它需要情境資訊。 挑戰在於給予它足夠的資訊，讓它能夠提供協助，但又不會給它萬能鑰匙。
我們的基本不變原則是最低權限原則，其確切表達方式取決於介面。 對於 AI 隊友而言，其擁有與任何個別使用者分開的專屬成員資格，界限是隊友權限與使用者權限的交集。對於以使用者身分運作的 AI 功能而言，界限僅是該使用者自己的存取權限。 在每種情況下，管理 Asana 中所有其他互動的同一個伺服器端授權層都會管理 AI 的存取權限。 AI 功能不會獲得提升的權限。 它們在 Asana 的存取控制系統內運作，而不是在其周圍。
定義情境不僅涉及規範 Asana 內部資料的存取，還包括代理程式可以互動的外部整合。 雖然整合目前需要使用者明確授權，但我們正在開發細微的、特定於代理程式的控制路徑。 這使組織能夠限制處理高風險輸入項的 AI 隊友的整合權限。 我們的核心架構不變原則很明確：AI 可查看內容的界限必須是動態的，並由資料所有者驅動，而非硬式編碼的產品預設。
即使攻擊者將惡意指令偷偷放入 AI 的背景資訊中，AI 實際上可以看到的內容也會受到與其他所有內容相同的權限模式限制。
檢查點：篩選 AI 可聆聽的內容
三重防護：接觸不受信任的內容
這是最困難的階段。 在工作管理平台中，AI 讀取的大部分內容都是使用者產生的內容：任務、評論、附加文件。 其中一些來自組織外部。 您無法拒絕讀取。
相反地，我們建立了檢查點：我們在這些檢查點區分可信任的意圖和任意內容，且若有任何看起來不對勁的地方，人類可以介入。
來源感知指令處理。 AI 功能會依據作者信任度和來源標記內容，因此模型可以將授權使用者的指令加權，使其高於在此過程中在任意內容中遇到的指令。 這樣可以縮小提示注入的攻擊面，但無法完全消除；模型仍會在其情境中讀取所有內容，且安全性保證是部分性的，而非絕對性的。 我們在下面討論此方法的局限性。
記錄和取證調查。 每次模型呼叫都會記錄其輸入、輸出、執行者、功能內容和下游事件，包括自動化觸及的工作圖物件，以及輸出中出現的網址。 我們會針對錯誤率和成本飆升等營運訊號自動發出警示。 對於與安全相關的異常情況，這些相同的記錄可支援人類進行事後調查。 正如 Willison 所指出的，即使是能夠捕捉大多數攻擊的基於模式的偵測，單靠它本身也無法達標；可視度和調查能力是我們建立的持久基礎，而非牆壁。
人在迴圈中的設計。 AI 功能會顯示其工作，供人工審查，而不是悄悄採取不可逆轉的行動。
任務分解和範圍內動作。 複雜的工作流程被分解為較小的階段，AI 功能可執行的動作有意受到限制，而非開放式。
這些措施單獨使用時都無法做到萬無一失。 它們共同構成深度防禦。
控制項：限制 AI 可以採取的行動
三重防線：產生副作用的能力
第三個支柱是大多數現實世界攻擊的發生地。 如果攻擊者說服人工智慧將敏感資料嵌入 URL、透過整合傳送，或變更其他人所依賴的記錄，則攻擊成功。
我們在此投資於幾個控制類別：
將 LLM 輸出視為不受信任。 產生的內容不會因為來自 Asana AI 而獲得信任提升。 它與任何其他使用者產生的內容經過相同的驗證和轉譯流程。
高影響力動作必須經人工核准。 無論 AI 的信心有多高，或請求看起來有多常規，某些動作類別始終需要人工明確核准。 對於 AI 隊友，這包含提升存取權限的行動 (變更權限、新增成員) 以及銷毀資料的行動 (刪除)。 AI 可以提出這些建議；但無法自行執行。
連結處理防護機制。 AI 產生的內容中的外部 URL 在到達使用者之前會先經過處理。 未出現在輸入內容中的新 URL 會受到額外審查，並以完整、未隱藏的形式顯示，而非以重新標記的錨點文字顯示，因此 AI 無法被用作武器，將洩漏端點偽裝成友善的「點擊此處查看摘要」。
無通用傳出 HTTP。 AI 功能沒有開放式的「向任何 URL 發送請求」基元。 外部整合會透過範圍內的通道進行，並具有其專屬的授權。
動作稽核追蹤。 AI 功能執行的每個寫入、變更和對外動作都會與觸發它的模型呼叫一起記錄，因此調查人員可以重建 AI 所做的事情，而不僅僅是它被要求做的事情。
目標並非使外部溝通變得不可能。 AI 功能需要參考連結、更新任務並產生有用的輸出。 目標是確保它們無法以使用者不希望的方式暗中執行這些操作。
AI 輸出值的模式
在這個框架內，同一個具體的子問題不斷出現：AI 功能產生某個東西（物件識別碼、收件人、網址），而下游程式碼對其進行操作，通常具有比 AI 本身更廣泛的權限。 幻覺和提示注入都落在同一個地方：模型輸出的值會受到信任。
我們使用四部分模式作為這些值的設計審查核對清單：
在必須執行驗證之前，從最開始就限制AI 可以產生的內容。
在伺服器端，根據與其他所有內容相同的授權層驗證每個 AI 產生的值。 模型被視為不受信任的用戶端。
保留足夠的結構化情境資訊，以說明 AI為何做出這樣的選擇，從而證明選擇的合理性。 這使得後續的調查、評估和事件應變成為可能。
當值具有高風險或超出預期範疇時，透過阻礙、備案或人工審查進行升級。
貫穿其中的主題：模型行為不應該是主要的安全控制。 更好的提示和「我們告訴模型不要這樣做」是有用的深度防禦，但持久的控制措施位於模型周圍的系統中。
以原則為基礎
這些選擇並非臨時性的。 它們源自 Asana 發佈的 AI 原則。
人們對決策負責，這推動了以檢查點為導向的設計。 AI 提供協助，但人類始終掌握最新情況，並負有責任。
我們致力於安全，因此即使分層控制會增加摩擦，也值得投資。 隨著 AI 功能承擔更複雜的工作，替代方案會加劇風險。
我們提倡透明度，這就是我們撰寫此貼文的原因。 我們尚未解決代理式 AI 的安全性問題。 但公開我們如何推理這些風險以及我們採取的緩解措施，有助於更廣泛的社群在共同的挑戰中取得進展，並邀請他人進行審查，讓我們更加進步。
誠實的限制
提示注入仍然基本上未得到解決，而間接提示注入（惡意指令嵌入在 AI 在工作過程中擷取的內容中，而非使用者直接提供的內容）是 2026 年業界受到最嚴重打擊的變體。 來源感知標籤有所幫助，但無法完全彌補這個缺口，因為模型仍然必須選擇遵守標籤。 我們的檢查點大幅降低了風險，但並未消除風險。 只要指令和資料共享上下文視窗，透過搜尋、公開表單或整合擷取的惡意輸入有時就會被漏掉。 我們將此視為一個積極、持續的投資領域，並更仔細地審查任何讓外部撰寫的內容進入代理式功能的途徑。 針對保護 LLM 代理的設計模式的工作指向了有希望的方向，但業界共識仍在形成中。
威脅環境變化迅速。 從基於隱形圖片的提示注入到多步驟洩漏鏈，新的媒介不斷出現。 我們將控制設計為分層且可組合，以便在出現新威脅時新增新的緩解措施。 這是一場軍備競賽，而非一次就能解決的問題。 OWASP 十大 LLM 應用程式是一個有用的持續參考資源。
我們不認為這些差距是放慢腳步的理由。 我們認為這些是需要深思熟慮的原因。 致命的三要素告訴我們風險所在。 背景、檢查點和控制項為我們提供了行動架構。 由於無團隊能獨自解決此問題，我們正積極與我們的研究和客戶合作夥伴一起投入，以便隨著威脅環境的演變，強化這些表面。
參照
Simon Willison，《AI 代理程式的致命三重奏》， 2025 年 6 月
Korny Sietsma，《Agentic AI and Security (代理式 AI 與安全性)》， Martin Fowler，2025 年 10 月
Bruce Schneier，《我們仍然無法保護 LLM 免受惡意輸入的影響》， 2025 年 8 月
OWASP，《LLM 應用程式前 10 名》
