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

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