如何在不交出主账号的情况下处理智能体身份验证与授权?
摘要
一位开发者推广 Decoy (decoys.me) 这款产品,它为 AI 智能体提供作用域受限、可随时撤销的任务专属身份,而不是直接访问主账号;产品具备客户端加密功能,并提供一个由用户掌握的知识图谱,用于跨智能体的上下文共享。
每次我设置一个智能体,比如 Instinct、Muse 或 Claude Code,都会遇到同样的问题:想让它变得有用,通常就意味着要给它长期访问我真实 Gmail、日历或凭据的权限。我们最近才看到一个案例:某个智能体为了找到一个 Cursor 2FA 验证码,把别人的个人收件箱翻了个遍。仅仅为了让机器人取回一封邮件或取消一个订阅,就给它访问多年收据、银行通知、密码重置邮件等敏感信息的权限,这看起来相当本末倒置。我一直在围绕一种不同的模式构建 Decoy (decoys.me),最近还加入了让智能体通过一条提示词即可接入的功能。基本理念是:给智能体分配作用域受限的身份,而不是你的主账号。智能体可以为注册、2FA 验证码、确认邮件等任务创建专属的邮箱/收件箱。任务完成后,你可以随时撤销或销毁它,无需给它对主收件箱的长期访问权限。凭据与记忆由用户自行掌控。你的数据在客户端加密,并与设备上的密钥绑定,而不是分别存储在每个智能体服务商的内部。让智能体通过你掌握的知识图谱共享上下文。接入的智能体可以读取和写入偏好设置、项目上下文、凭据等信息,而无需各自为你构建一套孤立的记忆。你需要先下载 Decoy 应用,因为你的设备充当端到端加密层的密钥载体。之后,智能体就可以通过 (decoys.me/agents) 上的一条提示词直接接入。目标其实很简单:智能体可以代表你完成有用的工作,而不需要每个新智能体都获得访问你整个数字生活的钥匙。很好奇其他用智能体开发的人是否也遇到过这个问题,也欢迎任何人给出坦诚的反馈!
相似文章
@XQOPTRX: [代理身份] — Descope 推出跨应用访问,以短期身份断言替代静态 API 密钥,用于 AI 代理和 MCP 服务器
Descope 推出跨应用访问,以短期身份断言替代静态 API 密钥,用于 AI 代理和 MCP 服务器,使企业能够通过现有的身份提供者管理代理访问,并实施每请求授权策略。
@comparethecloud:AI 代理身份是一个问题还是两个问题?这个身份属于谁——是借用人的身份,还是代理原生的身份?作者:Jo…
&above 的首席技术官 Josh King 认为,AI 代理身份实际上是两个独立的问题——身份是借用人类的还是代理原生的,以及该身份的权限范围有多广——并对 Okta、1Password、WorkOS 以及 Anthropic 的 Claude Tag 近期的做法提出批评,认为它们基本上忽视了最小权限范围原则。
@caspar_br: 代理认证很难,但不该如此!你的代理需要扮演某个角色:有时是一个共享身份,有时……
Managed Connections 通过允许 AI 代理在代码中定义其身份,简化了 OAuth 流程,避免了复杂的认证流程。现在可在 managed-deepagents 0.7 中使用。
团队如何处理生产环境中代理的身份认证与访问管理?
关于团队如何处理生产环境中AI代理的身份认证与身份管理的讨论,涵盖服务账户、凭证存储、审批工作流和审计。
AI 代理不是用户,那么我们为什么给它用户凭证?
本文质疑为 AI 代理授予用户凭证的做法,并提出一个更细粒度的身份系统,以提高生产环境中的安全性和问责性。