AIエージェントのアイデンティティ：すべてのエージェントに非人間としてのアイデンティティを付与する

AIエージェントIDとは？

AIエージェントIDは、登録済みエージェントが呼び出しを行うたびに提示する検証可能な認証情報です。これはトークンだけでは答えられない問い、つまり「有効な認証情報が提示されたか」ではなく、「どのエージェントが呼び出しており、今誰のために行動しているのか」という問いに答えるものです。

TrueFoundryではすでに2種類のプリンシパルを認識しており、エージェントIDはそれに続く3番目の種類となります。

重要なのは「委任」の境界線です。仮想アカウントは自分自身としてしか行動できないため、MCPサーバーに設定すると、誰がプロンプトを出したかに関わらず、すべての呼び出しが同じものに見えてしまいます。一方、エージェントIDは他者の代理として行動できるため、何百人ものユーザーにサービスを提供する単一の登録済みエージェントであっても、各リクエストが誰のためのものかを追跡しつつ、エージェント自身も識別可能です。この特性こそが、エージェントのトラフィックを監査可能にするのです。

非人間ID（NHI）とその独立したカテゴリー化の理由

「非人間ID（NHI）」とは、背後に人間が存在しない状態で認証を行うあらゆるもの（サービスアカウント、ワークロードID、APIクライアント、そしてエージェント）を指すセキュリティチームの包括的な用語です。エージェントはこのファミリーの中で最も扱いが困難です。なぜなら、固定されたサービスアカウントとは異なり、自律的に動作するからです。エージェントはコンテキストを解釈し、ツールを選択し、呼び出しを連鎖させるため、サービスアカウントに必要な管理（認証情報のローテーション、インベントリ管理）に加え、委任ルール、責任の所在、ホップごとの追跡、キルスイッチといった新たな管理機能が必要となります。

エージェントを「単なるサービスアカウント」として扱うことは、追跡不可能な過剰権限を持つエージェントを生む原因となります。エージェントの非人間ID管理は、まず各エージェントに独自のファーストクラスのIDを付与することから始まります。

なぜすべてのエージェントに独自のIDが必要なのか

各エージェントに個別のIDを付与することは、ガバナンスモデル全体を機能させるための重要な決定です。

• 追跡可能性（アトリビューション） 呼び出しの受信側は、呼び出し元が人間なのか、サービスなのか、あるいは特定のエージェントなのかを判別できます。事後にアクションを証明できるようになり、これは監査において不可欠な要件です。
• エージェントごとのポリシー設定 一人の人間が複数のエージェントを操作する場合、それらすべてにその人間の全権限を継承させるべきではありません。Jiraを読み取るサポート用コパイロットと、Jiraに書き込むエンジニアリング用エージェントは、どちらも同じユーザーのために行動していても、異なるプリンシパルとして扱うべきです。個別のIDがあれば、それぞれに異なるスコープを設定できます。
• 匿名エージェントの排除 エージェントが登録済みIDを提示しなければツールにアクセスできないようにすれば、登録プロセスが強制的な管理ポイントとなります。組織全体のインベントリを自動的に把握でき、不正なエージェントを他のエージェントに影響を与えることなく個別に無効化できます。

この最後の点は、静かながらも大きなメリットです。IDが行動の必須条件となれば、レジストリは単なるドキュメントではなく、他のあらゆる制御を可能にするための重要なゲートウェイとなります。

TrueFoundryによるエージェントIDの発行と管理方法

TrueFoundryにおいて、エージェントIDは作成して後付けする別個のオブジェクトではありません。エージェント登録プロセスの一環として生成されるため、IDとエージェントは1対1で対応します。エージェントを登録すればIDが生成され、エージェントを削除すればIDも同時に消滅します。

‍

TrueFoundryドキュメントの製品スクリーンショット：エージェント登録時の「エージェントID」ステップ。

認証情報の取得元

登録時に、エージェントが自身の身元を証明する方法を選択します。

‍

• TrueFoundryによる発行 TrueFoundryがエージェントのトークンを発行および署名します。これは最もシンプルなオプションであり、自社で構築・運用するエージェントに適したデフォルト設定です。
• IDプロバイダーによる発行 Okta、Microsoft Entra、各種OIDCプロバイダー、またはSPIFFE/SPIREエンドポイントなど、お客様が利用するプロバイダーのトークンを使用してエージェントを認証します。特定のクレーム値をエージェントにマッピングすることで、受信したトークンを該当するエージェントに関連付けます。この方法では「On-Behalf-Of (OBO) デリゲーション」が利用可能となり、エージェントがユーザーの代理として一連の処理を継続できるようになります。

‍

どちらの方法でもIDが持つ意味は同じです。異なるのは発行元のみであり、1つのテナント内でエージェントごとに発行元を混在させることも可能です。

IDブローカーとしてのTrueFoundry

ご利用のIDプロバイダーにエージェントID機能が備わっていない場合、TrueFoundryがコントロールプレーンの3つの役割すべてを担うことができます。各エージェントのID発行、Agent GatewayおよびMCP Gatewayでの全呼び出しの認可、そしてトークン交換による各ホップ用のスコープ付き認証情報の生成を行います。企業のSSOは、これまで通り人間（ユーザー）の認証に専念します。呼び出し時には、エージェントは自身のIDをユーザーのIDと併せて提示するため、両方のIDが同時に可視化されます。

‍

curl https://gateway.truefoundry.ai/api/llm/chat/completions \

  -H "Authorization: Bearer $USER_TOKEN" \

  -H "x-tfy-agent-authorization: $AGENT_TOKEN" \

  -H "Content-Type: application/json" \

  -d '{

        "model": "openai-main/gpt-4o",

        "messages": [{"role": "user", "content": "未解決の課題を要約して"}]

      }'

‍

エージェントは、仮想アカウントと同様の方法で、レジストリから自身のトークンを取得します（エージェントの「トークン取得」アクション）。

エージェントが誰の代理として行動できるか

委任には制限があります。その範囲は、登録時のアクセス制御ステップで設定されたエージェントのコラボレーターによって決まります。誰がエージェントを呼び出せるかを決定するリストが、誰の代理としてエージェントが行動できるかも決定します。

‍

TrueFoundryドキュメントの製品スクリーンショット：エージェントのコラボレーターとロール。

‍

エージェントの 管理者（Agent Manager） は、エージェントを編集できます。 エージェントのアクセス権を持つユーザー は、エージェントを呼び出し、代理として行動させることができます。また、 オーナー チームは別途設定され、作成から廃止に至るまでエージェントに対して責任を負います。これらの権限付与がエージェントの定義された権限となります。つまり、誰の代理として行動できるか、どのMCPサーバーやモデルにアクセスできるかが決まります。

‍