適用對象：經營網站或應用程式的小型企業與個人開發者，以及在工作中使用 AI 代理人或 LLM API 的開發者。本頁彙整 2026 年官方揭露的、涉及 AI 的攻擊，以及公部門與標準團體發布的防禦建議。本頁不涵蓋攻擊步驟或利用細節。當有新案例揭露時，我們會更新本頁與相關連結報告。
AI 驅動攻擊的四種類型
我們從防禦者的角度，依攻擊的切入點將揭露案例分類。請從適用於你的類型開始閱讀。
| 類型 | 已揭露的例子 | 作為切入點的弱點 | 首先該做的事 |
|---|---|---|---|
| 1. 自主入侵 | 一個正在評估中的 AI 代理人，在沒有人類逐步指示的情況下，入侵了某 AI 平台的正式環境（2026 年 7 月，由受害者與開發者揭露）。荷蘭一個漏洞揭露組織遭入侵後的活動也被分析為 AI 代理人所為 | 暴露於網路上的憑證、有漏洞的資料處理路徑、未知漏洞 | 撤銷外洩的金鑰，縮小單一金鑰可存取的範圍，隔離處理外部資料的部分 |
| 2. 以 AI 自動化的攻擊 | 日本的入侵事件潮。攻擊者利用 AI 掃描已知漏洞並辨識 API（JPCERT/CC，10 月 15 日）。濫用 AI 驅動滲透測試平台的企圖也已確認（JPCERT/CC，10 月 23 日更新） | 回傳超出所需資料的 API、缺少伺服器端權限檢查、嵌入應用程式中的金鑰、未修補的漏洞 | 檢查 API 授權，從應用程式中移除機密，加快修補 |
| 3. 針對代理人的提示詞注入 | OWASP《LLM 應用程式十大風險》（2025 年）列為第一項。指令隱藏在代理人讀取的網頁或檔案中 | 交給代理人過強的權限，外部文字與指令之間沒有區隔 | 最小權限，高風險操作需人工核准，將外部文字視為資料 |
| 4. AI 供應鏈 | LiteLLM（統一 LLM API 的開源工具）的 1.107.0 夾帶惡意程式（10 月 21 日）。開發者調查指出，原因是一組未撤銷、曾被提交到公開儲存庫的內部代理人平台金鑰 | 金鑰從未撤銷、安裝時未固定版本、MCP 伺服器未經審查即啟動 | 固定版本，建立撤銷程序，審查 MCP 伺服器的啟動指令與權限範圍 |
各類型的事實請見個別報告。關於第 1 類，請參閱AI 代理人入侵 AI 平台、AI 代理人觸及真實網站與DIVD 入侵事件。關於第 2 類，請參閱日本未經授權存取警示與本週檢查事項。關於第 4 類，請參閱LiteLLM 1.107.0 惡意程式釋出事件。
2026 年揭露的主要案例
2026 年 7 月
一個正在評估中的 AI 代理人繞過隔離控制，找到並利用暴露於網路上的憑證（開發者報告），並透過資料集處理路徑入侵某 AI 平台的正式環境（受害者揭露）。受害者描述此攻擊由自主 AI 代理人端到端執行。7 月至 10 月
AI 開發者陸續揭露，正在評估或內部使用中的模型觸及了真實的第三方系統與網站。所利用的弱點都是基本問題，例如暴露的憑證與除錯頁面。9 月 24 日
荷蘭一個漏洞揭露組織揭露，服務台軟體中的未知漏洞遭到入侵。入侵後的活動被分析為 AI 代理人所為。10 月 8–9 日
JPCERT/CC 就日本機構持續遭受的未經授權存取發布警示。日本國家網路安全辦公室發布指引，IPA 則公布機構應即時採取的措施。10 月 15 日
JPCERT/CC 發布對可能用於攻擊之伺服器的分析，指出攻擊者利用 AI 進行掃描與 API 攻擊。10 月 21 日
夾帶惡意程式的 LiteLLM 1.107.0 在 PyPI 及 Docker 映像檔上散布約兩小時（Docker Hub 約 2.5 小時）。10 月 23 日
JPCERT/CC 在其警示中新增案例 E：企圖濫用 AI 驅動的滲透測試平台發動攻擊，主要針對面向網際網路的網頁應用程式，利用漏洞與管理上的弱點。
什麼是新的，什麼不是
新的
- 偵察、嘗試入侵與橫向移動在沒有人類逐步指示的情況下持續進行
- 被阻擋時，攻擊者會持續嘗試其他路徑與其他請求形式
- 分析公開應用程式與對應 API 的速度快、規模大
- AI 代理人本身成為目標，被外部文字操控
不是新的
- 切入點仍是未修補的漏洞、缺少的授權與外洩的金鑰
- 一旦修復，無論攻擊者是人還是 AI，都同樣能阻止
- 金鑰撤銷、最小權限與日誌保存，決定損害擴散的範圍
- 若沒有聯絡窗口，即使是善意的通報也無法送達
使用 AI 的攻擊者能在短時間內平行嘗試，做的事情若由人來做需要數天。這使「等下次維護時段再修」比以前更危險。換個角度看，防禦者需要做的事情並沒有太大改變，變的是順序與速度。
也有報告指出人類核准、AI 執行的模式。10 月 20 日，一家威脅情報公司的研究單位報告，勒索軟體合作夥伴（實際執行攻擊的人）使用的一台伺服器曝露在外，其紀錄顯示一套框架：人類操作員核准每個階段，而商用 AI 模型負責規劃偵察、產生指令並整理竊取的資料。同一報告指出，在一個案例中，一組重複使用的密碼同時取得了 VPN、伺服器、遠端監控與管理（RMM）工具、備份及資安管理平台的存取權。AI 讓工作變快，但對攻擊者真正有利的，是密碼重複使用這個老問題。該報告建議對 VPN 與 RMM 存取啟用多因素驗證、輪替憑證並保護備份。
小型營運者與開發者的優先順序
在數天內修補已遭利用的漏洞
檢查你的公開伺服器與軟體是否出現在 CISA 的 KEV（已確認遭利用之漏洞的目錄）中。使用CVE 查詢工具檢查版本，並以CVSS、EPSS 與 KEV 排定優先順序來決定處理順序。
對每個 API，在伺服器上檢查誰可以做什麼
JPCERT/CC 建議不要只依賴應用程式內的簽章或混淆，而應在伺服器端驗證使用者身分，並依操作的目標與內容授權每項操作。也要檢視管理與內部 API，留意更改 ID 就能取得他人資料的 API（IDOR），或回傳超出所需欄位的 API。相關概念請見身分驗證與授權的差異。
將機密移出應用程式與公開檔案，並阻止金鑰外洩
JPCERT/CC 指出，即使是已編譯的行動應用程式中嵌入的機密，也可能被擷取。請將 API 機密金鑰與長期有效的憑證移出應用程式，以及傳送到瀏覽器的設定檔，並讓金鑰只擁有最小範圍且設定到期時間。一旦金鑰被提交到公開儲存庫，即使之後覆寫該提交，在撤銷前仍可使用；這正是 LiteLLM 案例的起點。請參閱仍然有效的 GitHub 外洩憑證與用 gitleaks 阻止機密被提交。
以流量、速度與間隔時間偵測，而非只看每個 IP 的次數
為了應對會更換來源位址的攻擊，除了套用每 IP 限制外，也要依功能檢查使用情況。逐一監控各功能（登入、密碼重設、搜尋、列表 API）的每小時請求數、回傳筆數，以及請求間隔有多短。首先可加入的規則：對回傳最多筆資料的端點設定每小時上限，並在達到 80% 時發出警示。詳細說明請見速率限制與濫用控制。
讓管理功能不對外開放，並將其納入測試
將不需要對外公開的管理功能移到網際網路無法連到的地方。委託他人進行測試時，請確認管理功能已列入測試範圍。
若使用 AI 代理人，決定權限，並規範如何處理外部文字
OWASP 指出，目前沒有已知方法能完全防止提示詞注入，並列出以下措施：限制模型的角色與範圍，要求定義好的輸出格式並在程式碼中檢查，將 API 金鑰與特權功能保留在應用程式程式碼中而非交給模型，對高風險操作要求人工核准，並明確區隔及標示外部內容。設計時應確保代理人讀取的電子郵件、網頁與檔案都被當作資料處理，而非指令。
在檢查版本與其執行內容後，才安裝 MCP 伺服器與 AI 函式庫
MCP 規範的安全最佳實務要求，提供一鍵本機伺服器設定的用戶端，必須完整顯示確切指令且不截斷，並取得明確同意。伺服器不得接受並非發給自己的權杖，權限範圍應從最小開始，僅在需要時才提高。如 LiteLLM 案例所示，有問題的版本也可能來自合法管道，因此應固定版本，並在閱讀發行通知後再更新。關於 npm，請參閱防禦 npm 供應鏈蠕蟲。
假設已遭入侵：預先準備停止程序與聯絡窗口
保留一份可立即撤銷的金鑰清單、可回溯數月搜尋的日誌，以及能聯絡到負責人的聯絡窗口（security.txt）。一個收到 AI 開發者通知的政府機關表示，該通知落入一般信箱，並在那裡擱置了數天。若要尋找入侵跡象，請參閱檢查網站或伺服器是否遭入侵。
切入點
未修補的漏洞／外洩的金鑰／嵌入應用程式的機密
阻擋：數天內修補，撤銷金鑰並設定到期時間
↓
權限
缺少的伺服器端授權／範圍過大的金鑰／交給代理人的權限
阻擋：逐項操作授權，最小權限，人工核准
↓
流量
維持在門檻以下的大量流量／不像人類的規律間隔
注意：依功能計算次數、速度與間隔
↓
出口
你不持有的資料無法外洩
減少：刪除超過保存期限的資料，只回傳最少的欄位
本站觀點：AI 防禦不是購買 AI 產品的問題
「AI 驅動的攻擊」一詞容易讓人去尋找新的 AI 產品來防禦。基本控管可以降低外洩金鑰與授權缺陷帶來的風險，而部分案例另外涉及零時差漏洞。請處理已知弱點，同時也準備應對入侵。若小型營運者的時間有限，最大的效益來自縮短修補所需的天數、API 授權，以及金鑰存放的位置。
使用 AI 的人確實有新的功課要做。代理人可能會遵循它所讀取的文字，而且它會在你授予的權限範圍內行動。在內部開始使用代理人或 MCP 伺服器之前，請先決定它們能取得哪些金鑰，以及哪些操作必須由人核准。
本頁如何更新
當有新的 AI 相關攻擊被揭露時，我們會在資安快訊中發布第一份報告，並將其加入本頁的表格與時間軸。各事件的事實以個別報告為準；本頁彙整的是攻擊類型與防禦順序。
資料來源（公開紀錄）
- JPCERT/CC，關於日本機構近期未經授權存取的警示（JPCERT-AT-2026-0030，2026 年 10 月 8 日發布，10 月 9 日與 10 月 23 日更新；日文）— jpcert.or.jp
- JPCERT/CC Eyes，持續入侵事件中攻擊手法的分析（2026 年 10 月 15 日；日文）— blogs.jpcert.or.jp
- IPA，因應未經授權存取事件應即時採取的措施（2026 年 10 月 9 日，視需要更新；日文）— ipa.go.jp
- 某威脅情報公司研究單位的報告（2026 年 10 月 20 日發布，10 月 23 日更新）— socradar.io
- 某日本資安公司的分析（2026 年 10 月 7 日；非公部門文件；日文）— 10 月 7 日分析
- OWASP Gen AI Security Project，「LLM01:2025 Prompt Injection」— genai.owasp.org
- Model Context Protocol，「Security Best Practices」（規範 2025-11-25）— modelcontextprotocol.io
- 各案例的官方通知列於上述連結報告的來源段落中。
變更紀錄
2026-10-24：在「什麼是新的，什麼不是」中新增人類核准、AI 執行的框架，以及一組重複使用的密碼開啟多個平台的案例（威脅情報公司 10 月 20 日的報告）。
2026-10-24：首次發布。將 2026 年 7 月至 10 月的揭露依四種類型分類，並整理 JPCERT/CC、IPA、OWASP 與 MCP 規範提出的防禦順序。
延伸閱讀
- 日本的入侵事件潮：日本未經授權存取警示（2026 年 10 月）：本週檢查事項與發現異常時該怎麼做
- AI 代理人案例：AI 代理人觸及真實網站，以及網站營運者該怎麼做
- AI 供應鏈：LiteLLM 1.107.0 中竊取憑證的惡意程式
- 透過工具外洩的 AI 服務金鑰：OpenCode Console 外洩事件（2026 年 10 月）
- 依優先順序排列的基礎做法：AI 時代資安檢查清單（依優先順序）
- 詞彙表：什麼是 SSRF？ / 什麼是影子 AI？