AI 代理的“God Mode”问题（以及为何标准 OAuth 不足）

Source: Dev.to

我们在 AI 代理生态系统中遇到了瓶颈，这并不是关于推理能力或上下文窗口的问题，而是一个基础设施问题。

目前，自治 AI 代理的大规模采用被单一且关键的瓶颈卡住了：“上帝模式” 访问。

作为开发者，我们希望构建能够与现实世界交互的代理——读取邮件、摘要文档、创建日历邀请。但一旦我们尝试将代理连接到用户数据，就会立刻撞上标准 OAuth 的限制。

全有或全无的陷阱

以一个简单的 Gmail 集成为例。

设想你正在构建一个唯一任务是根据用户日历起草邮件回复的代理。要让代理通过 Gmail API 撰写草稿，标准 OAuth 强迫你请求的作用域同时也授予 发送 邮件的权限。

仅仅为了让代理写草稿，你就被迫向用户索要通往王国的大门钥匙。

不足为奇的是，终端用户害怕将无限制的访问权交给自治系统。一次提示注入或幻觉，代理就可能向全公司发送邮件。

开发者的困境

由于 OAuth 缺乏针对 AI 的细粒度、上下文感知的边界，全部负担都落在我们身上。

为了让代理在企业或严肃的消费场景中安全使用，开发者们浪费了数月的工程时间去构建自定义、符合 SOC‑2 标准的数据摄取管道和代理层。我们不是专注于核心代理逻辑，而是构建复杂的中间件，仅仅是为了防止代理失控。

行业如何解决这个问题？

我的团队和我一直在专注这个问题。我们得出结论，需要一个新的基础设施层——Agent Access Security Broker（AASB）——作为实时、上下文感知的代理，位于自治代理与用户数据之间。我们正从头开始构建它，以为开发者提供开箱即用的细粒度控制（例如，在代理层强制执行严格的“仅草稿”策略，而不受 OAuth 作用域的限制）。

面向社区的开放问题

如果你正在构建涉及敏感用户数据的多代理系统：

• 你是如何限制代理行为的？ 你是自行搭建代理服务器吗？还是依赖系统提示（感觉风险较大）？
• 你是否在使用模型上下文协议（MCP） 来处理安全边界？
• 你如何处理信任的用户体验？ 你如何说服用户相信你的代理不会意外删除他们的数据库或发送恶意邮件？

我很想了解你们用于保持代理沙箱化的架构和变通方案。