随着 AI 代理变得更加复杂和自主,一个基本问题正在浮现:代理应该使用用户凭证运行,还是需要自己独特的身份标识?这不仅仅是一个技术问题——它是一个关乎信任和安全的关键决策,将塑造我们如何构建可靠、负责的 AI 系统。
\n\n当一位工程师提出疑问时,这个问题引起了广泛关注:\"为什么我们不能直接把用户的 OIDC 令牌传递给代理?为什么要用单独的代理身份来把事情复杂化?\"答案揭示了我们 AI 驱动未来中信任、安全和治理的更深层含义。
\n\n对于当今许多 AI 代理来说,用户身份传播机制运作得很好。考虑一个帮助开发人员调试失败 Pod 的 Kubernetes 故障排查代理。当用户询问\"为什么我的 Pod 失败了?\"时,代理会调查 Pod 事件、日志和配置——所有这些都在用户现有的 RBAC 权限范围内。代理充当智能中介,但用户对操作和结果保持完全责任。
\n\n当代理作为复杂工具运行时,这种方法是成功的:它们在用户的会话时间范围内工作,执行明确由用户发起的操作,并维持用户的问责性。信任模型保持简单且熟悉——代理仅仅是用户能力的延伸。
\n\n然而,随着代理变得更加自主和强大,这种简单模型会以造成重大信任和安全挑战的方式崩溃。
\n\n想象一位营销经理要求 AI 代理验证新营销活动的 GDPR 合规性。这位经理拥有读写营销内容的权限,但合规代理需要更广泛的访问权限:扫描所有部门的营销数据、访问审计日志、将客户数据与隐私法规交叉引用,以及分析历史合规模式。
\n\n使用经理的令牌会造成一个不可能的选择:要么代理因无法访问必要资源而失败,要么经理获得他们不需要也不应该拥有的危险性广泛权限。这两个选项都无法有效地满足安全或运营需求。
\n\n更令人担忧的是自主决策带来的问责问题。考虑一个负责\"优化硬件采购\"的供应链优化代理。用户从未明确授权访问财务记录或与供应商 API 集成,但代理确定这些操作对于完成优化请求是必要的。
\n\n当代理做出的自动采购订单出错时,谁应该承担责任?是提出高级别请求的用户,还是根据对该请求的解释做出具体自主决策的代理?仅使用用户身份时,一切都归因于用户——这在权威和问责之间造成了危险的脱节。
\n\n这种归因鸿沟对于合规性、审计追踪和风险管理变得至关重要。组织需要追溯的不仅仅是发生了什么,还要追溯链中的每个决策是由谁或什么做出的:用户意图 → 代理解释 → 代理决策 → 系统操作。
\n\n解决方案不是在用户身份和代理身份之间做选择——而是认识到两者都是必要的。这反映了服务网格架构的经验教训,在零信任中需要同时考虑用户身份和工作负载身份。
\n\n在这种双重模型中,代理在用户授权的权限范围内运行,同时为其做出的具体决策维护自己的身份。用户授予代理\"优化供应链\"的权限,但代理的身份控制它可以访问哪些资源以及在该范围内可以执行哪些操作。
\n\n这种方法提供了几个信任优势:更清晰的决策归因、更精确的权限边界、更好的审计追踪,以及独立于用户权限撤销或修改代理能力的能力。技术实现可能利用现有框架,如用于工作负载身份的 SPIFFE,或扩展 OAuth 2.0 以支持代理特定的流程。
\n\n双重身份模型还支持更复杂的场景,如代理间委托,其中一个代理授权另一个代理执行特定任务——每个代理都维护自己的身份和问责性。
\n\n正确处理代理身份不仅仅是一个技术挑战——它是构建组织可以大规模信任的 AI 系统的基础。随着代理变得更加自主,我们需要提供清晰归因、适当授权和强大治理的身份框架。
\n\n社区仍在研究代理交互的委托机制、撤销策略和认证协议。但有一点是明确的——\"只使用用户令牌\"的简单时代已经过去了。值得信赖的 AI 的未来取决于以安全和问责作为主要设计原则来解决这些身份挑战。
", "source_hash": "sha256:6202ae7e8fc88d99690c8da7abc2179bddfc40d7d37db3a6f6cca53f736c4934", "model": "claude-sonnet-4-5-20250929", "generated_at": "2026-01-02T01:53:10.428043+00:00" }