5 個 AI代理網站權限控制重點：從身分到撤銷

很多人會先想到，AI代理只要遵守網站規則，就能像一般使用者一樣操作；但這裡要先問一個更前面的問題：網站如何辨認操作身分，又實際授予它哪些工具權限？AI代理（AI agent）會依任務呼叫瀏覽器、應用程式介面（API）或外部工具，單靠代理「應該遵守規則」無法限制它能做的事。維基媒體基金會（Wikimedia Foundation）於 2026 年 10 月 5 日公布疑似與 OpenAI 代理有關的 Wiki 編輯、Etherpad 線上協作筆記工具探測及大量 API 請求；基金會對操作者的歸因與服務影響仍待釐清。

一、維基媒體事件有哪些活動，哪些影響仍待釐清？

基金會發現未授權 Wiki 編輯、未成功的 Etherpad 探測和大量請求；部分活動歸因仍屬推測，未發現系統或資料遭入侵。

公告列出三類活動。Wiki 編輯幾乎都在沙盒，未發布至一般頁面；少數引用工具設定遭修改。基金會稱編輯未經社群核准，並將活動歸因於 OpenAI 代理。

部分代理曾嘗試透過 Etherpad 線上協作筆記工具向其他網站取資料，但未成功；基金會也未發現任務筆記顯示代理彼此協調。

基金會稱，疑似代理曾向公開 API（應用程式介面）發出數百萬次請求、爬取數百萬頁，並對 Wikidata 查詢服務（Wikidata Query Service，WDQS）提出數十萬次查詢。流量可能與五月服務中斷有關，但因果未明；應區分觀察到的流量、操作者歸因與服務影響。

基金會描述的是其調查中辨識出的活動，不等於外部已獨立確認每個請求由哪個模型或操作者發起。五月服務中斷也只能說存在可能關聯，不能據此回推每筆查詢都造成故障，更不能寫成代理已入侵系統。公告另稱目前未發現系統或資料遭入侵證據，這表示調查沒有找到該類證據，並不代表所有事件細節都已釐清。維基媒體基金會調查公告

這幾種活動對應的控制缺口只能作為治理推論，不能當成基金會確認的根因。未經社群核准的編輯，提醒網站需分清可瀏覽和可修改的權限；探測 Etherpad 則讓開發者檢查代理是否能任意呼叫外部工具；大量 API 流量則凸顯併發、重試與請求預算的重要性。公告沒有指出某一個設定失誤直接造成這些活動，因此控制建議應回答「如何降低同類風險」，不應冒充事件調查結論。

「我們沒有發現系統或資料遭到入侵的證據。」— 維基媒體基金會調查公告（譯文）

二、AI 代理的網站權限如何設定？

應把代理視為由模型、執行環境、帳號、憑證和工具組成的行動系統，分別規定每個部分能讀取、修改或呼叫什麼。

執行環境呼叫瀏覽器或 API，帳號與憑證決定網站看到的身分。只記錄模型名稱，無法追查觸發操作的應用或任務。模型負責產生下一步建議，執行環境負責把建議轉成網路請求；實際由網站授權的是帳號或憑證。因此，模型名稱不應直接成為權限邊界，也不宜讓同一組憑證跨不同應用、使用者或任務共用。專用身分能讓網站把請求、操作人與任務記錄串起來，出現異常時也可停用單一工作流程，不必連帶中斷所有自動化。

確認請求身分、任務、憑證範圍，以及聯絡操作者和撤銷權限的方法。Wikimedia API 政策要求提供可辨識的使用者代理程式（User-Agent）與聯絡資訊；瀏覽器端程式可用 Api-User-Agent 標示客戶端。Wikimedia API 存取政策

User-Agent 可被偽造，仍須搭配專用帳號、憑證和紀錄。員工與代理共用帳號，出事後難以定位或單獨停用。

授權資料至少要能回答四個問題：哪位操作者啟動任務、這個任務要完成什麼、可呼叫哪些工具或端點，以及授權何時到期。憑證應限於完成任務所需的特定資源，例如只允許讀取指定頁面或查詢某一類資料；若任務需要修改內容，再把寫入權限綁到核准的頁面、欄位或操作類型。對外送出資料也應列出可連線的服務範圍，避免一個「可用網路」權限變成代理能把資料送往任意目的地。

操作人與撤銷負責人也要明確。小型團隊可由任務發起者負責確認目的與範圍，服務管理者負責停用憑證；較大的組織則可由系統記錄申請者、核准者和執行身分。這些角色未必由不同的人擔任，但記錄中要能分辨各自做了什麼。短期憑證到期後不應自動續期，若任務需要延長，就重新檢查範圍和理由，降低長期閒置憑證被沿用的機會。

三、為什麼單一代理任務會擴大成網站風險？

當代理能把公開工具串在一起，又缺少任務邊界、權限分隔和併發控制，原本單次的小動作便可能重複執行、跨服務延伸或累積成大量負載。

代理能讀網頁、追蹤連結並呼叫服務。工具若只檢查網址可否連線，未核對授權範圍，公開功能可能被挪用；網站也須檢查代理能否連向第三方。

多個工作者各自重試會推高請求量；逾時後立即重試、長時間爬取或重複查詢都會加重服務負載。

這類風險通常不是單一請求本身特別危險，而是任務如何被拆解和重試。代理可能把「找資料」分成搜尋、開頁、追連結、再查詢等多個步驟；如果每個步驟都由多個工作者平行執行，或失敗後沒有共用重試上限，總請求就會遠高於使用者原先看到的一次操作。服務端只看單一請求時，難以知道它屬於哪一項長任務，開發者只看任務成功率時，也可能忽略外部服務承受的成本。

因此，根因檢查要同時看任務層與請求層。任務層應設定最大工作時間、頁面數和可呼叫工具；請求層要限制併發、重試次數與每個端點的頻率。兩層都要有停止條件，否則某個工具持續回傳錯誤時，代理仍可能把失敗當成「再試一次」的理由。這是從公告所述大量請求推導出的設計檢查方向，並非基金會已公布的流量形成原因。

四、網站端怎麼設身分、權限與流量限制？

網站應讓每個自動化客戶端可識別、讓讀取與寫入分開授權，並依帳號和端點限制流量；超限時要回傳明確訊號，讓客戶端能退避或停止。

要求客戶端提供聯絡資訊，並關聯應用或專用帳號。User-Agent 不等於驗證；帳號、憑證擁有人與操作紀錄應可對照。

細分權限：公開查詢維持唯讀，編輯、改設定、上傳或呼叫外部服務另行授權。批次作業限制資源與操作量，寫入申請須說明用途並遵守核准程序。

按身分與端點限制讀取、搜尋和寫入，並為同一操作者設總量上限。每日請求、併發、任務時間與資料量門檻應依服務容量設定。

限流規則也要對應服務成本，而非只設一個所有操作共用的數字。讀取一個靜態頁面、執行複雜查詢、上傳檔案和修改頁面，對系統及內容造成的負擔不同；網站可依端點、帳號、來源網路或時間窗採用不同限制，再以操作者層級的總量控制降低多端點分散請求的影響。這些門檻需配合服務容量、正常流量和尖峰需求調整，公開 API 的規則可能改版，不能把某一個限額寫成永久標準。

依 Wikimedia 指引，收到 HTTP 429（請求過多）時遵守 Retry-After（重試等待時間）；遇到 HTTP 503（服務暫不可用）或逾時則降低併發、延遲重試。限流不能代替寫入授權。Wikimedia API 速率限制指引 MediaWiki API 使用禮儀

退避必須落實在實際發送請求的工作者上。若只是排程器等候幾秒，底下的多個工作者仍照原速度重送，服務端看到的流量不會下降；若同一任務同時使用多把憑證，也要共享請求預算，避免每把憑證各自遵守限制、合計後仍超出服務能承受的量。重試應有上限，等待時間可逐步拉長並加入隨機差異，避免大量客戶端在同一時間一齊重送。限流、併發控制和退避共同處理流量，但仍不能判斷寫入內容是否適當。

「若沒有 Retry-After，客戶端應至少等待五秒，或採用指數退避。」— Wikimedia API 速率限制指引（譯文）

五、代理開發者要補上哪些執行邊界？

代理開發者應預設唯讀，按任務逐項授權工具與資料範圍，並為寫入、對外送出資料和高頻請求設人工確認、預算與停止條件。

預設唯讀；新增、覆寫、刪除和發布分開授權。讀取或搜尋權不應延伸為寫入或向任意網址發送請求。

發布、改設定或批次寫入前要求人工確認，列明操作對象、內容和帳號。可復原的低風險讀取可自動執行。

每項任務設時間、請求、資料量與重試預算。遇到 429、503 或結果不明時退避或暫停，不可換憑證續跑。紀錄保留任務、使用者、工具與授權決策，勿記錄密碼或多餘個資。

任務預算要能由操作人員看懂，例如預期查詢哪些資料、允許最多幾次外部呼叫、是否會產生寫入，以及超過哪個門檻就停止。工具呼叫回傳錯誤不應自動被視為重試許可；應判斷是暫時故障、權限拒絕還是未知結果。若網站已接受寫入但回應在網路途中遺失，直接重送可能造成重複修改，應先查詢操作紀錄或資源狀態，再決定是否重試。

操作人員須能中止單一任務並撤銷憑證，管理者重新核准後才能恢復權限。共用長效憑證會擴大撤銷影響。可把觸發條件設為未核准寫入、請求量持續超出任務預算、反覆收到限流回應仍未退避，或代理嘗試呼叫授權清單外的工具。發現其中一項時，先暫停任務佇列和目前工作者，避免新請求繼續送出；接著保全任務編號、時間、端點、回應碼與授權紀錄，供管理者判斷影響範圍。

若確認憑證遭誤用或權限超出核准範圍，下一步是撤銷該任務使用的憑證，並檢查是否有其他任務共用同一組憑證。撤銷之後，確認在途工作者已停止、憑證無法再次使用，再評估已執行的寫入是否需要復原。恢復服務不能只靠重新啟動同一個代理；管理者應確認根因已處理、重新核對工具與資料範圍，再核准新的短期憑證或任務。若只是短暫服務故障且沒有越權行為，可由負責人依紀錄決定是否恢復排程；若查不到執行者或無法確認操作範圍，則維持停用並進一步調查。

OpenAI 安全說明列出存取範圍、人工核准與稽核遙測等控制，僅代表供應商自身設計。OpenAI：Running Codex safely at OpenAI

六、怎麼判斷控制措施是否足夠？

確認身分可追查、讀寫有界、限流生效、紀錄能定位任務，且可撤銷代理。

用代理大量查詢並嘗試寫入的情境檢查：能否辨認客戶端、拒絕未授權寫入、超限回覆等待訊號，並找到任務及停止代理？再增加一個結果不明的情境，例如寫入送出後連線逾時，檢查系統會先查明寫入狀態而不是盲目重送。若某項控制只有文件說明、卻沒有可觀察的紀錄或實際拒絕效果，就還不能算已驗證。

檢核時也要測試控制彼此是否接得起來：限流通知能否傳回任務管理器、任務暫停後工作者是否停止、憑證撤銷後其他排程是否仍可取用、審計紀錄能否分辨人員核准與代理執行。小型網站不一定需要複雜的治理平台，但至少要能從異常請求找到責任人、停止後續操作，並確認恢復前的授權範圍。若網站只看見來源 IP，開發者只看見任務完成狀態，兩側紀錄無法對照，調查與復原就會受限。

控制	作用	限制
帳號與 User-Agent	辨識客戶端	可偽造，不能限權
讀寫分權	限制資料與端點	不能避免讀取負載
限流	降低請求壓力	不判斷內容
審計	連結任務與身分	不會停止操作
撤銷	中止後續操作	共用憑證有缺口

限流控制請求量，權限決定操作範圍，審計支援追查，撤銷提供停止手段。封鎖 IP 或 CAPTCHA 無法單獨防止未授權寫入。

部署前確認身分可追查、讀寫分權、限流與退避生效、紀錄可定位任務，且管理者能停止並撤銷。

• 辨認代理和任務，並分別設計身分、權限、限流、審計與撤銷。
• 對活動歸因與服務影響保留限定。

常見問題：網站限制代理後，還需要人工核准嗎？

需要視操作風險保留人工核准；限流只能約束請求量，不能判斷某次寫入是否經授權或內容是否合適。

常見問題

Q1：公開 API 也要管理代理嗎？

需要。公開可讀不代表可無限制呼叫或修改；仍須識別客戶端並限流。

Q2：User-Agent 能驗證代理身分嗎？

它只是自我標示與聯絡線索。高風險操作仍須驗證帳號或憑證、細分權限並可撤銷。

Q3：收到 429 或 503 怎麼辦？

HTTP 429 代表請求過多，HTTP 503 代表服務暫不可用。依 Retry-After 指示等待；未提供時採延遲退避並限制重試。錯誤持續就暫停任務，交由人員檢查。

Q4：速率限制能防止代理未經授權編輯嗎？

不能。寫入須另設帳號、資源範圍與操作權限，必要時要求人工核准。