AIDEFEND in Action AIA-0091 實證研究發布於 AIA: 2026年10月1日

SalesBleed：Agentforce 如何在 Slack 發出含釣魚連結的回覆

Zenity Labs 驗證了針對 Agentforce in Slack 的兩條濫用路徑：外部攻擊者可將惡意指示注入員工 agent 稍後讀取的 CRM 潛在客戶資料（Lead）；內部人員則可直接要求 agent 發送訊息。在受測的 Slack Knowledge 範本中，Reply to a Slack Thread 動作預設不要求送出前確認，回覆也未顯示是哪位使用者發起，且特製網址能繞過遮蔽機制。Salesforce 已於 2026 年 9 月完成相關預設設定與繞過修復。

Indirect Prompt InjectionSocial EngineeringHuman-in-the-LoopSaaS Security

7 項對應的 AIDEFEND 防禦手法

來源: SalesBleed: Hijacking Agentforce in Slack for Anonymous Phishing Attacks

作者: João Donato, Alex Apostolov, Avishai Efrat, Ayush RoyChowdhury

原文發布: 2026年9月24日

威脅分析

SalesBleed 包含兩條受測的攻擊入口：外部攻擊者可將指示植入員工 agent 稍後讀取的 CRM 潛在客戶資料（Lead）；內部人員則可直接要求 agent 發布訊息。兩條路徑最後都匯流至 Reply to a Slack Thread 動作，該動作當時預設不要求送出前確認，回覆也未顯示是哪位使用者發起。

外部攻擊者透過公開的 Web-to-Lead 等表單提交潛在客戶資料（Lead），內含注入指示與特製釣魚連結。
員工請 agent 協助處理潛在客戶資料；agent 讀取紀錄後，將其中的不可信文字當作在 Slack 發布訊息的指令。
擁有權限的內部人員直接要求 agent 發送含有釣魚內容的 Slack 回覆；這是另一條經受控測試的內部人員路徑。
Reply to a Slack Thread 動作在未經獨立使用者確認的情況下送出訊息；受測的網址遮蔽繞過手法亦使惡意連結完整保留在訊息中。
回覆以 agent 身分出現在相關討論串中，未顯示是哪位使用者發起，使釣魚訊息更容易取得同仁信任。

Zenity 亦驗證了特製釣魚網址能繞過遮蔽並保留在回覆內。Salesforce 已於 2026 年 9 月 21 日前確認完成修復；若企業後續自行關閉確認提示，仍可能重新暴露同類風險。該研究並未記錄到真實世界中的釣魚受害者。

適用的 7 項 AIDEFEND 防禦手法

AID-H-018.002

Policy-Based Access Control

高

Slack 發布訊息的授權必須源自已通過身分驗證的呼叫者與當前任務脈絡，絕不能依據 CRM 紀錄內的文字：處理潛在客戶資料的任務，絕不可獲准向任意 Slack 討論串發文。在 Agentforce 架構下，客戶無法在規劃器與標準 Reply to a Slack Thread 動作之間插入自訂政策檢查，因此部署前提是將標準 Slack 寫入動作從 agent 移除，改由客戶自行開發的自訂動作（如 Apex、Flow 或 External Service）發送，並在發布前強制執行政策驗證。若內部使用者原本就具備在該頻道發文的權限，此政策仍會放行，因此這項控制主要限制目標討論串範圍，無法單獨杜絕所有風險。

AID-H-018.003

High-Impact Independent Validation & Approval Gate

高

把大量發送或含連結的 Slack 發文列為高影響操作。以客戶自建動作取代標準寫入動作，在送出前要求綁定確切訊息、目的地、連結與已驗證發起者的獨立核准。由提出請求的員工再次確認，可以攔下外部潛在客戶資料誘發的非預期發文；卻無法單獨阻止有意發送釣魚訊息的內部人員自行核准。針對這類風險，政策須要求另一位有權限的人核准。

AID-H-017.002

Least-Privilege Tool Architecture

高

Slack Knowledge 範本所引入的 Reply to a Slack Thread 屬於通用寫入動作，凡是 Search Slack 能檢索到的討論串皆可寫入。處理潛在客戶資料的 agent 應完全不配置 Slack 寫入權限，或改以客戶自訂動作取代範本動作：將討論串參數嚴格限縮於發起請求的當前對話，且訊息結構禁止包含 Markdown 連結。若完全移除寫入權限，agent 就無法發送 Slack 訊息；若只開放受限的自訂動作，則只能回覆發起請求的對話。兩種做法都能移除研究中用來向其他討論串發送訊息的通用工具。

AID-H-006.002

Text, Markup & Structured Output Sanitization and Release Gate

高

在客戶自建的 Slack 發送動作中，解析 Slack 實際接收的訊息內容，擷取所有明文顯示與隱藏在 Markdown 語法內的網址，完成正規化後比對目標位址、安全政策及最新威脅情資。只要有任何網址無法通過驗證，整則訊息便一律禁止送出。此機制能有效阻擋已知惡意網域與格式繞過手法；若攻擊者採用尚無信譽紀錄的新註冊網域，仍需仰賴明確的目的地允許清單（allowlist）或獨立人工核准。

AID-H-017.007

Dual-LLM Isolation Pattern

中

讓沒有 Slack 工具的 Q 工作程序在隔離環境中讀取原始 CRM 潛在客戶資料，再由中介服務檢查資料欄位及允許的值，僅將必要資料交給持有 Slack 工具的 P 工作程序。兩端須有獨立身分、憑證與網路路徑，並禁止 P 讀取原始資料。單一提示範本或自由文字摘要不足以構成這道邊界；字串即使符合欄位格式，仍可能含有惡意指示，因此轉交文字仍是不可信資料，每次 Slack 動作都須獨立授權。這需要可實測隔離效果的客戶自建整合，不能假設原版 Agentforce 已提供。

AID-H-018.005

Value-Level Capability Metadata & Data Flow Sink Enforcement

中

只有整合系統能提供訊息及每個衍生連結完整、可驗證的來源資訊，客戶自建 Slack 動作才能依資料標記執行政策。只在 CRM 紀錄入口加標籤，無法追蹤模型任意改寫；來源不明時須拒絕，並移除標準動作與直接寫入的繞過路徑。較保守的替代方式，是禁止隔離的潛在客戶處理任務發送所有連結或寫入；這與 AIDEFEND 所述逐一追蹤每個資料值來源與去向的方法不同。原版 Agentforce 設定不能證明任一架構已成立。

AID-D-005.004

Specialized Agent & Session Logging

中

每次呼叫 Reply to a Slack Thread 時，皆應完整記錄已驗證的觸發使用者、agent 當時的任務目標、工具引數雜湊值與政策判定結果。日後若有疑似釣魚訊息以 agent 身分發布時，資安團隊便能迅速回溯是由哪位員工的請求或讀取了哪筆 CRM 紀錄所導致；也能查出是否有內部人員直接指使 agent 發文。不過，Slack 頻道內的接收同仁若要即時辨識觸發者，仍須仰賴產品介面本身的標示機制。

身為資安防禦者，我們應該這麼做

全面盤點 Agentforce 的所有 Slack 寫入動作，特別是 Reply to a Slack Thread。凡涉及高影響力的訊息發布，應以客戶自建動作取代標準動作，並在訊息送出前，針對實際顯示的內容、網址、發送目標與已驗證呼叫者要求獨立核准。
完整記錄已驗證的實際呼叫者以供資安鑑識；若需讓接收者即時掌握訊息發起人，應在 Slack 訊息中加入產品層級的來源標示。僅留存日誌記錄無法改變接收者當下看見的畫面。
於最終發送動作前，針對正規化網址與隱藏在 Markdown 中的目標位址落實政策比對；範本或設定變更後，應再次送出原本必須被擋下的測試網址，確認政策仍會拒絕發送。

1 個額外的防禦考量

證據與部署界線

目前修正後的預設設定能降低這條特定攻擊鏈；但客戶仍可能透過自訂設定關閉確認提示或發送者標示。

建議做法: 全面盤點 Agentforce 的所有 Slack 寫入動作，特別是 Reply to a Slack Thread；針對具高影響力的訊息發布，必須要求已驗證的呼叫者對確切文字、網址與討論串進行顯式確認。

結論

AIDEFEND 指出關鍵防線在於 Slack 訊息真正送出前的最後一道檢查：發送動作必須嚴格驗證是誰發起請求、訊息發布目標為何，以及呈現文字所指向的真實網址。若要在送出前核對核准紀錄與實際訊息是否一致，必須以客戶自建動作取代標準發送動作；日誌則只能供事後追查。

最後更新: 2026年10月1日