ServiceNowがすべてのAIエージェントに「パスポート」を発行。スタートアップのエージェントの多くは、名前すら持っていません

2026年10月18日
8 min read

2026年10月18日
8 min read
AIエージェントを動かしているスタートアップに、3つの質問をしてみてください。エージェントはいくつあるのか。それぞれの責任者は誰か。それぞれは何に触れてよいのか。正直な答えは、たいてい「いくつか」「エンジニアリングチーム」「APIキーで許される範囲すべて」です。今週のServiceNowの発表は、大企業の顧客がその答えを受け入れなくなりつつあることを示しています。
本記事は、2026年10月15日のServiceNowの発表と、Constellation Research、Forkastの記事に基づいています。AI Passportはまだ提供されておらず、引用している数字はServiceNowとその顧客によるものです。第3節以降は筆者の見解です。
ServiceNowによれば、AI Passportは「AIエージェントが実行時に参照し、認められた範囲を確認するための、暗号署名付きの認証情報」です。各エージェントの認証情報には、次のことが記録されます。
確認が行われるのは、設定時だけでなく、エージェントが行動するその時点です。範囲内で動いているエージェントは自由に動作します。範囲から外れたエージェントには、段階的な対応がとられます。「AIエージェントを誘導する、制限する、適切な文脈を与えて再接続する。終了が必要な場合は、機械の速さで強制停止することも含む」。
ほかにも重要な点が3つあります。
ServiceNowは2つの数字を挙げています。いずれも自社の調査、または顧客によるものです。
役に立つのは2つ目の数字です。大企業の顧客が、エージェントを社員と同じように管理すると決めたのです。エージェントには識別子があり、その行動に責任を負う人がいます。
顧客が1,500のエージェントそれぞれに社員IDと上司を割り当てているなら、あなたが売るエージェントにも同じことが求められます。
AI Passportを買うことは、おそらくないでしょう。しかし、企業にAIエージェントを販売しているなら、あなたのエージェントはこの種の管理を導入しつつある顧客の環境で動くことになり、セキュリティ審査でも次のことを聞かれるようになります。
圧力は複数の方向から同時に来ています。FTCはOpenAIとAnthropicに対し、インシデントの記録と安全対策を求めたばかりです。調査でも繰り返し、企業がエージェントの管理策を、その実態以上に信頼していることが示されています。エージェントごとの認証情報は、説明するだけでなく、実際に示すことができる種類の管理策です。
この4つの質問に答えるのに、署名付きの認証情報や制御プラットフォームは必要ありません。必要なのは、意図して用意したいくつかの要素です。
エージェント台帳。 エージェントごとに1行、エージェントID、責任者(チームではなく個人)、許可された操作、アクセスできるシステムの4列。リポジトリで管理し、エージェントを変更したらレビューします。台帳に載っていないエージェントは、動かすべきではありません。
エージェントごとの認証情報。 複数のエージェントで1つのAPIキーを共有するのはやめましょう。各エージェントに、台帳の行に記した操作とシステムに限定した、短期のトークンを個別に与えます。どれかが問題を起こしても、ほかを壊さずにそれだけを無効にできます。
プロンプトではなく、操作の時点で確認する。 システムプロンプトの「請求書の閲覧だけをすること」はお願いにすぎません。呼び出しを拒否するツール層こそが管理策です。権限の確認は、エージェントの操作が実際に実行される場所に置きましょう。
段階的な停止の仕組み。 エージェントごとに、まず警告、次に制限、次にブロック、最後に停止。どの行動がどの段階を引き起こすかを事前に決め、顧客に「強制停止の仕組みはあるか」と聞かれる前にテストしておきます。
ユーザー単位ではなく、エージェント単位で記録する
すべてのログ行に、エージェントが代理で動いている人間のユーザーとあわせて、エージェントIDを含めましょう。「ユーザー4812が300件のレコードを削除した」と「エージェントbilling-reconcilerが、ユーザー4812の代理として300件のレコードを削除した」では、顧客との会話も、後から調査する人との会話も、まったく違うものになります。
なぜモデルの外で制御するのか。UK AI Security InstituteがOpenAIのエージェントを、1行の権限範囲ルールを与えてテストしたところ、許可されていない行動は大きく減ったものの、ゼロにはなりませんでした。書かれた権限範囲は役に立ちますが、持ちこたえるのは強制される権限範囲です。そして台帳と、名前の挙がった責任者は、どのフレームワークも用意してくれない部分です。
AI Passportが説明どおりに機能するとは言えません。 提供は2026年第4四半期からで、ServiceNowとそのパートナー以外は誰もテストしていません。
オープンな仕様が確定しているとも言えません。 ServiceNowはオープンな仕様に基づくとしていますが、発表では仕様の名前を挙げておらず、相互運用性はほかのベンダーが同じ仕様を採用するかどうかにかかっています。
認証情報があればエージェントが安全になるとも言えません。 Forkastが指摘するように、制御の質は、認証情報に書き込まれた権限範囲の質で決まります。範囲の定義が甘いパスポートは、制御できているという誤った安心感を与えます。
銀行の数字があなたの顧客に当てはまるとも言えません。 24%という数字は、規制の厳しい業界である銀行を対象にした、ServiceNow自身の調査によるものです。
ServiceNowのAI Passportは、各AIエージェントに、ID、許可された操作、アクセスできるシステム、責任者を記した署名付きの認証情報を与え、行動の時点で確認し、逸脱すれば強制停止まで対応します。提供開始は2026年第4四半期で、NVIDIAがローンチパートナー、名前はまだ明かされていないオープンな仕様に基づきます。ある顧客はすでに、1,500のエージェントそれぞれに社員IDと上司を割り当てています。
スタートアップにとって重要なのは、製品そのものよりも、それが生み出す期待です。エンタープライズの顧客は、あなたのエージェントそれぞれが何なのか、責任者は誰か、何ができるのかを尋ね、その答えがコードで強制されていることを求めるでしょう。
次のエンタープライズ契約の前に、台帳を書いてください。動かしているすべてのエージェントについて、責任者、許可された操作、システムを記します。そのうえで、各エージェントに専用の認証情報を与え、すべてのログ行にそのIDを入れましょう。
出典:ServiceNow(2026年10月15日)— AI Passportの定義、段階的な対応と強制停止、オープンな仕様に関する説明、NVIDIAの役割とOpenShell・Sentryの構成要素、2026年第4四半期の提供予定、2026年版Banking AI Maturity Indexの数字、社員IDと上司が割り当てられたLTMの1,500のエージェント。Constellation Research— NVIDIAのOpen Agent Safety Platformとの提携に関する報道。Forkast— 制御の効果は認証情報の範囲をどれだけ丁寧に定めるかで決まるという指摘。第3節から第5節は筆者の見解です。
IdeaToMVP Academy
4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.