无人谈论的事实:云代理需要你的登录凭证才能存在
摘要
本文讨论了云代理需要登录凭证的安全问题,并倡导一种在macOS上运行于用户浏览器中的本地代理方法,尽管存在需要设备保持清醒等权衡,但它允许监控和控制。
好的,先坦白:我开发了一个内置代理的Mac浏览器,所以我有偏见。但我已经思考这个问题好几个月了,几乎从没在这里看到讨论。每个托管代理都面临同样的问题。它生活在别人的电脑上,所以要操作你的账户,你的凭证也必须传到那里。当你让它订餐时完全没问题。这也是为什么它们永远不会帮你对账、处理工资或在广告账户中操作绑定活卡的业务。那些真正值得自动化的枯燥重复工作,正是你不能交托的东西。还有监控问题。云代理在你看不到的地方工作。自托管的代理在没什么可看的地方工作,只有日志和最后的“完成”。无论哪种情况,你都在信任摘要。所以我们选择了另一条路。代理是一个本地进程,驱动你已登录会话中的真实标签页。没有东西被交出,因为没有人可以交出。你可以监控它所在的页面和它正在输入的字段,如果它试图花费、发送、删除或发布任何东西,它会先停止并询问。MCP tokens存储在macOS钥匙串中,按代理分发,而不是一个大的全局授权。缺点是真实的,我不会假装没有。你的Mac必须保持清醒,而且仅限macOS。真的很好奇大家对此的看法。能够监控它工作是否值得放弃那种在笔记本电脑关闭时也能运行的东西的便利性?
相似文章
@dabit3: 本地逃逸的代理可以访问你的整个机器,而云中逃逸的代理基本上只获取一个……
该推文通过对比本地和云环境,阐明了云代理的必然性:本地代理逃逸可获取完整机器访问权限,而云逃逸仅能访问空租户。
运行本地代理而非云端代理的理由 #645
解释了运行本地代理而非云端代理的原因,强调了隐私和控制的优势。
Openclaw vs Hyperagent:云原生代理是否构成巨大的安全风险?
一场比较Hyperagent等云原生代理平台与OpenClaw等本地优先方法安全风险的讨论,突显了便利性与控制权之间的权衡。
浏览器代理很酷,直到一个登录界面第14次毁掉了工作流程
作者批评浏览器代理因登录界面和干扰而频繁失败,建议使用正规API或Runable等原生连接器来实现更可靠的自动化。
@anorth_chen: Peter这篇文章讲清楚了cloud agent和desktop agent的根本分界:一旦agent离开用户电脑,问题从framework变成了infra contract。 桌面agent默认了很多隐含前提:本地文件系统可信、env里…
Peter的文章阐明了cloud agent和desktop agent的根本分界,讨论了云agent在无人监督、共享硬件环境下的安全性、运行时和基础设施挑战,指出agent runtime未来会越来越像一个小型OS。