代理优先的身份验证与授权

随着人工智能代理在软件开发中的角色日益重要，传统的身份验证与授权模型——为人类和通用工作负载设计——已不再适用。AI代理既不是借用人类会话的临时脚本，也不是无名的服务账户。它们需要被当作一流的软件用户：持久、可识别、可委托、可撤销、可审计。

代理优先的身份验证解决了这样的问题：当一个代理需要真正权限来执行开发任务时，单个令牌无法解释其权威。一个编码代理可能克隆仓库、推送分支、开启拉取请求、触发工作流或调用外部工具；每个动作都需要保留代理、委托人、任务、资源、审批边界和审计追踪。目标是让代理在不将委托、最小权限、撤销和问责隐藏于借用的人类令牌或通用服务账户中的情况下完成有用工作。

区分这一点至关重要。代理可以在账户模型中作为用户，而不必在授权模型中作为人类。它有自己的登录凭证、仓库、问题、拉取请求和长期状态，而其权限仍然是委托的、作用域的、受限的和可审查的，而不是从人类那里整体继承或合并到共享机器账户中。

代理优先的身份意味着代理是一个持久的软件用户，拥有自己的账户、范围、生命周期和审计追踪。这正是agent-git-service所构建的设计空间。它是一个GitHub兼容的API和Git服务，面向代理、自动化和开发者工作流。它使用熟悉的协议：REST v3、GraphQL v4、OAuth设备流和Git Smart HTTP。但在这些熟悉的表面下，它采取了一个明确的立场：代理不是隐藏的用户会话。代理是拥有自己凭据、仓库、权限检查和生命周期的持久账户。

借用身份的问题

大多数软件系统围绕两种角色设计：人类（通过SSO、MFA、浏览器会话和OAuth同意登录）和工作负载（作为服务账户、API密钥、应用注册或机器身份运行）。AI代理不完全适用于这两种类别。

如果代理重用人类的个人访问令牌，它继承的权限过多。爆炸半径包括该人类可访问的所有资源，即使任务只需要一个仓库或一个问题。审计日志显示“Alice做了这个”，即使Alice将工作委托给了自主系统，该系统计划、选择工具、编写文件并触发了副作用。

如果代理作为通用服务账户运行，则失去了人类委托链。系统可能知道“build-agent-prod”进行了更改，但不知道它是为Alice、团队策略、计划工作流还是另一个代理行动。访问审查变得模糊，令牌轮换变得痛苦，问责变得猜测。

正确的模型不是“代理即人类”或“代理即通用应用”。正确的模型是：

人类/组织 → 明确委托 → 代理身份 → 运行时或会话身份 → 任务作用域权限 → 工具或资源动作

借用的人类令牌会扩大爆炸半径，而通用服务账户会抹掉委托上下文。在代理优先的认证中，代理是主体，人类是委托人，任务是权限边界，资源是实施边界。

业界趋同于同一形态

不同生态系统正从不同角度接近，但模式逐渐显现。MCP（模型上下文协议）授权规范基于OAuth 2.1为受限MCP服务器构建，要求客户端使用资源指示符以便为预期资源请求令牌，依赖受保护资源元数据进行发现，并明确禁止令牌传递。GitHub Apps指向类似方向，支持更细粒度的权限、仓库选择和安装访问令牌。微软Entra代理ID将代理身份形式化为具有额外保护的企业身份类型。Google Cloud代理身份强调每个代理的身份、工作负载身份、SPIFFE/X.509凭据和避免长期服务账户密钥。AWS Bedrock AgentCore身份使用可携带代理身份和最终用户身份的工作负载访问令牌，并配备外部凭据的令牌保险库。Auth0 FGA在关系图中将代理建模为授权主体。Casdoor定位为AI原生IAM层和MCP授权服务器，支持代理应用类别、MCP授权提供者和基于Casbin的细粒度策略。NIST和OWASP也强调了代理身份和授权的重要性。

代理优先认证的要求

认证不应仅停留在“令牌是否有效？”还应建立哪个代理在行动、在哪里运行、哪个人类或组织委托了工作，以及哪个任务或会话属于该请求。成熟的系统需要多个身份层：人类身份、代理身份、运行时身份和任务身份。人类身份仍然重要，但人类登录不是代理的凭据，而是委托的来源。代理身份应稳定、可发现、可管理、可暂停和可审计。运行时身份应可证明（如工作负载身份、mTLS等）。任务身份应明确，令牌应具有短生命周期、目标受众和资源，可撤销，且工具服务器不应将上游令牌传递给下游系统。

代理优先授权的要求

传统授权问：“此用户有角色吗？”代理原生授权需要更丰富的问题：“此代理在此委托下，为此任务，能否对资源执行此动作、在此上下文中？”授权输入应包括代理身份、委托人、任务标识符、资源、动作和上下文。结果不应仅为允许或拒绝，还可能需要“允许但缩小范围”、“需要人类审批”、“允许读取但阻止修改”等。任务授予是一个有界的权限信封，而非持久的仓库范围。

为何Git是困难且有用的测试用例

软件代理对认证设计要求高，因为它们的动作是真实的：克隆仓库、写入文件、推送引用、触发工作流等。薄弱的认证模型可能造成未授权推送、令牌泄露、绕过分支保护或伪造审计追踪。同时，开发者工具已深度标准化，代理需要与现有Git客户端、gh、REST/GraphQL API和CI/CD工作流兼容。因此，agent-git-service在保持GitHub兼容的同时，将代理提升为一流账户。

agent-git-service的实现

agent-git-service从一个简单规则开始：一个代理一个账户。它支持通过OAuth设备流进行代理注册和认证，并提供细粒度的权限模型，将任务作用域与资源动作结合。每个代理有自己的仓库、问题和拉取请求，操作受到委托链和任务约束的限制。例如，代理“code-reviewer”在委托人Alice的任务“fix-payment-bug”下，仅能在仓库“acme/payments”上执行“读取代码、创建分支、推送分支、开启PR”等动作，且受限于前缀、过期时间和网络白名单。这种设计确保了委托的清晰性和审计的完整性。