6月30日、It's FOSSが「AI Agents Could Get Verified Identities, Courtesy of DNS」と題した記事を公開した。Linux FoundationがDNSを拡張してAIエージェントに検証済みIDを付与するオープン標準「Agent Name Service（ANS）」の立ち上げ意図を発表したことについて詳しく紹介されている。
AIエージェントの「なりすまし」問題
AIエージェントが増殖しつつある現在、見落とされがちな問題がある。エージェントの認証だ。
あるエージェントが support-agent.acme.com と名乗っていても、それが本当に正規のエージェントかどうか確認する手段が現状では存在しない。誰でも任意の名前を自称できる。Linux Foundationが引用したリサーチによれば、経営幹部の82%が今後1〜3年以内にAIエージェントを導入する計画を持っているにもかかわらず、本番環境で稼働するエージェントを認証・統制する確立された手段がないのが実態だ（※出典名は元記事に明記されていないため、詳細は元記事を参照）。
ANS（Agent Name Service）はこの問題に正面から取り組む仕様である。
ANSの仕組み：DNSとTLSの流用
ANSはゼロから新しい認証基盤を作るのではなく、すでに広く使われているDNSとTLS証明書の仕組みをAIエージェント向けに拡張するアプローチを取る。
ANSに登録されたエージェントは、DNSのサブドメイン形式を踏襲した名前とバージョン番号を持つ。元記事が示す例では my-agent.example.com のような形式を基本としており、バージョン情報を付加した識別子として管理される。
この名前に紐づくID証明書は、通常のTLS証明書と同じDNSおよびACMEによる検証を通過した場合にのみ発行される。つまり、Webサイトに対してすでに確立されたPKI（公開鍵基盤）のプロセスをそのまま使う。
また、エージェントの登録・更新・失効といったすべてのイベントは追記専用のMerkleログ（改ざん検知可能な構造）に記録される。過去の記録を書き換えることはできず、ans-verify というオフラインツールで、レジストリへの接続なしに任意の記録を検証できる。
GoDaddyがすでに本番運用中
重要な背景がある。これはLinux Foundationが一から起こした取り組みではない。
GoDaddyはLinux Foundationが関与するより前の段階ですでにANSを稼働させており、IETF draft（draft-narajala-ans）に基づいて実装を進めていた。GoDaddyのエンジニアは新しいインフラを構築するのではなく、すでに本番で動いている自社のSSL/TLSサービス（アクティブな証明書数1億件超）と既存のDNSシステムをそのまま流用する形で実装した。
GitHubには agentnameservice という組織アカウントがあり、現在8つのリポジトリが公開されている。メインの ans リポジトリはMITライセンスのGoで書かれており、レジストリ・ロギング・ベリファイアを含むフルスタックのリファレンス実装が含まれている。
セットアップに必要なのは Go、openssl、curl、jq のみで、約60秒でスタック全体が立ち上がると報告されている。
標準化の意義
AIエージェントの台頭とともに、エージェント間の通信プロトコルの標準化も進んでいる。Anthropicが提唱するMCP（Model Context Protocol）やGoogleが推進するA2A（Agent2Agent Protocol）などが並行して議論されているが、これらはあくまでエージェント間の通信仕様であり、「そのエージェントが何者か」を証明する仕組みではない。ANSはその欠けているピースを埋める位置付けだ。
DNSとTLSという実績ある基盤を転用することで、全く新しい信頼モデルを設計するコストを省きつつ、既存のセキュリティエコシステムとの親和性を保っている点は、エンジニアにとって評価しやすい設計判断だろう。
詳細はAI Agents Could Get Verified Identities, Courtesy of DNSを参照していただきたい。
