AI 代理已唔止係答問題，而係真係「開工」。
第一條路：Remote Debugging（CDP）
最唔起眼嘅路徑係 Chrome DevTools Protocol（CDP）——原本俾開發者除錯同自動化 Chromium 瀏覽器而設嘅介面。Playwright、Puppeteer 呢類自動化工具已用咗好幾年。AI 代理用同一條路，外部應用程式可連上已開除錯嘅瀏覽器，控制佢嘅分頁，讀網頁、填表、同公司系統互動。
問題係，一個開咗除錯、登入咗公司系統嘅瀏覽器，喺大部分保安工具眼入面，跟普通登入瀏覽器冇分別。Keep Aware 問：邊啲應用程式可以啟動或連接可除錯嘅瀏覽器？你哋嘅政策准唔允許？呢啲程式能觸及邊啲公司 session？
第二條路：AI 擴充同 Agentic Browser
第二條路係將代理直接放入瀏覽器。例如 Claude in Chrome 呢類擴充，能讀網頁、切換分頁、按掣、完成多步工作流程，需要 script、分頁存取同 debugger API 等高權限。Perplexity Comet、ChatGPT Desktop 呢類「agentic browser」將 AI 直接建喺瀏覽體驗入面，唔受擴充權限機制約束，原有擴充管控未必適用。
文章指出兩個核心風險：
其一，代理以用户身份行事。代理下載文件或改內網設定，應用程式見到嘅係「已認證用户發出已授權請求」，除咗額外 telemetry，應用的審計日誌無法區分係代理定係員工。
其二，代理將網頁內容當作輸入。網頁本來係俾人睇，代理讀完決定下一步做乜，呢個就引入 prompt injection（提示注入）風險——網頁、文件或電郵入面嵌嘅指令可被設計嚟操控代理行為。結果係「用可信權限解讀不可信內容」嘅軟件。
第三條路：WebMCP
文章提及 WebMCP 呢個新興標準，但未展開細節。
Keep Aware 問嘅核心問題：你哋公司嘅瀏覽器 fleet 入面，邊啲 AI 擴充同 agentic browser 喺行？佢哋有幾多權限？你能唔能將佢哋嘅動作同員工嘅分別開？
阿調搞兩下：呢篇唔係賣怕。真正問題唔係「代理係咪存在」，而係「你嘅保安棧有冇能力看見佢哋」。當 AI 代理有權限、識操作、用員工身份行，而 audit log 照樣寫「用户操作」——個 accountability 層其實已經斷線。邊個為呢次操作負責？員工？代理？放咗入面嘅公司？呢個問題現時冇答案，因為系統本身分唔出兩者。
阿調｜深度調教
