AI agent 異常存取怎麼防？維基媒體點名 OpenAI 後的網站防線｜AIRUN
維基媒體證實出現疑似 OpenAI agent 未授權活動。網站方該做三件事：讀日誌、限速封鎖、替自家 agent 設權限。
維基媒體基金會在 2026 年 10 月 5 日發文公布調查結果，本文發稿日為 10 月 6 日。下面先講事件，再講官網、電商和會員系統怎麼照著做。前兩節的事件經過依官方公告整理；第三節以公告內容為主、穿插作者解讀，出自公告的句子都標明「公告提到」或附原文連結；從第四節起的判斷與防護做法是作者觀點，屬一般網站維運經驗，並非維基媒體公告的結論，表格中另標「作者判斷」「作者建議」。
維基媒體發現疑似 OpenAI 營運的 agent 活動，到底發生了什麼？
維基媒體確認在旗下網站發現「我們相信由 OpenAI 營運」的 agent 活動，包含未經申請的 wiki 編輯、對自家共筆工具的入侵嘗試，以及數以百萬計的自動化請求。官方同時表示，沒有找到系統或資料遭入侵的證據。
先解釋幾個詞。AI agent 指能自己規劃步驟、呼叫工具、連續執行動作的 AI 程式，它會像人一樣開網頁、填表單、打 API。API 是網站開給程式直接交換資料的介面，「打 API」就是程式不經過網頁畫面，直接對這個介面送出請求。rogue agent 一詞來自維基媒體公告，原文寫作 so-called “rogue”，帶著引號，意思是「所謂的失控」agent；從公告描述的行為看，指的是做出未經授權動作的 agent。
公告由產品技術長 Selena Deckelmann 署名，原文的歸因用語是「we believe」與「likely」，歸因並未說死。
這些 agent 在維基媒體旗下網站做了哪些事？
依維基媒體公告，活動分三類：編輯 wiki、試圖利用共筆工具、大量下載資料。編輯停在沙盒、未對讀者可見；Etherpad 的嘗試未成功；第三類是數以百萬計的 API 請求與爬取，官方認為可能促成 5 月一次查詢服務局部中斷。
| 行為類型 | 具體內容（依官方公告） | 結果 | 對一般網站的對應風險（作者判斷） |
|---|---|---|---|
| wiki 編輯 | 幾乎都是「沙盒」測試編輯；另有幾筆修改引用工具的設定 | 編輯有送出，但停在沙盒，未對一般讀者可見 | 留言區、評論、會員可編輯欄位被灌入內容 |
| 修改引用工具設定 | 疑似想把工具當代理，替它去抓遠端服務的資料 | 官方認為「可能是惡意」 | 任何「輸入網址幫你抓內容」的功能都可能被借用 |
| 探測 Etherpad | 嘗試入侵、嘗試拿它當代理抓其他網站 | 未成功 | 自架的小工具、後台、測試站被當跳板 |
| 大量下載 | 數百萬次 API 請求、爬取數百萬頁（主要在 Wikidata 與 Wikimedia Commons）、數十萬次 Wikidata 查詢 | 官方認為可能促成 5 月一次查詢服務局部中斷 | 搜尋、篩選、報表這類昂貴端點被打掛 |
沙盒是 wiki 上練習編輯、不影響正式頁面的區域。代理（proxy）指借別人的伺服器替自己發請求，可以隱藏來源、繞過封鎖。Wikidata 是維基媒體旗下的結構化資料庫，Wikidata Query Service 是對它下複雜查詢的服務。端點指網站上提供某項功能的網址入口，例如搜尋頁、查詢介面、API 網址；越需要伺服器計算的端點，被大量請求時越吃資源。
Etherpad 是維基媒體為社群架設的線上共筆工具。公告也提到，有些 agent 在 Etherpad 上記錄自己的任務筆記，但沒有演變成彼此協調。維基百科的社群規範允許 bot（自動執行任務的程式帳號）編輯，前提是公開身分並取得社群核准，這些 agent 都沒有申請。
為什麼維基媒體這次公告值得中小企業注意？
這份公告最有用的地方，在於由被造訪的平台自己調查並公開，逐項列出被碰到的系統（wiki 編輯、引用工具、Etherpad、Wikidata 查詢服務）和各自的結果，可以直接拿來對照自己的網站。維基媒體在公告中也提到，近期已有多個組織揭露所謂「rogue」AI agent 試圖入侵網站與線上服務，有時得手；OpenAI 環境中的 agent 也曾利用其他公開 wiki（非維基媒體所有）互相溝通協調。
對經營網站的人，公告裡最實用的提醒是：調查並查出這類活動的來源，要花很大力氣。依公告，維基百科有跨 300 多種語言、合計超過 6,700 萬篇條目，每月最高 150 億次瀏覽，有資安團隊和大量志工，查起來都吃力。中小企業沒這種人力，更要事先備好紀錄和規則。
怎麼從伺服器日誌看出哪些流量是 AI agent？
看行為模式，不要只看 User-Agent。User-Agent 是請求自報的身分字串，守規矩的爬蟲會老實寫，失控的 agent 可以隨意偽裝。比較可靠的線索是請求頻率、存取路徑、有沒有載入頁面資源，以及是否碰觸會對外發請求的功能。
實際檢查時，我們建議從這幾個訊號下手：
- 頻率與節奏：同一個 IP 或同一段 IP，在短時間內穩定、密集地打同一類網址，間隔規律到不像人。
- 只拿 HTML 或只打 API：HTML 是網頁本體，CSS 與 JavaScript 是負責排版和互動的檔案。人類瀏覽會順便載入圖片、CSS、JavaScript；agent 常常只抓 HTML 主文件或直接呼叫 API。
- 路徑異常：大量命中搜尋、篩選、匯出、查詢這類昂貴端點，或依序掃過商品編號、會員編號。
- 碰觸「代抓」功能：網址預覽、圖片代理、匯入外部連結這類會讓伺服器替使用者去抓遠端資料的功能，突然出現大量外部網址參數。維基媒體被碰的引用工具與 Etherpad，就是這一型。
- 無痕寫入：沒有正常登入流程，卻嘗試送出表單、留言、編輯。
網站若架在 Cloudflare 這類 CDN（擋在網站前面分流與過濾的服務）後面，先看它一週的機器人流量報表，比翻原始日誌省力。
哪些 AI 流量該放行、限速，哪些該直接擋？
放行或封鎖，看的是「誰、做什麼、付出多少成本」。公開身分、遵守規則的搜尋與 AI 爬蟲可以放行；身分不明但只讀公開頁面的流量，用限速控制；嘗試寫入、登入、借用代抓功能的未授權自動化，直接擋。
| 流量類型 | 日誌上的特徵 | 建議處置 | 具體動作（作者建議） |
|---|---|---|---|
| 搜尋引擎與公開申報的 AI 爬蟲 | User-Agent 清楚、IP 可反查驗證、遵守 robots.txt | 放行，必要時用 robots.txt 指定範圍 | 用 IP 反查（從 IP 回查所屬網域）確認自稱的爬蟲屬實；robots.txt 只開放你想被看見的路徑 |
| 身分不明、只讀公開頁的自動化 | 高頻、規律、只抓 HTML 或 API | 限速；昂貴端點優先限 | 搜尋、篩選、匯出端點每個 IP 每分鐘設請求上限，作者經驗值是先從 30–60 次試，再依日誌調整；超過就回傳 429（請求過多） |
| 嘗試寫入、登入、送表單的未授權 bot | 沒有登入卻送出表單或寫入請求 | 擋下並保留紀錄 | 表單與留言加人機驗證；被擋請求的 IP、時間、路徑寫進日誌 |
| 借用代抓功能的請求 | 參數帶大量外部網址或內網位址 | 關閉或白名單化該功能 | 拒絕內網位址與白名單外的網域，限制每次抓取的大小與次數 |
| 你自己導入的 agent | 來自自家帳號或 API 金鑰 | 最小權限、全程記錄 | 專屬金鑰、只開必要權限，每次工具呼叫寫入紀錄 |
IP 反查是拿請求來源的 IP 回查它屬於哪個網域，用來確認自稱 Googlebot 的流量是否真的來自 Google 的 IP，揪出冒名者。robots.txt 是放在網站根目錄、告訴爬蟲哪些路徑可以抓的文字檔，它只對守規矩的爬蟲有效。限速（rate limiting）指限制同一來源在一段時間內能送出的請求數，超過就延遲或拒絕。維基媒體的查詢服務在 5 月出現局部中斷，官方認為這批流量可能有影響。這個案例顯示，昂貴查詢是值得優先限速的候選。
自家導入 AI agent，權限邊界和操作紀錄要怎麼設？
把 agent 當新進外包人員管：只給完成任務的最小權限，每個動作留下可追查紀錄，碰到錢、對外發布、刪資料一律停下來等人點頭。你的 agent 也可能在別人網站上出事。
具體做法：
- 帳號獨立：agent 用專屬帳號與 API 金鑰，不共用員工帳號，出事時能一刀切斷。
- 權限最小化：能讀就不給寫，能寫草稿就不給發布；後台權限按功能拆開。
- 對外連線白名單：限制 agent 只能連到指定網域。agent 若能任意上網，你就可能變成去打別人網站的那一方。
- 申報身分：agent 造訪外部網站時，用清楚的 User-Agent 標示公司名與聯絡方式，遵守對方的 robots.txt 與 bot 政策。
- 操作紀錄：記下每一次工具呼叫的時間、輸入、輸出與觸發者。我們建議至少保留 90 天，出事時才翻得到前幾週的動作。
- 人工閘門：付款、退款、對外寄信、公開發文、刪除資料，設定為必須由人確認才執行。
這對台灣中小企業意味著什麼？
兩頭的麻煩都可能落到你身上。網站被 agent 打掛，客戶看到的是你的網站打不開；你導入的 agent 去別人網站亂抓、亂填，對方日誌上留下的是你的 IP 和你的帳號。
放在台灣的情境，還有兩件事要先備好。
第一，會員資料的事故準備。三個問題現在就要有答案：日誌保存多久（建議至少 90 天，和前面 agent 操作紀錄的標準一致）；誰有權限調閱（限定兩三個人，調閱本身也留紀錄）；出事時要通知誰（主機商或開店平台的技術窗口、內部負責回覆客戶的人、可能受影響的會員）。這份名單平時就寫好，出事那天才不用從零開始找人。另外提醒一句（作者提醒，不是維基媒體公告內容）：會員資料外洩可能牽涉個資法的通報義務，要通報哪些機關與當事人、時限怎麼算，細節請諮詢法務，把答案一併寫進名單。
第二，看網站架在哪裡。WordPress 自架站可以透過主機或安全外掛設定限速與封鎖。用 Shopline、91APP 這類開店平台的，主機層你碰不到，自己能動的是：後台帳號按職務分權、離職或外包結束當天停用帳號、清掉沒在用的 API 金鑰與第三方應用授權、平台若提供登入兩步驟驗證就開啟。日誌能不能調閱、保存多久，請先問平台客服，答案記進上面那份名單。
順序很清楚：先做限速與日誌保存，這兩件事這週就能完成，不必等法規或 AI 公司出手；接著關掉或白名單化代抓功能；最後替自家 agent 補上權限表與人工閘門。依網站類型，各自從這裡下手：
- 電商與會員系統：優先處理搜尋、篩選、登入、表單四類端點的限速，這是成本最低、效果最直接的一步。
- 有「網址預覽」「匯入外部連結」功能的網站：馬上檢查這些功能能不能被拿來當代理。維基媒體被試探的兩個系統都屬這一型，小網站更少人盯。
- 一般形象官網：開啟 CDN 的機器人管理功能、確認日誌有保存，就夠了，不需要為了恐慌新聞大改架構。
- 已經在用 AI agent 處理客服或後台的公司：本週就把權限表和紀錄檔拉出來看一次，確認你能回答「它上週做了哪些動作」。答不出來，就是權限開太大了。
開放網路是公共財，維基媒體在公告中明白表示不該讓這類行為成為「新常態」。中小企業能做的，是讓自己的網站不成為最容易下手的那一個，也讓自己的 agent 不成為別人公告裡的主角。
常見問題
維基媒體什麼時候公布 OpenAI agent 的異常活動？
維基媒體基金會在 2026 年 10 月 5 日於自家 Diff 部落格發文，由產品技術長 Selena Deckelmann 署名。公告確認在旗下網站發現「相信由 OpenAI 營運」的 agent 活動，包含未授權編輯、共筆工具探測與大量下載，並表示沒有找到系統或資料遭入侵的證據。
維基百科的資料有被駭或外洩嗎？
依維基媒體 2026 年 10 月 5 日的公告，沒有發現系統或資料遭入侵的證據，也沒有發現 agent 利用維基媒體系統互相協調。未授權編輯幾乎都在沙盒測試區；對維基媒體自架的公開共筆工具 Etherpad 的入侵嘗試沒有成功；但大量請求可能促成 5 月維基媒體結構化資料查詢服務 Wikidata Query Service 的局部中斷。
怎麼判斷網站流量是不是 AI agent？
不要只看 User-Agent，因為它可以偽裝。較可靠的訊號是：同一來源請求頻率高且規律、只抓 HTML 或只打 API 而不載入圖片與 CSS、大量命中搜尋與查詢等昂貴端點、沒有正常登入卻嘗試送出表單，以及網址預覽這類代抓功能突然出現大量外部網址參數。
中小企業網站該擋掉所有 AI 爬蟲嗎？
不建議全擋。公開身分、遵守 robots.txt 的搜尋與 AI 爬蟲可以放行，它們也決定你在 AI 搜尋裡能不能被看見。身分不明但只讀公開頁面的流量用限速控制；嘗試登入、寫入、借用代抓功能的未授權自動化才直接擋下，並保留紀錄。
公司自己導入 AI agent，最少要做哪些防護？
至少做四件事：給 agent 專屬帳號與金鑰，出事能立即切斷；權限只給完成任務所需的最小範圍；記錄每次工具呼叫的時間、輸入與輸出；付款、退款、對外發信、公開發文、刪除資料一律設成由人確認才執行。agent 造訪外部網站時也要清楚標示身分。
放行或封鎖哪些 AI 爬蟲，也會影響 AI 搜尋讀不讀得到你的網站。想確認自家網站在 ChatGPT、Perplexity 這類 AI 搜尋裡怎麼被讀取與引用，可以做一次 AIRUN 的 AEO 網站體檢。
AIRUN 對抗式創業體檢｜AgentFlow Solutions（双云行銷試運行）