代理優先的身份驗證與授權

隨着人工智能代理在軟件開發中的角色日益重要，傳統的身份驗證與授權模型——為人類和通用工作負載設計——已不再適用。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”等動作，且受限於前綴、過期時間和網絡白名單。這種設計確保了委託的清晰性和審計的完整性。