エージェントファーストの認証と認可

人工知能エージェントがソフトウェア開発においてますます重要な役割を果たすにつれ、従来の認証・認可モデル（人間と汎用ワークロード向けに設計されたもの）はもはや適切ではありません。AIエージェントは、人間のセッションを一時的に借用するスクリプトでも、無名のサービスアカウントでもありません。それらは第一級のソフトウェアユーザーとして扱われるべきです：永続的で、識別可能で、委任可能で、取り消し可能で、監査可能です。

エージェントファーストの認証は、エージェントが開発作業を行うために本当の権限を必要とするが、単一のトークンではその権限を説明できないという問題を解決します。コーディングエージェントは、リポジトリのクローン、ブランチのプッシュ、プルリクエストの作成、ワークフローのトリガー、外部ツールの呼び出しなどを行います。各アクションは、エージェント、委任者、タスク、リソース、承認境界、監査証跡を保持する必要があります。目標は、委任、最小権限、取り消し、説明責任を借用した人間のトークンや汎用サービスアカウントの中に隠すことなく、エージェントが有用な作業を実行できるようにすることです。

この区別は重要です。エージェントは、アカウントモデルにおいてユーザーになることができ、同時に認可モデルにおいて人間である必要はありません。それは独自のログイン、資格情報、リポジトリ、イシュー、プルリクエスト、長期状態を持つことができ、その権限は人間から全体として継承されたり、共有マシンアカウントに統合されたりするのではなく、委任され、スコープ化され、制約され、レビュー可能なままです。

エージェントファーストのアイデンティティとは、エージェントが独自のアカウント、スコープ、ライフサイクル、監査証跡を持つ永続的なソフトウェアユーザーであることです。これこそがagent-git-serviceが構築されている設計空間です。それはGitHub互換のAPIおよびGitサービスであり、エージェント、自動化、開発者ワークフロー向けです。REST v3、GraphQL v4、OAuthデバイスフロー、Git Smart HTTPなど、おなじみのプロトコルを話します。しかし、そのおなじみの表面の下で、明確な立場を取っています：エージェントは隠れたユーザーセッションではありません。エージェントは、独自の資格情報、リポジトリ、権限チェック、ライフサイクルを持つ永続的なアカウントです。

借用アイデンティティの問題

ほとんどのソフトウェアシステムは、2種類のアクターを中心に設計されていました。

人間：SSO、MFA、ブラウザセッション、OAuth同意を通じてログインします。

ワークロード：サービスアカウント、APIキー、アプリ登録、またはマシンアイデンティティとして実行されます。

AIエージェントは、これらのどちらのバケットにもきれいに収まりません。

エージェントが人間のパーソナルアクセストークンを再利用すると、継承するものが多すぎます。爆発半径は、タスクが1つのリポジトリや1つのイシューのみを必要とする場合でも、その人間がアクセスできるすべてのリソースに及びます。監査ログには「アリスがこれを実行した」と表示されますが、実際にはアリスが作業を自律システムに委任し、そのシステムが計画、ツール選択、ファイル書き込み、副作用トリガーを行った場合でも同じです。

エージェントが汎用サービスアカウントとして実行されると、人間の委任チェーンが失われます。システムは「build-agent-prod」が変更を行ったことを知っていても、それがアリスのためなのか、チームポリシーのためなのか、スケジュールされたワークフローのためなのか、別のエージェントのためなのかはわかりません。アクセスレビューは曖昧になり、トークンローテーションは面倒になり、説明責任は推測になります。

正しいモデルは「エージェント＝人間」や「エージェント＝汎用アプリ」ではありません。正しいモデルは次のとおりです。

人間 / 組織 → 明示的な委任 → エージェントアイデンティティ → ランタイムまたはセッションアイデンティティ → タックスコープの権限 → ツールまたはリソースアクション

借用した人間のトークンは爆発半径を拡大し、汎用サービスアカウントは委任コンテキストを消去します。

エージェントファーストの認証では、エージェントがプリンシパル、人間が委任者、タスクが権限境界、リソースが実施境界となります。

業界は同じ形状に収束しつつある

異なるエコシステムは異なる角度からこの問題にアプローチしていますが、パターンは可視化されつつあります。

Model Context Protocol (MCP) 認可仕様は、制限されたMCPサーバー向けにOAuth 2.1上に構築されています。クライアントにResource Indicatorsの使用を要求し、トークンが意図されたリソースに対して要求されるようにし、保護リソースメタデータに依存して発見を行い、トークンパススルーを明示的に禁止しています。これはエージェントにとって重要な原則です：ツールサーバーは、他のAPI向けのトークンを受け入れて盲目的に下流に転送すべきではありません。

GitHub Appsは、ソフトウェア自動化に関して同様の方向性を示しています。従来のパーソナルトークンと比較して、より細かい権限、リポジトリ選択、さらに制限可能なインストールアクセストークンをサポートしています。GitHub Copilotコーディングエージェントは、製品レベルの境界を追加します：制限された開発環境で動作し、ブランチ保護と必須チェックの対象となり、ファイアウォール制御を使用してネットワークアクセスを制約します。

Microsoft Entra Agent IDは、エージェントアイデンティティを追加の保護手段を持つ専用のエンタープライズアイデンティティタイプとして形式化します。ドキュメントでは、従来のユーザーとアプリ登録は自律エージェントに理想的ではなく、多くの高リスクロールや権限はデフォルトでエージェントに対してブロックされるべきであると明示しています。

Google Cloud Agent Identityは、エージェントごとのアイデンティティ、ワークロードアイデンティティ、SPIFFE/X.509資格情報、長期有効なサービスアカウントキーの回避を強調しています。AWS Bedrock AgentCore Identityは、エージェントアイデンティティとエンドユーザーアイデンティティの両方を運ぶことができるワークロードアクセストークンを使用し、それを外部資格情報のトークンボールトと組み合わせています。

Auth0 FGAは、関係グラフ内でエージェントを認可サブジェクトとしてモデル化します。これは、実際の質問が「このユーザーはadminロールを持っているか？」ではなく、「このエージェントはこのユーザーに代わってこのオブジェクトに対して行動することを許可されているか？」である場合に有用です。

Casdoorは別の理由で興味深いです。それは、単なる汎用SSO製品ではなく、AIネイティブIAMレイヤーおよびMCP認可サーバーとして位置づけられています。そのAgentアプリケーションカテゴリは、マシン間エージェントアプリをユーザー向けアプリから分離し、MCPおよびA2Aタイプを備えています。そのMCP認証プロバイダーは、ツールビルダーにOAuth 2.1インフラストラクチャ（動的クライアント登録、PKCE、同意、JWKS検証、Resource Indicators、メタデータ発見など）を提供します。そのMCP認可ドキュメントは、スコープをツールにマッピングし、サードパーティMCPサーバー向けのカスタムツールスコープをサポートし、スコープチェックをCasbinベースのきめ細かいポリシー（ユーザー、ロール、リソース、アクション、関係、環境にわたる）と組み合わせています。そのAgentsとOpenClawのストーリーは、ランタイムの可視性も指し示しています：エージェントエンドポイントを登録でき、ツールコールやエージェントインタラクションを監査エントリとして記録できます。

NISTのソフトウェアおよびAIエージェントのアイデンティティと認可に関するコンセプトペーパーは、識別、認可、監査、否認防止、プロンプトインジェクション軽減を中心に問題をフレーミングしています。OWASPのエージェンティックセキュリティの取り組みは、反対側から同じリスクを強調しています：過剰権限のスキル、弱いアイデンティティ検証、権限乱用は、エージェントがツールを呼び出し状態を変更できるようになるとシステム全体の問題になります。

これらのシステムのいずれも単独では完全な答えを提供しません。しかし、それらは一緒に実用的なアーキテクチャを指し示しています：

すべてのエージェントに実際のアイデンティティを与える。

人間または組織からエージェントへの委任チェーンを保持する。

短命で、オーディエンスとリソースにバインドされた資格情報を発行する。

権限をタスク、リソース、アクション、コンテキストにスコープする。

すべての意味のある境界で実施を行う。

アクションが許可された理由を説明するのに十分な来歴を記録する。

異なるエコシステムは、同じエージェントファーストの認証形状（実際のエージェントアイデンティティ、スコープ付き資格情報、ポリシー境界、監査可能な決定）に収束しつつあります。

エージェントファースト認証の要件

エージェントの認証は「このトークンは有効か？」で止まるべきではありません。どのエージェントが行動しているか、どこで実行されているか、どの人間または組織が作業を委任したか、どのタスクまたはセッションがリクエストに属するかを確立する必要があります。

成熟したシステムには、いくつかのアイデンティティレイヤーが必要です。

エージェント認証は、人間の委任者、エージェントアイデンティティ、ランタイムアイデンティティ、タスクアイデンティティを確立する必要があります。

人間のアイデンティティは依然として重要です。ユーザーはOIDC、SAML、OAuth、MFA、デバイスフロー、または他のエンタープライズアイデンティティパスを通じて認証する必要があります。しかし、人間のログインはエージェントの資格情報ではありません。それは委任のソースです。

エージェントアイデンティティは安定しているべきです。永続的なアカウント、ユニークなログインまたは識別子、所有者、ステータス、作成メタデータ、トークンライフサイクルを持つべきです。それは発見可能で、管理可能で、一時停止可能で、監査可能であるべきです。

ランタイムアイデンティティは可能な場合は証明可能であるべきです。ワークロードアイデンティティ、mTLS、SPIFFE/X.509 SVID、OIDCワークロードトークンなどのメカニズムは、「このエージェントアカウントが存在する」と「このリクエストが期待されたランタイムからのものである」を区別するのに役立ちます。

タスクアイデンティティは明示的であるべきです。「リポジトリAのイシュー123を修正する」ために使用されるトークンは、「リポジトリBを削除する」や「すべての組織シークレットを読む」ためにも有効であるべきではありません。タスクが期限切れになると、資格情報も期限切れになるべきです。

これはいくつかの具体的な認証ルールにつながります：

長期有効なシークレットはブートストラップ資格情報であるべきであり、通常の運用資格情報であるべきではありません。

通常の作業には短命のセッションまたはタストークンを使用するべきです。

トークンはターゲットオーディエンスとリソースを持つべきです。

高リスクトークンは、可能な場合DPoP、mTLS、またはワークロードにバインドされた発行で送信者制約がかかるべきです。

トークンはエージェント、タスク、人間の所有者、組織、セキュリティポリシーによって取り消し可能であるべきです。

ツールサーバーは上流のトークンを下流のシステムに渡すべきではありません。

エージェントファースト認可の要件

従来の認可はよく尋ねます：

このユーザーはこのロールを持っているか？

エージェントネイティブの認可は、より豊かな質問を必要とします：

このエージェントは、この委任のもとで、このタスクのために、

このリソースに対してこのアクションをこのコンテキストで実行できるか？

つまり、認可入力には以下を含めるべきです：

エージェントアイデンティティ。

委任している人間、組織、またはシステムポリシー。

タスクまたはセッション識別子。

リソース（リポジトリ、イシュー、ブランチ、シークレット、ワークフロー、ドキュメント、データベース、外部SaaSオブジェクトなど）。

アクション（読み取り、書き込み、プッシュ、マージ、削除、ワークフロー実行、シークレット読み取り、メッセージ送信、外部API呼び出しなど）。

コンテキスト（時間、ランタイム、ブランチ名、ネットワーク宛先、リスクスコア、承認状態、以前のツールコールなど）。

エージェントネイティブの認可は、制約された決定を返す前に、エージェント、委任、タスク、リソース、アクション、コンテキストを評価します。

結果は「許可」または「拒否」だけであるべきではありません。多くの場合、次のようになる必要があります：

許可。

拒否。

スコープを狭めて許可。

人間の承認を要求。

より強力な認証を要求。

読み取りを許可するが変更をブロック。

変更を許可するが、コミット、マージ、リリース、外部副作用の前にレビューを要求。

タスク付与は次のようになる可能性があります：

{

"agent": "agent:code-reviewer",

"delegator": "user:alice",

"task": "task:fix-payment-bug",

"resources": ["repo:acme/payments"],

"actions": ["read_code", "create_branch", "push_branch", "open_pr"],

"constraints": {

"branch_prefix": "agent/task-123/",

"expires_at": "2026-06-02T12:00:00Z",

"network_allowlist": ["github.com", "jira.example.com"],

"requires_approval": ["merge_pr", "read_secret", "run_workflow"]

}

}

タスク付与は、永続的なリポジトリ権限ではなく、境界のある権限エンベロープです。

これは、エージェントに永続的なリポジトリスコープを与えることとは異なります。タスク付与は、エージェント、委任者、リソース、許可されたアクション、制約を指定します。プラットフォームがなぜエージェントがあることはできて別のことはできないかを説明できるようにします。

なぜGitが困難で有用なテストケースなのか

ソフトウェアエージェントは、そのアクションが本物であるため、認証設計にとって要求の厳しい環境です。

彼らはドキュメントを読むだけではありません。リポジトリをクローンし、履歴を検査し、ファイルを書き込み、参照を進め、プルリクエストを開き、ワークフローをトリガーし、コメントを投稿し、イシューを管理し、時にはシークレットやデプロイパスに触れます。弱い認証モデルはここでは抽象的なリスクではありません。それは、無許可のプッシュ、漏洩したトークン、バイパスされたブランチ保護、偽造された監査証跡、混乱したデプティワークフロー実行になり得ます。

同時に、開発者ツールは深く標準化されています。エージェントは既存のGitクライアント、gh、REST API、GraphQL API、資格情報ヘルパー、CI/CDワークフローと連携する必要があります。理論的に純粋なエージェントプロトコルだけでは不十分で、既存のクライアントをすべて書き換える必要があってはなりません。

これが、agent-git-serviceが意図的にGitHub互換でありながら、エージェントを第一級のアカウントにする理由です。

agent-git-serviceがモデルを実装する方法

agent-git-serviceは単純なルールから始まります：エージェントごとに1つのアカウント。OAuthデバイスフローを介したエージェント登録と認証をサポートし、タスクスコープとリソースアクションを組み合わせたきめ細かい権限モデルを提供します。各エージェントは独自のリポジトリ、イシュー、プルリクエストを持ち、操作は委任チェーンとタスク制約によって制限されます。例えば、エージェント「code-reviewer」は、委任者Aliceのタスク「fix-payment-bug」の下で、リポジトリ「acme/payments」に対して「コード読み取り、ブランチ作成、ブランチプッシュ、PR作成」のみを実行でき、プレフィックス、有効期限、ネットワークホワイトリストなどの制約を受けます。この設計により、委任の明確さと監査の完全性が保証されます。