AI Agents and the Non‑Human Identity Crisis: How to Deploy AI More Securely at Scale
2025/05/27 TheHackerNews — GitHub Copilot のコード補完から、社内のナレッジベースをマイニングして即答するチャットボットにいたるまで、AI は企業の生産性に大きな変化をもたらしている。そこで用いられる、それぞれの新たなエージェントは、他のサービスでの認証を得る必要があるため、企業クラウド全体における NHIs (Non‑Human Identities) の数が静かに増加している。
すでに、この NHI 数により企業は圧倒され、人間一人のユーザーが、少なくとも 45個のマシン ID を使い分ける組織も多いという。すべてのサービス・アカウント／CI/CD ボット／コンテナ／AI エージェントは、他のシステムに安全に接続して作業を行うために、API キー／トークン／証明書などの形式のシークレットを必要とする。
GitGuardian の State of Secrets Sprawl2025 レポートでは、このスプロール化によるコストが明らかにされている。2024 年だけで、2,370 万件を超えるシークレットがパブリック GitHub 上に公開されている。そして、状況は改善されるどころか、Copilot を用いるリポジトリでは、シークレットの漏洩頻度が 40% も増加したという。
人間ではない NHI
システムにログインする人間とは異なる NHI は、認証情報ローテーションの義務付けや、権限の厳密な制限、そして、不要になったアカウントの廃止といったポリシーが、ほとんど無い。
したがって、管理不在の状態で放置されると、密集かつ不透明な高リスク接続の網を張り巡らせる NHI について、また、そのシークレットの存在について、誰もが忘れ去ってしまった後であっても、攻撃者に悪用される可能性が生じるかもしれない。
特に LLM (Large Language Models) と RAG (Retrieval-Augmented Generation) の導入により、このようなリスクを誘発するスプロール化が、爆発的な速度で広がっている。
LLM を搭載する、社内サポート・チャット・ボットを考えてみよう。このチャットボットが、開発環境への接続方法を尋ねられた場合には、有効な認証情報を取り込んだ Confluence ページを取得する可能性がある。チャットボットには、適切な質問をした人に対して、意図せずに機密を公開してしまう可能性があり、また、この情報へのアクセス権を持つ人に対して、容易にログを漏洩する可能性もある。さらに悪いことに、このシナリオでは、LLM は開発者に対して、プレーン・テキストの認証情報を使用するように指示している。したがって、セキュリティ上の問題が、急速に積み重なる可能性がある。
しかし、状況が絶望的だというわけではない。現実に、NHI とシークレット管理に関する適切なガバナンス・モデルを実装すれば、開発者はイノベーションと導入を迅速化できる。
５つの実践的なコントロールで AI 関連の NHI リスクを軽減
AI 駆動型 NHI のリスクを管理しようとする組織は、以下の５つの実践的なプラクティスに重点を置く必要がある。
- データソースの監査とクリーンアップ
- 既存の NHI 管理の一元化
- LLM デプロイメントにおけるシークレット漏洩の防止
- ログ記録のセキュリティ強化
- AI データへのアクセス制限
これらの各領域について、詳しく見ていこう。
データソースの監査とクリーンアップ
初期の LLM は、目新しくも、機能が限られ、トレーニングに使用される特定のデータセットだけにバインドされていた。その一方で、RAG エンジニアリングでは、必要に応じて追加のデータ・ソースへと、LLM がアクセスできるようになり、この状況が変化した。したがって、これらのソースにシークレットが存在する場合には、関連する ID が悪用されるリスクが生じている。
プロジェクト管理プラットフォームの Jira や、コミュニケーション・プラットフォームの Slack、そして、ナレッジベースである Confluence などのデータソースは、AI やシークレットを考慮して構築されていない。したがって、誰かがプレーン・テキストの API キーを追加しても、それが危険であることを警告する安全策が存在しない。つまり、適切なプロンプトさえあれば、チャットボットがシークレット漏洩エンジンへと、容易に変容する可能性がある。
LLM において、これらの内部シークレット漏洩を防ぐ唯一確実な方法は、存在するシークレットの削除もしくは、それらが持つアクセス権限の取り消しとなる。
無効な認証情報が、攻撃者により武器化され、直ちに危険な存在になることはない。理想的には、AI がシークレットを取得する前に、これらのシークレット・インスタンスを完全に削除する必要がある。幸いなことに、GitGuardian のようなツールやプラットフォームを利用すれば、このプロセスを可能な範囲で容易に実践できる。
既存の NHI 管理を一元化してみよう
ケルビン卿の「測定できないものは改善できない」という格言は、よく知られている。それは、NHI のガバナンスにも当てはまる。現時点で保有している、すべてのサービスアカウント／ボット／エージェント／パイプラインを把握しなければ、エージェント AI に関連付けられる NHI に対して、新しく効果的なルールとスコープを適用することは、ほぼ不可能である。
これら、すべての NHI に共通する唯一の点は、すべてにシークレットが含まれるという点である。NHI の定義の方法とは無関係に、認証メカニズムの定義は、すべてに共通するものだ。それがシークレットである。この視点からインベントリを分析することで、シークレットの適切な保管と管理に焦点を絞り込める。それは、決して新しい問題ではない。
それを実現できるツールとしては、HashiCorp Vault／CyberArk／AWS Secrets Manager などが挙げられる。すべてが一元管理され、アカウント管理されるようになれば、長期間にわたり有効な認証情報を使用する世界から、ポリシーによりローテーションが自動的に強制される世界へと移行できる。
LLM デプロイメントにおけるシークレット漏洩の防止
MCP (Model Context Protocol) サーバは、エージェント型 AI が、サービスやデータソースにアクセスするための新しい標準である。それ以前においては、リソースにアクセスする AI システムのコンフィグが必要であり、その都度、自分で配線を理解する必要があった。
MCP が導入するプロトコルは、標準化されたインターフェイスを介して、AI がサービス・プロバイダーに接続するためのものである。これにより作業が簡素化され、統合を機能させる開発者が、認証情報をハードコードする可能性も低くなる。
GitGuardian のセキュリティ研究者が発表した論文の中で、もっとも憂慮すべき点は、すべでの発見された MCP サーバの 5.2% に、少なくとも１つのハードコードされたシークレットが含まれていたことである。この数値は、すべてのパブリック・リポジトリで観測されたシークレットの漏洩発生率 4.6% と比べて、著しく高いものとなる。
他のテクノロジーを導入する場合と同様に、ソフトウェア開発ライフサイクルの早期において、少しでも安全対策を講じることで、その後に予測される甚大なインシデントを未然に防げる。
機能ブランチにある段階で、ハードコードされたシークレットが検出されると、本番環境へのマージと出荷が阻止される。Gitフックやコード・エディタ拡張機能を使って。開発者ワークフローにシークレット検出機能を追加すると、プレーン・テキストの認証情報が共有リポジトリに届かなくなる可能性もある。
ログ・セキュリティの向上
LLM は、リクエストを受け取り、確率的な回答を返すブラックボックスである。基盤となるベクター化は調整できないが、期待通りの出力が得られたかどうかは判断できる。したがって AI エンジニアや機械学習チームは、最初のプロンプト／取得したコンテキスト／生成されたレスポンスといった、あらゆるログを記録し、システムを調整することで、AI エージェントを改善していく。
ログに記録されたプロセスの、いずれかのステップでシークレットが漏洩した場合には、同じシークレットの複数のコピーが、サードパーティ製のツールやプラットフォームに存在すると予測できる。つまり、多くのチームにおいて、調整可能なセキュリティ対策が講じられることなく、クラウド・バケットにログが保存されている。
最も安全な方法は、ログを保存する前に、また、サードパーティに送信する前に、サニタイズ手順を追加することである。その設定においては、多少のエンジニアリング作業が必要となるが、GitGuardian の ggshield などのツールは、クシュのスクリプトからプログラム的に呼び出されるシークレットを、スキャンする際に有用である。シークレットが排除されるなら、リスクは大幅に軽減される。
AI データ・アクセスの制限
CRMへのアクセスを、LLM に許可すべきだろうか？ これは難しい問題であり、その答えは、状況により大きく異なる。SSO で保護された社内のセールス・ツールで、メモを素早く検索して配信効率を向上させるものであれば、許容できるかもしれない。しかし、Web サイトのトップページに配置される、カスタマー・サービス・チャットボットの場合は、絶対に許可すべきではない。
権限の設定において、最小権限の原則に従う必要があるのと同様に、導入する AI にも同様の最小アクセスの原則を適用すべきである。物事をスピードアップさせるという名目で、あらゆる機能へのフルアクセスを AI エージェントに与えてしまいたくなる、きわめて強い誘惑があるだろう。
イノベーションを、早期に阻害してしまうような事態は避けたい。アクセス権限を制限しすぎると、RAG モデルの目的が損なわれる。しかし、アクセス権限を与えすぎると、不正使用やセキュリティ・インシデントの発生につながる。
開発者の意識向上
冒頭のリストでは触れていないが、これらのガイダンスは、適切な担当者に提供されることで、はじめて意味を持つ。
最前線で働く人々は、効率と安全を考えながら、業務を遂行するためのガイダンスとガイドラインを必要としている。魔法のようなテクノロジーによる、解決策があれば良いのだが、安全を担保しながら AI を大規模に構築／展開するには、適切なプロセスとポリシーについて、人間同士が共通の認識を持つことが重要となる。
開発に携わっている人々は、この記事をセキュリティ・チームと共有し、組織内で AI を安全に構築する方法について意見を交換してほしい。セキュリティを担当する人々は、この記事を開発者や DevOps チームと共有してほしい。そこで深めてほしいのは、「いま、ここに AI がある。AI を構築し、AIと共に発展していく上で、安全性が不可欠である」という議論である。
マシン ID のセキュリティ確保は、より安全な AI 展開につながる
AI 導入における次のステップは、NHI を人間のユーザーと同様に、厳格かつ慎重に扱う組織に委ねられるはずだ。そこで必要とされるのは、継続的な監視／ライフサイクル管理／堅牢なシークレット・ガバナンスを、標準的な運用手順に組み入れることだ。セキュアな基盤を速やかに構築することで、企業はセキュリティを犠牲にすることなく、自信を持って AI イニシアチブを拡大し、インテリジェント・オートメーションの可能性を最大限に引き出せるはずだ。
1人の人間ユーザーに対して 45個の NHI を管理している組織もあるというのは、正直いって驚きでした。業務効率化の裏側で、こうした “人ではない存在” が次々とシステムにアクセスし、密かに増殖している状況は、まさに可視化し難いセキュリティ・リスクだと感じます。よろしければ、以下の関連記事も、カテゴリ NHI／カテゴリ _AI/MLと併せて、ご参照ください。
2025/05/08：AI と NHI：非人間 ID の管理が鍵
2025/01/27：OWASP の NHI Top-10 とは？
IoT OT Security News 
You must be logged in to post a comment.