AI 拿著用戶的賬號密碼進入平臺，究竟是在行使用戶的權利，還是在未經許可的侵入？
作者：劉紅林律師，曼昆區塊鏈法律服務
2025 年 12 月，字節跳動推出了豆包手機助手技術預覽版，AI 可以直接操作手機——用戶說一句話，它會自動打開京東、淘寶、美團等平臺比價，輔助完成下單流程。2026 年 1 月，阿里千問 App 上線了"一句話點外賣"功能，用戶說出"幫我點杯咖啡"，AI 自動完成選店、比價、下單和支付，整個過程無需跳轉另一個 App。
這兩款產品的思路都是讓 AI 從"回答問題"變成"代替做事"。很多創業者認為這是即將到來的美好未來，但美國法院最近的一項判決，讓業界不得不重新審視一個根本問題：
AI 拿著用戶的賬號密碼進入平臺，究竟是在行使用戶的權利，還是在未經許可的侵入？
故事要從亞馬遜講起。
2026 年 3 月 9 日，美國加州北區聯邦法院裁定，AI 公司 Perplexity 通過其瀏覽器 Comet，在獲得用戶許可但未經 Amazon 授權的情況下訪問用戶受密碼保護的賬戶，因《計算機欺詐和濫用法》（CFAA）及《加州刑法典》第 502 條承擔法律責任。
法院發佈臨時禁令，禁止 Perplexity 繼續使用 AI 代理訪問 Amazon 系統，並責令其銷燬已獲取的全部數據。
本案的核心確立了：用戶授權不能替代平臺授權，獲得用戶憑證不等於獲得平臺准入許可。
這個原則，幾乎會直接決定未來所有 AI 代理產品的命運。
到底發生了什麼事？
2025 年，AI 搜索公司 Perplexity 推出了一款名為"Comet"的瀏覽器，主打功能是"AI 代理"（AI Agent）。當用戶希望 Comet 幫自己在 Amazon 上購物時，只需提供賬戶憑證，Comet 便會以用戶的身份登錄、瀏覽、比價、甚至下單。
這聽起來似乎只是用戶的"AI 助手"，但 Amazon 並不這麼認為。
Amazon 向法院提起訴訟，指控 Perplexity 的行為構成未經授權的計算機入侵。Amazon 認為，儘管 Comet 獲得了個別用戶的同意，但它從未獲得 Amazon 作為平臺的授權，其行為實質上是在"擅自闖入"Amazon 的計算機系統。
《計算機欺詐和濫用法》（CFAA）是美國聯邦層面規制計算機入侵行為的主要法律。根據該條款，構成違法需要滿足五個要件：
故意訪問計算機、未經授權或超越授權訪問、因此獲取信息、涉及州際或外國通信、一年內造成至少 5000 美元的損失。
法院認定，Amazon 提供的證據已經初步滿足上述要件。
關於"未經授權"的認定，法院援引了第九巡迴法院在 Facebook, Inc. v. Power Ventures, Inc.（2016）案中的先例。該案確立了關鍵原則："用戶授予的同意，不足以在平臺明確撤銷許可後繼續構成有效授權。"
換句話說，用戶同意和平臺授權是兩個獨立層面的問題，不能相互替代。
作為州法層面的補充，《加州刑法典》第 502(c)(7) 條禁止"明知且未經許可訪問或促使訪問任何計算機、計算機系統或計算機網絡"。法院認為，基於與 CFAA 分析相同的理由，Amazon 在該項指控上也展現了較高的勝訴可能性。
法院在這個案子裡就確立了一件事：
用戶授權≠平臺授權。
這意味著，哪怕用戶把自己的賬號密碼交給你，讓你幫他操作，但只要平臺說"不同意"，你的訪問就是非法的。
這跟以前很多人理解的那套邏輯完全不一樣。很多人以為：只要用戶同意了，那 AI 幫用戶做點事情有什麼問題？現在法院明確告訴你——不行。
聊完這個案子，創業者最關心的問題來了：我的 AI 產品到底怎麼做才安全？
紅林律師首先建議大家把握這三條紅線：
紅線一：拿著用戶的賬號密碼去操作電商平臺。這是 Perplexity 踩到的坑。只要你拿著用戶的賬號密碼登錄了 Amazon、京東、淘寶這些平臺，然後幫用戶完成了購物、下單、評論等操作，而平臺又明確表示反對這個行為——那你就在違法的邊緣試探了。
紅線二：訪問平臺明確標註為"密碼保護"的區域。法院在這個案子裡特別強調了一點：Comet 訪問的是 Amazon"密碼保護的部分"。這話什麼意思？就是是說，如果只是抓取公開網頁上的信息，可能風險還沒那麼大；但一旦涉及登錄後的會員區、訂單管理、個人中心這些需要密碼才能進去的地方，法律風險會急劇上升。
紅線三：收到平臺警告後還在繼續運營。本案中 Amazon 發出的停止侵權函成為認定"未經授權"的關鍵證據。這也提醒 AI 公司：收到平臺警告後繼續運營的行為，將被視為明知違法而繼續訪問，極大地增加敗訴風險。
其次，基於用戶授權不等於平臺授權的邏輯，建議一個合規的 AI 代理產品，應當建立起兩重授權審查機制：
第一重是用戶層面的授權確認。 你的產品確實需要獲得用戶的明確同意，這是底線。但光有這一層不夠。
第二重是平臺層面的授權審查。 在產品構思的最初階段，開發團隊就不能只考慮"用戶需要什麼"，還必須回答"平臺是否允許"。如果沒有獲得平臺的明確授權，哪怕用戶求著你幫他操作，這事兒也別幹。
最後，儘量走「官方 API 接口」的路徑。未來一定會有希望顛覆舊秩序的平臺開始探索"受控的開放"模式，通過官方 API 接口提供有限度的代理訪問能力，既滿足用戶需求，又保持平臺控制權。
比如，在中國市場，千問接入淘寶、支付寶，走的是"生態內整合"路線——通過官方接口和工具的調用，在阿里系內部已經獲得了平臺的"准入許可"。
如果能走官方 API 接口的路徑，法律風險一定比直接模擬用戶登錄要小得多。
畢竟，只有活下來的公司，才有資格談顛覆。
免責聲明：作為區塊鏈信息平臺，本站所發佈文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。文章內的信息僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
歡迎加入 Web3Caff 官方社群：X(Twitter)賬號丨Web3Caff Research X(Twitter)賬號丨微信讀者群丨微信公眾號
