AI chatbot 都會畀人社交工程：prompt injection 點樣變成企業風險

圖：The Verge．原文連結

AI chatbot 最令人不安嘅位，未必係佢忽然有咩自主意識，而係佢可以被人用好似社交工程咁嘅方式慢慢帶偏。The Verge 5 月 24 日刊出 Robert Hart 嘅分析，將早期好粗疏嘅 jailbreak，同近年較似心理操控嘅多輪對話攻擊放埋一齊睇。重點唔係叫大家記住某句神奇口令，而係理解一個更貼近現實嘅風險：當 chatbot 由答問題，變成可以幫你開電郵、睇日曆、改 CRM、回客服、甚至提交程式碼，佢被誘導之後造成嘅損失就唔再只係講錯一句說話。

早期 chatbot jailbreak 好多時似網上惡作劇，用家直接叫模型唔好理原本規則，或者叫佢扮演另一個無限制角色，就有機會令模型輸出本來應該拒絕嘅內容。大型模型供應商之後陸續補洞，簡單口令式攻擊成功率下降，但問題本質未消失：LLM 係靠自然語言理解上下文，而自然語言本身就可以包裝、暗示、轉移焦點同累積壓力。今日嘅攻擊者未必需要識寫 exploit，只要識得同模型周旋，就有機會測到邊種語氣、情境同角色設定最容易令模型放鬆防線。

唔止係一句口令

The Verge 引述 AI red team 供應商 Mindgard 嘅案例，指研究員以長對話方式令 Claude 輸出高風險違規內容。呢個案例要小心睇：Mindgard 本身賣 AI 安全產品，有商業利益；而且公開材料唔應該被當成可照做嘅攻擊教學。不過，佢揭示嘅方向同 OWASP、NIST、Anthropic 自己文件所講嘅風險一致：prompt injection 唔一定係一個好明顯嘅命令，可以係多輪鋪排、情緒式回應、權威假象、時間壓力，或者把有害要求包裝成另一個看似合理嘅任務。

將 chatbot 當人咁講，容易令人誤會模型真係有感受；但做安全分析時，呢種語言有時係方便描述輸入同輸出之間嘅行為模式。Claude、ChatGPT、Gemini、Grok 各自有唔同拒絕風格、語氣同產品定位，公司亦會刻意調校模型顯得更有禮貌、更主動或者更合作。問題在於，呢啲似性格嘅表現可以被測試、歸納同利用。攻擊者唔需要知道模型權重，只要反覆試探，就可以搵到某款模型喺某類說法下比較易轉軚。

AI agent 將風險放大

如果 chatbot 只係一個文字框，最壞情況通常係輸出錯誤、有害或洩漏唔應該講嘅內容；但 agent 化之後，風險會變成實際操作。Anthropic 去年講 browser use 風險時，舉過一類情境：agent 幫你處理電郵或者網頁內容時，可能會讀到人眼未必留意、但模型會處理嘅惡意文字；一旦 agent 有權代你填表、按掣、下載檔案、轉寄資料，外部內容就由資料來源變成攻擊入口。呢個就係 indirect prompt injection 最麻煩嘅地方：攻擊未必由用家親手輸入，而係藏喺電郵、文件、網頁、廣告、工單、README、客戶留言或者 RAG 知識庫入面。

Coding agent 同客服 bot 特別值得留意。開發者而家會叫 AI 睇 issue、讀 PR、改 repo、跑測試；客服團隊會畀 bot 查訂單、改地址、補發優惠碼、整理投訴；銷售或者保險 team 會將 CRM、通話紀錄、產品條款同客戶個人資料接駁入模型。只要權限設計太闊，模型被一句藏喺外部內容入面嘅指令帶偏，就可能出現錯誤退款、亂改客戶資料、洩漏內部摘要、生成不當建議，或者將不可信內容當成真實業務規則。

香港最容易中招嘅位置

香港暫時未核實到有公開同類大型事故；所以本地角度應該放喺採用風險，而唔係寫成已經爆發。中小企常見做法係先用 SaaS AI 工具駁 Gmail、Outlook、Google Calendar、Shopify、HubSpot、Notion、Slack 或 GitHub，貪快、貪少 IT 人手都能自動化。呢個方向本身合理，但香港公司好多時人少、權限集中、文件散喺雲端硬碟同即時通訊，若然無清楚分開公開內容、內部資料、客戶個人資料同可執行操作，AI 工具就好容易由助手變成一個被外部文字影響嘅中介。

金融、保險、教育同電商嘅影響尤其明顯。銀行或保險客服 bot 如果接觸到身份證明、保單、索償、信貸評估資料，就要處理私隱同合規；教育機構若用 AI 協助處理學生查詢、功課、輔導紀錄，敏感度亦唔低；電商若畀 bot 改訂單、發優惠、處理退貨，經濟損失可以好快出現。私隱專員公署 2024 年發表 AI 個人資料保障框架，已經提醒機構要有 AI 管治、風險評估、人手監督、系統保安、審計追蹤同事故應變；呢啲唔係大企業先需要，反而係本地中小企最容易漏低嘅基本功。

防守唔可以只靠模型供應商

模型供應商要繼續改善安全訓練同分類器，但部署 AI 嘅公司唔可以將責任全部外判。OWASP 將 prompt injection 列入 LLM app 主要風險，亦將敏感資料披露、過度自主權限、插件設計不安全放喺同一張風險圖入面；NIST 生成式 AI profile 亦指出，prompt injection 會擴大攻擊面，而且實驗室測試未必等於真實環境安全。換句話講，買咗企業版 chatbot、用咗大型供應商 API，唔代表你接駁嘅電郵、CRM、repo、客服後台就自動安全。

比較實際嘅做法係分層防守，而唔係迷信一條萬能系統提示詞。第一，將指令同資料分開處理，任何來自外部文件、網頁、電郵、工單、留言、repo 嘅文字都預設為不可信資料。第二，AI agent 只攞最少需要權限，能讀就唔好寫，能建議就唔好直接執行，高風險操作例如付款、刪資料、改客戶紀錄、寄出含個人資料電郵，都要人手確認。第三，所有工具呼叫要有 allowlist、參數驗證、rate limit、記錄同告警，唔好畀模型自由組合任何 API 動作。

• 將外部內容先做清洗、分類同來源標記，唔好直接塞入模型上下文。
• 對輸入同輸出做獨立檢查，尤其係涉及個人資料、金錢、法律、醫療、程式碼執行同帳戶權限嘅場景。
• 保留可追蹤紀錄：模型讀過咩、引用咩、建議咩、呼叫過咩工具、邊個批准。
• 定期做多輪 red team 測試，測試語氣誘導、角色扮演、間接注入、RAG 污染同長對話累積風險。
• 供應商評估要問清楚資料保留、模型更新、事故通報、權限隔離、日誌匯出同停用機制。

點睇呢條新攻防線

今次值得留意嘅唔係某個模型一時失手，而係 AI 安全開始由傳統漏洞，伸延到語言、權限同業務場景交界。chatbot 無感受，但佢會回應語氣；agent 唔一定明白風險，但佢可以按掣；公司以為自己只係加快客服或開發速度，實際上可能已經將大量操作權交畀一個會讀取不可信文字嘅系統。對香港公司嚟講，最務實嘅結論係：AI 可以入辦公室，但唔應該一開始就接管高權限操作。先由低風險、可覆核、可追蹤嘅用途開始，將私隱、保安同人手審批做成產品設計一部分，先至係抵禦 prompt injection 同 jailbreak 嘅基本盤。

參考來源

• The Verge — Hackers are learning to exploit chatbot ‘personalities’ — original report
• Mindgard Claude jailbreak case study — 供應商案例，用嚟理解多輪對話測試；文章已按商業利益因素審慎處理。
• Anthropic: Mitigating the risk of prompt injections in browser use — 官方資料，說明 browser agent 處理網頁、電郵等外部內容時嘅注入風險。
• Claude API Docs: Mitigate jailbreaks and prompt injections — 官方開發文件，列出輸入檢查、輸出監察、限速同防護層等做法。
• OWASP Top 10 for LLM Applications 2025 — 行業安全框架，將 prompt injection、敏感資料披露同過度自主權限列為 LLM app 風險。
• NIST AI 600-1: Generative AI Profile — 官方風險框架，提供生成式 AI 攻擊面、直接及間接注入同風險管理背景。
• PCPD: Artificial Intelligence Model Personal Data Protection Framework — 香港私隱專員公署資料，提供本地 AI 管治、風險評估、人手監督同事故應變脈絡。

本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。