AIモデルとプラットフォーム
Linux Foundation、AIエージェントのアイデンティティ向け「Agent Name Service」を開始

Linux Foundationは2026年11月10日、Agent Name Service(ANS)が財団のプロジェクトとして正式に開始されたと発表した。オープンな仕様とオープンソースツールを通じて、ドメインにひも付いたアイデンティティ、ディスカバリー、認証をAIエージェントに提供する。
ANSは、独自のセキュリティポリシーを適用する前に、システムがどの登録済みエージェントとやり取りしているのかを確認できるよう設計されている。バージョン付きの名前をエージェント運用者が管理するドメインにひも付け、Domain Name System(DNS)を使ってディスカバリー情報を公開し、署名済みのライフサイクルイベントを透明性ログに記録する。この方式では、単一の独自エージェント登録簿を必要とせず、既存のインターネット基盤を再利用する。
この開始により、財団が2026年6月23日に発表したプロジェクト設立の意向は、ガバナンスの下で運営されるプロジェクトへと進展した。財団によると、それ以降、11の組織がANSに貢献または採用している。Cisco、Cloudflare、DigiCert、DistributedApps.ai、GoDaddy、HOL、Infoblox、Radix、Salesforce、OWASP、Trustmodel.aiである。
ANSの登録と認証の仕組み
7層からなる仕様は、アイデンティティ、登録、バージョン付きの命名、DNSによる公開、透明性、完全性の監視、エージェント認証を網羅する。ANS名はドメインにバージョンをひも付ける。たとえば、 ans://v1.0.0.payments.example.com;新しいバージョンには新たな登録が必要となる。
登録時、運用者はエージェントのホスト、バージョン、エンドポイント、証明書情報を登録局に提出し、登録局はドメインの管理権限と必要な証明を確認する。運用者が返却されたDNSレコードを公開すると、登録局は有効化の前にそれらを検証する。続いて、登録局はライフサイクルイベントに署名し、透明性ログに封印させる。これにより、登録と認可済み証明書をひも付ける公開証跡が生成される。
ピアは、対応するディスカバリープロファイルを使ってエンドポイントを見つけ、共有の _ans-badge レコードから透明性の証拠を確認する。ディスカバリーだけでは、呼び出し元は認証されない。認証には3つの確認が必要となる。証明書が登録済みのアイデンティティにひも付いていること、登録が引き続き有効であること、そして呼び出し元が対応する秘密鍵を保有していることである。
ANS-6認証ドラフトでは、相互TLS(mTLS)とアプリケーション層の所有証明(DPoP)が同等に扱われる。mTLSはエンドツーエンドのTLS経路に適している一方、DPoPは1回限りの証明をHTTPリクエストにひも付け、TLSを終端するゲートウェイを経由する場合にも利用できる。バッジ階層の検証者は透明性ログに問い合わせて最新の証拠を確認する。SCITT階層では、リクエストごとにネットワークへ接続することなく、レシートとステータストークンをローカルで検証する。DPoPにはSCITTとのバインディングが必要となる。
ソフトウェアと初期の相互運用性
現在利用できるソフトウェアには、登録局、透明性ログ、オフライン検証ツールのGoによるリファレンス実装と、APIや機能の対応範囲がそれぞれ異なるGo、Rust、JavaのSDKが含まれる。また、 ans-cli このツールは、macOS、Linux、Windowsで登録、ディスカバリー、証明書管理、透明性ログへの問い合わせに対応する。ローカル環境向けのクイックスタートでは、開発用鍵と noop DNS検証ツールを使用する。そのため、レシート検証に合格しても、公開DNS、本番環境での証明書発行、稼働中のデプロイは検証されない。
相互運用性について、Linux Foundationは、AGNTCYのAgent Directory ServiceがANSアイデンティティの検証に対応し、ANS FinderがAgentic Resource Discovery(ARD)を実装して、同レジストリの適合性テストに合格していると報告している。ARD独自の仕様は、実行ではなく呼び出し前のディスカバリーを扱い、中央カタログを定めるのではなく、信頼性、順位付け、アクセスのポリシーが異なる複数のディスカバリーサービスを認めている。この取り組みは、検証可能なアイデンティティの証拠をディスカバリーに結び付ける一方、普遍的なエージェントディレクトリを作るものではない。
ドラフト仕様とセキュリティ上の境界
初期の技術運営委員会は、投票権を持つ5人のメンバーで構成される。GoDaddyのScott Courtney、Keith Perry、Connor Snitker、DistributedApps.AIのKen Huang、Hashgraph OnlineのMichael Kantorである。同委員会は技術方針を定め、リポジトリのメンテナーは変更をレビューし、リリースを管理して、セキュリティ報告に対応する。開始時のリリースでは仕様が正式化されたと説明されている一方、プロジェクトのドキュメントでは、公開済みの仕様は活発な開発が続くドラフトとされている。ANS-6には「DRAFT v1.0」と記され、バージョンは0.2.0、日付は2026年11月3日となっている。
このセキュリティモデルが確立するのはアイデンティティであり、権限ではない。認可、呼び出しチェーンをまたぐ委譲、信頼度のスコアリングはANS-6の対象外であり、認証されたエージェントに何を許可するかは各アプリケーションが判断する。封印されたメタデータのダイジェストは、リモートマシン上で実行されるコードを証明するものでも、エージェントの動作を保証するものでもない。また、クライアント側では、信頼できるログ鍵、署名と証明の正確な検証、鮮度チェック、障害時のポリシーが引き続き必要となる。検証者が鍵の保有確認を省略すると、公開バッジ、レシート、ステータストークンが再利用されるおそれもある。
受領証が証明するのは現在の有効性ではなくログの履歴であり、エージェントが失効した後も検証に使えるため、最新のステータス確認と併用する必要があります。統合の成熟度にもばらつきがあります。NVIDIA OpenShellの取り組みはリサーチプレビューと位置付けられており、その接続先登録時のチェックでは、実際のTLSピア証明書とのANS-6バインディングは実装されていません。
ANSは現在、財団によるガバナンス体制を備え、ドラフトとリファレンス実装を公開しています。実用上のセキュリティ価値は、導入環境でアイデンティティ、最新のステータス、鍵の所持を一体として検証することにかかっています。一方、認可やエージェントの振る舞いに関する判断は、アイデンティティの主張の範囲外に置かれます。












