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 立场无关。文章内的信息仅供参考，均不构成任何投资建议及要约，并请您遵守所在国家或地区的相关法律法规。
