# 打破致命三重奏：Asana 如何看待代理式 AI 安全性 > 瞭解 Asana 如何在業界尚未弄清基本原理的情況下，以負責任的方式建立代理式 AI。 Source: https://asana.com/inside-asana/how-asana-thinks-about-agentic-ai-security ## 打破致命三重奏：Asana 如何看待代理式 AI 安全性 _代理式 AI 帶來了一類業界尚未解決的安全風險。 以下是 Asana 對此的看法，以及我們在所有 AI 功能中保持的安全性不變項。_ ### **問題** 代理式 AI 系統不僅僅是回答問題。 它們會閱讀文件、採取行動以及跨工具進行協調。 它們能做的事情越多，可能受攻擊的範圍就越大。 與傳統代碼不同，LLM 有一個特性，使這一點從根本上變得困難：**它們無法可靠地區分指令和資料。** 提供給 LLM 的所有內容都會進入同一個流，因此精心設計的資料可以像合法指令一樣劫持模型。 這是提示注入的根源，Simon Willison[稱](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/)之為基於 LLM 的應用程式的「原罪」。 這並非理論上的問題。 研究人員已經證明了這種攻擊類別可用於[Microsoft 365 Copilot](https://simonwillison.net/2025/Jun/11/echoleak/)、[GitHub 的 MCP 伺服器](https://simonwillison.net/2025/May/26/github-mcp-exploited/)、[Slack AI](https://simonwillison.net/2024/Aug/20/data-exfiltration-from-slack-ai/)以及許多其他工具。 Bruce Schneier[直言不諱地](https://www.schneier.com/blog/archives/2025/08/we-are-still-unable-to-secure-llms-from-malicious-inputs.html)說：業界尚未針對這類攻擊建立強大的防禦機制。 那麼，當業界尚未弄清楚基本原理時，您要如何負責任地建立代理式 AI 呢？ ### **致命三重奏** Willison 將核心風險歸納為三種能力，這三種能力結合在一起，就會為傷害創造條件： - **存取敏感資料。** 代理程式可以讀取機密或私人資訊。 - **接觸不受信任的內容。** 代理程式處理可能包含隱藏惡意指令的輸入。 - **與外部溝通的能力。** 代理程式可以將資訊傳送到系統外部。 對第三個支柱的有用改進：這真的是**產生副作用**的能力，而不僅僅是向外溝通。 將資料外洩到攻擊者的伺服器是典型的例子，但悄悄地重新命名工作空間中每個專案的標題，或將敏感內容傳送到錯誤的內部頻道的惡意指令，也是同樣類型的問題。 我們使用「外部溝通」作為簡略說法，但我們實際上防禦的是更廣泛的版本。 三要素中的任何一個都可以管理。 即使是兩個部分同時存在，通常也是如此。 但當三者匯聚時，就會形成可行的攻擊路徑。 重要的深入解析：**打破任何一個環節都能大幅降低整體風險。** 我們不需要完美解決提示注入。 沒有人做得到。 我們需要確保這三個條件無法輕易同時存在。 [Korny Sietsma 以此為基礎](https://martinfowler.com/articles/agentic-ai-security.html)，將三大要素對應到緩解措施，例如沙盒、任務分解、最低特權以及人在迴圈中。 這些是構成要素。 問題是如何將其付諸實行。 ### **情境、檢查點和控制項** 我們圍繞三大支柱組織思維，這些支柱直接對應致命的三重奏。 每個支柱都限制一條腿。 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 原則](https://asana.com/ai-principles)。 **人們對決策負責，**這推動了以檢查點為導向的設計。 AI 提供協助，但人類始終掌握最新情況，並負有責任。 **我們致力於安全，**因此即使分層控制會增加摩擦，也值得投資。 隨著 AI 功能承擔更複雜的工作，替代方案會加劇風險。 **我們提倡透明度，**這就是我們撰寫此貼文的原因。 我們尚未解決代理式 AI 的安全性問題。 但公開我們如何推理這些風險以及我們採取的緩解措施，有助於更廣泛的社群在共同的挑戰中取得進展，並邀請他人進行審查，讓我們更加進步。 ### **誠實的限制** **提示注入仍然基本上未得到解決**，而間接提示注入（惡意指令嵌入在 AI 在工作過程中擷取的內容中，而非使用者直接提供的內容）是 2026 年業界受到最嚴重打擊的變體。 **來源感知標籤**有所幫助，但無法完全彌補這個缺口，因為模型仍然必須選擇遵守標籤。 我們的檢查點大幅降低了風險，但並未消除風險。 只要指令和資料共享上下文視窗，透過搜尋、公開表單或整合擷取的惡意輸入有時就會被漏掉。 我們將此視為一個積極、持續的投資領域，並更仔細地審查任何讓外部撰寫的內容進入代理式功能的途徑。 [針對保護 LLM 代理的設計模式](https://simonwillison.net/2025/Jun/13/prompt-injection-design-patterns/)的工作指向了有希望的方向，但業界共識仍在形成中。 **威脅環境變化迅速。** 從[基於隱形圖片的提示注入](https://brave.com/blog/unseeable-prompt-injections/)到多步驟洩漏鏈，新的媒介不斷出現。 我們將控制設計為分層且可組合，以便在出現新威脅時新增新的緩解措施。 這是一場軍備競賽，而非一次就能解決的問題。 [OWASP 十大 LLM 應用程](https://genai.owasp.org/llm-top-10/)式是一個有用的持續參考資源。 我們不認為這些差距是放慢腳步的理由。 我們認為這些是需要深思熟慮的原因。 致命的三要素告訴我們風險所在。 背景、檢查點和控制項為我們提供了行動架構。 由於無團隊能獨自解決此問題，我們正積極與我們的研究和客戶合作夥伴一起投入，以便隨著威脅環境的演變，強化這些表面。 #### **參照** - Simon Willison，[《AI 代理程式的致命三重奏》，](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/) 2025 年 6 月 - Korny Sietsma，[《Agentic AI and Security (代理式 AI 與安全性)》，](https://martinfowler.com/articles/agentic-ai-security.html) Martin Fowler，2025 年 10 月 - Bruce Schneier，[《我們仍然無法保護 LLM 免受惡意輸入的影響》，](https://www.schneier.com/blog/archives/2025/08/we-are-still-unable-to-secure-llms-from-malicious-inputs.html) 2025 年 8 月 - [Asana AI 原則](https://asana.com/ai-principles) - OWASP，[《LLM 應用程式前 10 名》](https://genai.owasp.org/llm-top-10/) - [系統管理主控台中的微型架構](/zh-tw/inside-asana/microframeworks-admin-console) 工程 每個 Asana 部署都有一個系統管理主控台。 IT 系統管理員可以在此處設定公司使用 Asana 的方式，例如調整密碼要求、角色和權限、是否可以從 Dropbox 附加檔案，以及在預設情況下誰可以看見新專案。隨著 Asana 的發展，系統管理主控台累積了多年的自訂邏輯和臨時拼湊的解決方案，導致建立和維護管理控制項的成本越來越高。 以其中一項管理設定為例： ... - [以規格為導向的開發：優點以及我們在三個月後學到的內容](/zh-tw/inside-asana/spec-driven-development) 工程 #### 主任軟體工程師 三個月後，我們更清楚地瞭解了新增的架構在何時有幫助，以及在何時成為阻礙。我們的一位工程師正在準備資料遷移，並決定使用規格導向開發 (SDD) 來規劃工作。 SDD 的用意是幫助他們及早發現疏漏，使方法更易於審查，並為客服人員提供明確的方向。 最終的計劃非常詳細，從紙面上看來相當合理。 它將工作組織如下：問題 → 研究 → 規格 → 審查 → 實施 → 驗證 ... - [我們在 2 週內完成了 Enzyme 遷移。這本應花費五年的時間。](/zh-tw/inside-asana/migrating-off-enzyme-2-weeks) 工程 我們最近使用 AI，在大約一次衝刺中完成了多年的工程工作。 以下是其方法，以及為什麼它改變了我們對可能性的看法。五年問題早在 2022 年，我們就著手將 Asana 的前端測試套件從我們老舊的測試庫 Enzyme 移轉至 React Testing Library (RTL)。 Enzyme 已經失去社群支援，無法與較新版本的 React 正常搭配，並且鼓 ... - [AI 隊友如何建立記憶：將工作轉化為可重複使用的知識](/zh-tw/inside-asana/ai-teammates-turn-work-into-reusable-information) 人工智慧 (AI) 工程 大多數 AI 產品將記憶視為個人功能，記住關於一位使用者或一段對話的事實。 但跨團隊協作的 AI 需要一種截然不同的記憶。 當 AI 系統能夠在先前學習的基礎上再接再厲時，就會變得更加實用。 但在企業軟體中，記憶不僅僅是儲存更多內容的問題。 更困難的問題是，讓記憶在共用工作中發揮作用，同時仍保持其可檢查、可治理且具有權限意識。這就是我們打算透過 AI 隊友 ... - [打破致命三重奏：Asana 如何看待代理式 AI 安全性](/zh-tw/inside-asana/how-asana-thinks-about-agentic-ai-security) 工程 - [主任安全工程師](/author/varun-prusty) 代理式 AI 帶來了一類業界尚未解決的安全風險。 以下是 Asana 對此的看法，以及我們在所有 AI 功能中保持的安全性不變項。問題代理式 AI 系統不僅僅是回答問題。 它們會閱讀文件、採取行動以及跨工具進行協調。 它們能做的事情越多，可能受攻擊的範圍就越大。與傳統代碼不同，LLM 有一個特性，使這一點從根本上變得困難：它們無法可靠地區分指令和資料。 提 ... - [工程](/inside-asana/engineering-spotlight)