Cloudflare Precursor 持續分析滑鼠同鍵盤節奏，AI agent 過關後都要再驗

過一次關，成段 session 仍然要計分

iThome 報道，Cloudflare 推出 Precursor，bot 判斷由單一 request 拉長到成個網站工作階段。原因好直接：而家嘅自動化工具識跑 JavaScript、用真 browser 環境，甚至過到 CAPTCHA；登入或付款前驗一次，之後嗰十幾分鐘發生咩事，舊做法未必睇得到。Precursor 連過咗 Challenge 嘅 session 都會繼續計分。但係佢估嘅係行為有幾似真人，唔等於身份證明，合法 API client 同用戶授權嘅 AI agent 一樣可能冇人類手勢。

圖片：Cloudflare Docs

四組訊號拼成一段行為

網站開啟後，Cloudflare 會喺經佢處理嘅 HTML response 入面，動態加入一段輕量 JavaScript；段 code 經過混淆，每次 response 都會重新組合。佢監察 pointer 軌跡、鍵盤事件時間、輸入欄位 focus，同頁面實際可見咗幾耐；資料先喺 RAM 暫存，再定時送到 edge server。edge 端會交叉對照滑鼠活動同可見時間係咪吻合、鍵盤事件係咪喺輸入欄位有焦點時出現，再將結果累積到 session。重新整理頁面或者再過一次 Challenge，之前嘅行為痕跡唔會即刻歸零。

圖片：Cloudflare Docs

Turnstile 同 Challenge 各自做咩

Turnstile 係擺喺登入、註冊或結帳位嘅 widget，仲可以獨立用，網站唔一定要經 Cloudflare CDN；Challenge Page 會先攔住 request，做一次即場驗證；Bot Management 則係整套自動流量評分同處置系統。Precursor 長時間供應 client-side 行為訊號，再交畀 bot score、Challenge 同 Security Rules 使用。官方文件亦話佢取代舊 JavaScript Detections，開 Precursor 後應關掉 JSD。

嚴格模式會撞 API

預設 Minimize Friction 只喺背景建立 session，唔彈出 interstitial Challenge，體驗順啲，但 Cloudflare 明講冇法保證每段 session 都驗妥。Maximize Security 會要求訪客先有有效 cf_clearance cookie，冇就彈輕量 Challenge；同一 session 嘅 clearance 之後亦可能降級、失效，再要求驗多次。登入、付款同管理頁用嚴格模式有道理，全站一刀切就容易撞到手機 backend、server-to-server job、監察工具，或者冇帶 cookie 嘅 fetch。穩陣啲嘅做法係全站先低摩擦，敏感 path 先加嚴，API hostname 留返低摩擦。

鍵盤節奏唔等於按鍵內容

Cloudflare 聲稱鍵盤部分只收事件時間同節奏，唔會收實際按鍵；行為訊號會用整體 pattern 評估，唔會逐筆展示畀網站管理員，亦唔會綁去登入身份、用戶帳戶或長期 profile。咁樣同鍵盤側錄有明顯分別。但係資料仍然係持續收集、定時送去 edge 端分析，而且 Precursor Rules 只揀驗證模式，冇提供逐頁關掉收集嘅設定。NIST 嘅數碼身份指引話，打字節奏等 session monitoring 訊號涉及私隱，系統要做風險評估。Cloudflare 公開資料暫時未交代針對 Precursor 嘅保存期或獨立審核。

誤判數字仍然欠奉

Cloudflare 話 session 訊號會提高準確度、令正常訪客少遇 Challenge，但未公布 false-positive rate、額外 script 大細、流量成本或獨立效能測試。W3C 指出，有人會全程用鍵盤、眼球追蹤、語音控制、滑鼠模擬器或手震補償軟件上網；呢啲操作節奏本身可以同一般滑鼠用戶差好遠。由呢點推斷，輔助工具、remote desktop、觸控筆同高延遲環境，都係要特別觀察嘅誤判位。網站應由低摩擦模式開始，睇 bot score 分佈、Challenge 完成率、客服個案同 API 錯誤，再逐段加嚴。

邊個有得用，官方說法未對齊

iThome 報道時稱佢係 Enterprise Bot Management 新功能，Cloudflare 網誌亦放 Precursor 喺 Enterprise Bot Management 脈絡；同日 changelog 卻寫明由當日起向「所有客戶」rollout，網誌又只承諾正式推出前免費。不過 account 收到 rollout、dashboard 見到開關，唔代表最終方案一定包埋完整 bot score 功能。正式 GA 後支援邊個方案、點收費：[待確認]。

值唔值得開

對受 credential stuffing、搶購 bot 或自動化濫用困擾嘅登入同網店系統，Precursor 值得小範圍試，因為佢補到一次 Challenge 之後嗰段盲區；內容網站暫時冇必要全站強驗。現階段開低摩擦、保留 API 例外、記錄誤判，再等 Cloudflare 補齊方案同私隱資料先擴大，會係較實際嘅部署次序。

參考來源

• iThome — Cloudflare推出Precursor，以網站工作階段行為辨識AI代理與機器人流量 — original report
• Cloudflare：Introducing Precursor — 核對收集訊號、運作方式、私隱聲稱同推出安排
• Cloudflare Docs：Precursor — 核對兩種模式、API 影響、cf_clearance 同 JSD 關係
• Cloudflare Changelog：Precursor session-based detection — 核對向所有客戶 rollout 嘅官方說法
• Cloudflare Turnstile 文件 — 比較 Turnstile、Challenge 同 Precursor 嘅用途
• NIST：Session Management — 核對持續 session 監察同打字節奏訊號嘅私隱風險要求
• W3C：輸入工具同無障礙使用方法 — 核對鍵盤、眼球追蹤、語音控制同手震補償等輸入差異

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