経験豊富なIT責任者であれば、シャドーITが根強い問題であることは承知しているでしょう。しかし急速に進化するAIとエージェントの増殖により、その潜在的な脅威とコストはかつてないほど大きくなっています。
AIエージェントは非決定論的で、自律的かつ適応的です。タスクを創造的な方法で解決することに長けており、しばしば開発者自身を驚かせる結果を生み出します。実際、あるエージェントは自分のプルリクエストを却下したプロジェクトメンテナーを批判するブログを書いたことがありました。また別のエージェントは、許可を求めることなく読み書きアクセス権を得るためにマッキンゼーのチャットボットをハッキングしました。そしてエージェントは絶えず賢くなり続けています。
業界のベテランであるDigiCertの製品担当上級副社長ブライアン・トルズペック氏は、ここに古くからのパターンを見出しています。「その技術がもたらす期待があまりに大きいと、人々はセキュリティを窓の外に放り投げてでも、一刻も早くその恩恵にたどり着きたがるものです」。
CISOたちは、厳格な統制なしにこうしたエージェントを自社インフラに受け入れることを懸念すべきですが、現実にはそれが進行してしまっています。IBMの2026年版データ侵害コストレポートによれば、AIを管理したりシャドーAIを検知したりするためのガバナンスを欠く組織の割合は、昨年の63パーセントから68パーセントへと増加しました。一方、AI導入にIT部門の承認を必要とする組織の割合は、45パーセントから38パーセントへと低下しています。
DigiCertは、この問題を「AI Trust」と呼ばれる独自のAIガバナンスの取り組みで解決しようとしています。このホワイトペーパーにまとめられたこのフレームワークは、公開鍵基盤(PKI)、DNS、アテステーションという同社が得意とする分野を土台に構築されています。
CISOが問うべきAIガバナンスの5つの問い
AI Trustはこれらのツールを活用し、組織が次の5つのAIガバナンスに関する問いに答える手助けをします。
・ 従業員がどのエージェントを利用しているか
・ どの規制対象データがそれらに流れ込んでいるか
・ 誰の認証情報を保持しているか
・ 侵害されたエージェントを即座に停止できるか
・ 改ざん検知可能な記録によってインシデントを再構築できるか
トルズペック氏は、ほぼすべての企業が最初の関門でつまずくと警鐘を鳴らします。開発者は許可を得ることなく、社内でエージェントを構築したりベンダーから購入したりして展開してしまいます。ユーザーもまた、Claude DesktopやOpenAI Codexのようなツール内からエージェントを生み出し、それがさらにサブエージェントを生成することもあります。
「そうしたサブエージェントは、親エージェントと同じ権利・責任・権限を引き継ぐわけではありません」と同氏は言います。「そのため、本来は完全に制御可能なはずのタスクまで委任しようとしてしまうのです」。
AIエージェントのアイデンティティをどう管理するか
ほとんどの企業は、こうした多様なエージェントの種類を把握するためのツールをまだ整備できていません。第一歩はそれらを特定することです。ここで多くの組織が最初のつまずきを犯します——既存の人間向けアイデンティティ・アクセス管理(IAM)スタックにエージェントを無理やり組み込んでしまうのです。サービスアカウントと長期有効なAPIキーをエージェントに与えれば、超高速な「従業員」として扱えるという発想ですが、これは現実的ではありません。
「IAMは、キーボードの前に座り、スマートフォンで『承認』をタップできる人間を前提に設計されたものです」とトルズペック氏は語ります。「エージェントにはそれができません。そこで結局、期限のない静的なAPIキーに頼ることになり、しかも必要以上に広範な権限を与えてしまう。これではゼロトラストが実現しようとしていたものをすべて台無しにしてしまいます。まさに、この10年間、私たちが『排除すべきだ』と言い続けてきた資格情報そのものなのです」。
業界団体はこれとは異なる答えに収斂しつつあります。IDCは現在、エージェントのアイデンティティを人間のIAMの延長としてではなく、ワークロードのアイデンティティの問題として扱うことを推奨しており、これはIETFのWorkload Identity Management and Security Extensions(WIMSE)やNISTのサイバーセキュリティフレームワーク バージョン2.0とも整合しています。これにより、エージェントを実行時アテステーションと短命な認証情報を必要とする「統治されたワークロード」として位置づけることができます。
この発想は、各チームをService Profile Identity (SPIFFE)とそのSPIFFE Registration Endpoint(SPIRE)へと導くものでもあります。これは、多くのハイパースケーラーがホストするKubernetes環境に既に導入されているオープンなワークロード・アイデンティティ標準であり、DigiCertのAI戦略の一部にも組み込まれています。
DNSはエージェント型AIのためのガバナンスツールになる
インベントリとアイデンティティによって可視性は得られるかもしれませんが、それでもポリシーを実行に移す場所が必要です。DigiCertは、DNSの完全性を管理してきた自社の歴史を踏まえ、この点について明確な考えを持っています。
エージェントがAPIエンドポイントを解決する場合であれ、MCPサーバーに接続する場合であれ、必ず最初にDNSへ問い合わせを行います。であれば、そこを核となる検証ポイントにしない手はありません。
DigiCertは、電子メールで使われるDMARC標準によく似た仕組みを提案しています。組織はDNS上に「エージェントポリシーレコード」を公開し、次のような事項を宣言します。
・ 自組織が承認しているエージェントのアイデンティティ
・ その認証情報を発行した認証局
・ それらに許可されている権限範囲
ゲートウェイはこのレコードに問い合わせることで、着信するエージェントが正当なものかどうかを検証し、チェックに失敗すればセッションを終了できます。また、実行の途中でエージェントが許可されていないドメインに接続しようとした場合、DNSがそのクエリをブロックし、MCPゲートウェイがセッションを強制終了します。
IDCはこの発想を評価しつつも、スケールが課題になると警告しています。エージェントの数が増えるにつれ、DNSレコードの更新が追いつかなくなる可能性があり、古いレコードが抜け穴になりかねません。過度に緩い権限範囲の宣言も依然として潜在的な問題です。
「スケールの問題は確かに実在します。しかしそれは、DNSがこれまで何百回も解決してきた問題と同じものです」とトルズペック氏は反論します。「ライフサイクルを自動化し、レコードを証明書の発行に紐付ければ、証明書が失効すればレコードも一緒に失効します」。
また、急いでいるあまりワイルドカードの権限範囲を書いてしまうオペレーターがいるとすれば、それはアーキテクチャの問題ではなく規律の問題だと同氏は付け加えます。
DigiCertの「AIパスポート」の内側
社内で構築されたエージェントは、Microsoft Copilot、Salesforce Agentforce、ServiceNowといったサードパーティ製エージェントと並存しており、この2つのカテゴリーの制御基盤は異なります。DigiCertが示す答えは、アイデンティティ用にDigiCertの認証局に紐付けられた単一のSPIREサーバーを用意し、ポリシーはOpen Policy Agentエンジンで一元的に実行し、両カテゴリーにまたがって機能する統一的な緊急停止機能(キルスイッチ)を備えるというものです。
「AIエージェントパスポート」は、アイデンティティと権限を結びつける成果物です。これは、承認済みシステムと許可された操作を暗号によって保護した記録です。各「パスポート」には、データの機密性の分類や有効期限の状態、さらに責任を負う人間の所有者といった情報も含まれます。
トルズペック氏によれば、設計において最も強い反発を招くのはポリシーそのものだといいます。というのも、顧客企業はたいてい、GCPやAWS上に既に複雑なポリシー体系を築いているからです。「それらを置き換えたり駆逐しようとしたりするのは無謀な試みです」と同氏は言います。そこでパスポートは、それらのポリシーエンジンを置き換えるのではなく、それらへのポインターを保持する形を取ります。
モデルの完全性をどう管理するか
エージェントを統治することは、課題の半分に過ぎません。モデル自体も戦略的資産であり、完全性と来歴の管理対象でもあります。それは具体的には、モデルの成果物の暗号化と暗号署名、Sigstoreコード署名の取り組みのようなツールを用いたOpen Container Initiative準拠のパッケージング、そして重み・データセット・依存関係を記述した暗号学的に検証可能な「モデル部品表(Model BOM)」を意味します。
また、それはサプライチェーンの保護にとどまらず、実行時にもモデルを統治することを意味します。DigiCertのAI Trustフレームワークは、この問題を解決する手段として信頼できるハードウェア実行環境を推奨しています。Intel TDXやAMD SEV-SNP上のトラステッド実行環境(TEE)内で動作するモデルは、メモリ上で暗号化されたままホストOSから隔離されます。
DigiCertは、IETFのRemote ATtestation Procedures(RATS)アーキテクチャに準拠した機密computingアテステーションサービスを運用しています。この構図では実行環境が「証明者(attester)」であり、DigiCertが「検証者(verifier)」、下流のシステムが「依拠当事者(relying parties)」となります。
このアプローチにより、アテステーションはワークロードを実行するクラウド事業者自身ではなく、中立な第三者によって行われることになり、規制対象の購入者にとって有用なものとなります。ハイパースケーラーが自社の完全性を自ら証明するべきではない、という考え方です。
こうした規制対象の購入者は、重い統治上の課題に直面しています。医療分野で問われるのは、FDAの510(k)審査を通過したAIモデルが、実際の臨床現場で稼働しているアルゴリズムとまったく同一のものかどうかという点です。暗号によるアテステーションを用いれば、こうした企業は推論のたびにモデルの完全性を証明できます。これはFDAが2023年に示したソフトウェア完全性検証とSBOM実施に関するサイバーセキュリティガイダンスにも対応するものです。
ただし、一部の規制業界に固有のニーズがある一方で、AIガバナンスは業界横断的な課題です。エージェントがアクセスまたは持ち出せる顧客データを保有する組織であれば、どこであれこうした統制が必要になります。
なぜ今、AIガバナンスを構築すべきなのか
今はまさにエージェント型AIの時代であり、企業は転換点に立たされています。そして、こうした局面を企業はこれまでにも経験してきました。
多くの企業は過去25年間、あるサイバーセキュリティ上のアンチパターンを踏襲してきました。大きな新技術の登場という好機を素早く掴みに行き、後からセキュリティチームを呼んで後始末をさせる、というやり方です。これはうまくいったためしがありません。多くの組織がエージェント型AIへの道のりをまだ歩み始めたばかりである今こそ、その悪習を断ち切り、検証可能な統制を用いて最初から正しく物事を進める好機です。
フロンティアモデルの価格が上昇し、AIが企業予算の中で無視できないコストとして目立つようになるにつれ、これはますます明確な選択として意識されるようになるだろう、とトルズペック氏は結論づけます。企業は、エージェント技術の利用についてより一層人々に説明責任を求めるようになるでしょう。だからこそ、統制を先んじて整え、初めて先手を打てる立場に立てるとしたら、それは望ましいことではないでしょうか。
スポンサー: DigiCert
