AIエージェントにアイデンティティはない——私たちが、それを与えるオープン登録(レジストリ)を作った

Dev.to / 2026/4/27

📰 ニュースDeveloper Stack & InfrastructureTools & Practical UsageModels & Research

要点

  • 人間のAPI呼び出しと違って、AIエージェントの仕事の委任には標準的なアイデンティティや検証手段がなく、現状はデフォルトで“信頼”に頼る構図だと述べています。
  • 提案されるProvenanceは、オープンなレジストリ、PROVENANCE.ymlで能力と禁止事項(制約)を宣言するプロトコル(必要に応じてEd25519の公開鍵で所有を証明)、および派遣前にエージェントを確認するnpm SDKで構成されます。
  • Provenanceは「ゲート」ユースケースにより、プラットフォームがエージェントのアイデンティティ状態、能力、制約、インシデント履歴を確認したうえでタスクをルーティングできます。
  • さらに、ノンス署名による委任作業の検証も可能で、受信側のエージェントはID文字列だけでなく、誰が呼び出しているかをより確実に証明できます。
  • アイデンティティ状態は推定(inferred)、宣言(declared)、検証済み(verified)の3段階で定義され、制約は自己申告であり実行時の監査・強制はしない一方、違反は検証可能な“アイデンティティ侵害”として記録できると説明しています。

人間がAPIを呼び出すときは、認証があります。キー、トークン、証明書。誰が呼び出しているのか、そして何が許可されているのかが分かります。

一方、AIエージェントが別のエージェントへ作業を委譲するときは、何もありません。標準のアイデンティティがない。呼び出しているエージェントが、自称する通りの存在なのか、決してやらないと約束したことを守ってきたのか、違反の履歴があるのかを検証する方法がない。こちらはディスパッチして信頼する。それが現在のデフォルトです。

Provenanceが解決するのは、この問題です。

私たちが作ったもの

Provenanceは3つの要素から成ります:

レジストリ — GitHub、npm、HuggingFace、PyPIから集めたAIエージェントのオープンなインデックス。各エージェントには、その出所に紐づいたprovenance_idが付与されます:provenance:github:alice/my-agent、provenance:npm:my-package。IDを与えると、レジストリはエージェントのアイデンティティ状態、宣言された対応能力(capabilities)、制約(constraints)、およびインシデント履歴を返します。

プロトコル — 開発者はリポジトリにPROVENANCE.ymlを追加し、自分のエージェントが何をできるか(capabilities)と、決して何をしないか(constraints)を宣言します。任意で、Ed25519の公開鍵を登録し、アイデンティティを自分が管理していることを証明できます — これは誰でも検証可能で、私たちのレジストリを信頼する必要はありません。

SDK — provenance-protocol(npm)により、どんなプラットフォームやエージェントでも、作業を委譲する前にエージェントを確認するための1回の呼び出しを行えます。

アイデンティティは2方向に機能します

主なユースケース:プラットフォームが作業をルーティングする前に、エージェントを検証すること。

import { Provenance } from 'provenance-protocol';
const provenance = new Provenance();

const result = await provenance.gate(agentId, {
requireVerified: true,
requireConstraints: ['no:pii', 'no:financial:transact'],
requireClean: true, // 未処理のインシデントなし
});

if (!result.allowed) throw new Error(result.reason);
// 安全に委譲できる

副次的なユースケース:受信側のエージェントが、自分を呼び出している相手のアイデンティティを検証すること。オーケストレータがprovenanceのアイデンティティを主張します。受信側がnonceを発行し、呼び出し側がそれを自分の秘密鍵で署名し、受信側がverifySignature()で検証します。単にID文字列を知っているだけでは不十分で、委譲された作業を受け入れる際に有用です。

3つのアイデンティティ状態

  • inferred — クロールによって発見される。開発者側のアクションはない。未知として扱います。
  • declared — 開発者がPROVENANCE.ymlを追加した。意図的な公開のコミットメントで、自認(self-attested)されています。
  • verified — 開発者がEd25519の公開鍵を登録し、所有を証明した。私たちのレジストリを信頼せずに、独立して検証可能です。

保証できないこと

制約は自己申告です。no:piiを宣言しないエージェントがいれば、それは公開のコミットメントをしたということです — ただし、インフラレベルの証明ではありません。実行時の振る舞いを監視したり、コードを監査したりはしません。得られるのは、機械可読で、バージョン管理され、暗号学的に署名されたコミットメントです。もしエージェントがそれに違反した場合、それは公開されているアイデンティティに対する、検証可能な侵害です — それはインシデントレポートとして文書化できます。

レジストリもまた集中型です。私たちは1つのサーバを運用しています。プロトコルは、署名をオフラインで検証でき、またPROVENANCE.ymlファイルがエージェント自身のリポジトリに置かれるよう設計されていますが、レジストリ依存の機能では私たちが利用可能である必要があります。保証を過剰に売り込む信頼インフラではないため、この点を正直に説明します。

オープンプロトコル

PROVENANCE.ymlのスキーマ、能力(capability)と制約(constraint)の語彙、そしてエージェントジョブプロトコル(AJP — ジョブごとに署名されたレシートを伴う構造化されたジョブオファー)はMITライセンスです。私たちのレジストリなしでも、信頼モデルを実装できます。

私たちが何者で、何を行い、何を行わないのかについての完全な説明:https://getprovenance.dev/about
レジストリと検索:https://getprovenance.dev
SDK: npm install provenance-protocol
仕様:https://github.com/ilucky21c/provenance-protocol