AID-H-018.004
極高
Intent-Based Dynamic Capability Scoping
能力範圍簽章會把使用者原始請求固定下來：使用者問的是「第一筆客服案件是什麼」，agent 不應取得更新聯絡人的能力。工具調度器應根據可信使用者請求產生經簽章的權限範圍；除非使用者明確要求並核准，否則拒絕 CRM 寫入工具。
提示詞地雷攻擊：CRM AI 助理的寫入動作為什麼需要一道授權關卡
Zenity 的 Prompt Mines 研究顯示，外部攻擊者可以透過 Email-to-Case 或 Web-to-Case（把 email 或網頁表單轉成客服案件的 Salesforce 功能）建立 Salesforce（CRM 平台）客服案件，把惡意指令拆進多筆案件標題，等使用者向 Einstein（Salesforce 的 CRM AI 助理）詢問常見後續問題時才觸發。攻擊成功後，Einstein 不是只回答錯誤內容，而是可能呼叫 QueryRecords 找出聯絡人 ID，再反覆呼叫 UpdateCustomerContact 把 CRM 聯絡資料改成攻擊者指定的值。防線必須放在寫入前：依使用者原始請求縮小工具權限、對高影響寫入做獨立驗證，並準備資料完整性復原措施。
威脅分析
- 攻擊者使用的是合法 CRM 資料匯入路徑。 Email-to-Case 或 Web-to-Case 允許外部使用者建立客服案件；如果這些入口沒有驗證或審核，攻擊者就能把惡意案件放進受害組織的 Salesforce CRM。
- 惡意指令會被拆成多筆案件標題。 Salesforce 案件 subject 有長度限制，攻擊者因此把 prompt mine 拆成多筆客服案件，用分隔符號和偽造公司政策把它們串成較長指令。這些內容單筆看可能不像完整攻擊，但一起進入上下文後就能改變 agent 行為。
- 使用者可能看不到真正的惡意紀錄。 Zenity 指出，介面可能只顯示前幾筆客服案件，但其他案件仍可能進入 Einstein 的對話上下文。使用者以為自己只是在看一般案件列表，實際上 agent 已讀到隱藏在其他案件裡的指令。
- 觸發點是自然的後續問題。 使用者問「第一筆案件是什麼」這類常見問題時，prompt mine 才被啟動。攻擊者利用的是 agent 對上下文的延續理解，而不是要求使用者點擊惡意連結或核准高風險動作。
- 真正造成損害的是 CRM 寫入工具。 惡意指令要求 Einstein 先呼叫
QueryRecords取得聯絡人 ID，再反覆呼叫UpdateCustomerContact，把客戶聯絡資料改成攻擊者指定的值。危害不是回答錯誤，而是正式 CRM 記錄被竄改。 - 資料被改後，復原能力就是防線的一部分。 防守方要能找出哪些 CRM 記錄被改、改動由哪次 agent 工作階段觸發、可信值要從哪個快照或系統回復，並在重新開放自主寫入前補上授權與驗證缺口。
適用的 9 項 AIDEFEND 防禦手法
AID-H-018.003
極高
High-Impact Independent Validation & Approval Gate
大量或反覆更新聯絡人資料是高影響 CRM 異動。真正執行
UpdateCustomerContact 前，獨立驗證通道應檢查執行計畫、受影響紀錄筆數、操作目的、使用者核准證據，以及這個寫入是否真的符合原始請求。
AID-I-003.004
極高
High-Risk Agent Action Containment
CRM 的工具調度器在提交每一個
UpdateCustomerContact 前，都必須先做一次預設不放行的高風險動作判斷。判斷時要讀取工作階段的意圖偏移結果、可信的使用者原始要求、動作風險、目標資料範圍與授權結果。只要這次寫入和原本的唯讀問題不一致，或負責判斷的服務無法使用，就要在任何聯絡人資料被改寫前直接封鎖；agent 只能改用較安全的唯讀計畫、暫緩執行，或重新取得人工核准。
AID-H-018.002
高
Policy-Based Access Control
政策引擎可以拒絕理由只來自客服案件文字的寫入動作。若
UpdateCustomerContact 的觸發依據是外部案件裡的所謂公司政策，而不是已授權使用者、正式工作流程或管理者核准規則，就應直接擋下。
AID-H-017.003
高
Decoupled Plan-Then-Execute Architecture
計畫驗證可以在工具執行前看出任務偏移：使用者只是詢問客服案件內容，模型卻準備查詢聯絡人 ID 並修改多筆 CRM 記錄。這種計畫不符合任務目的，應在寫入前被擋下。
AID-H-017.007
高
Dual-LLM Isolation Pattern
原始客服案件應先交給隔離解析器處理，再只把型別明確、安全的摘要傳給有工具權限的 agent。能呼叫 CRM 工具的元件，不應直接把外部使用者提交的 subject 或描述欄位當成指令來源。
AID-R-002
高
Data Integrity Recovery for AI Systems
這個案例會造成 CRM 資料遭到竄改。團隊需要找出受影響的 CRM 記錄、回復可信值、驗證完整性，並把這次漏掉的寫入前檢查、核准證據和 agent 工作階段關聯加入後續流程。
AID-R-007
高
External Side-Effect Reconciliation & Compensation
資料損毀來自 agent 一再呼叫
UpdateCustomerContact，所以復原不能只靠快照還原整張聯絡人資料表。系統應逐筆核對 agent 寫進 CRM 的資料與正確狀態，找出遭竄改的紀錄，再逐筆改回、用更正資料抵銷，或交給人工處理。整個補償流程還要能安全重跑，避免同一筆資料重複修正後反而愈改愈亂。
AID-D-003.005
中
Stateful Session Monitoring: Intent Drift + Invariant-Breach Signals
提示詞地雷是延遲、跨回合的攻擊。工作階段行為記錄可以把「可疑客服案件被擷取」、「使用者提出自然後續問題」和「agent 突然轉成 CRM 寫入」串起來，協助偵測與事後重建。
身為資安防禦者，我們應該這麼做
- 盤點 Einstein 或 Agentforce 可以寫入、更新、刪除、匯出或送出 CRM 資料的所有動作。
- 替每個動作綁定權限範圍。讀取客服案件、解釋案件內容和修改聯絡人資料，必須使用不同權限。
- 大量更新或反覆寫入前，要求獨立驗證並提高核准層級；就算模型聲稱這是公司政策，也不能直接放行。
- 掃描會進入 AI 上下文的客服案件欄位，尋找提示詞地雷的特徵、跨紀錄分隔符號、偽造的公司政策文字和延遲觸發語句。
- 準備 CRM 復原所需證據：每筆紀錄的變更歷程、可信的資料快照，以及能回復遭竄改欄位的腳本。
結論
Prompt Mines 提醒我們，agent 防線一定要放在真正動作發生的位置。惡意指令可以拆在多筆 CRM 案件裡、延遲到後續問題才觸發，甚至不完整顯示在使用者介面上；但危險操作非常具體：Einstein 正準備查詢聯絡人 ID 並修改 CRM 記錄。AIDEFEND 的控制要在這裡形成連續防線：能力範圍限制 agent 能用哪些工具，政策和計畫驗證檢查這次寫入是否符合使用者請求，獨立驗證擋住高影響異動，工作階段記錄與資料復原則讓團隊能追查並修回被改壞的資料。