シークレットレス・インペラティブ:AIエージェントがコードに触れる時、従来のセキュリティモデルが崩壊する理由
2023年4月、 サムスンは自社のエンジニアが機密情報をChatGPTに漏洩していたことを発見しました。しかし、それは偶発的なものでした。では、もしそのコードリポジトリに、人間には見えずAIによって処理されるように仕組まれた、コードだけでなくAIがアクセスできるあらゆるAPIキー、データベース認証情報、サービストークンを抽出するように設計された命令が意図的に埋め込まれていたらどうでしょうか。これは仮定の話ではありません。 セキュリティ研究者はすでに、この「不可視命令」攻撃が機能することを実証しています。問題は、これが起こるかどうかではなく、いつ起こるかです。存在しなくなった境界線何十年もの間、私たちは基本的な前提に基づいてセキュリティを構築してきました:コードはコードであり、データはデータであるという前提です。SQLインジェクションは、クエリをパラメータ化することを教えてくれました。クロスサイトスクリプティングは、出力をエスケープすることを教えてくれました。私たちは、プログラムの動作とユーザー入力の間に壁を築くことを学びました。AIエージェントにおいて、その境界線は消滅しました。予測可能なパスをたどる決定論的ソフトウェアとは異なり、大規模言語モデルは確率的なブラックボックスであり、正当な開発者の指示と悪意のある入力を区別することができません。攻撃者がAIコーディングアシスタントにプロンプトを入力するとき、彼らは単にデータを提供しているのではありません。彼らは本質的に、アプリケーションをその場で再プログラミングしているのです。入力自体がプログラムになってしまったのです。これは、アプリケーションセキュリティに関する私たちの知見のすべてからの根本的な断絶を表しています。DROP TABLEや<script>タグのような悪意のあるパターンを探す従来の構文ベースのファイアウォールは、自然言語による攻撃に対して完全に無力です。研究者は、プロンプト内の「APIキー」を「リンゴ」に置き換えることで、攻撃者がフィルターを完全に回避できる「意味的置換」技術を実証しています。意図が無害な会話に偽装されているとき、どうやってそれをファイアウォールで防ぐのでしょうか?誰も議論していないゼロクリックの現実ほとんどのセキュリティチームが理解していないことがあります:プロンプトインジェクションは、ユーザーが何かを入力する必要はありません。これらはしばしばゼロクリックエクスプロイトです。AIエージェントが、日常的なタスクのためにコードリポジトリをスキャンしたり、プルリクエストをレビューしたり、APIドキュメントを読んだりするだけで、人間の操作を一切必要とせずに攻撃がトリガーされる可能性があります。研究者がすでに証明した技術に基づく次のシナリオを考えてみてください:悪意のある行為者が、人気のあるオープンソースライブラリのドキュメント内のHTMLコメントに不可視の命令を埋め込みます。GitHub Copilot、Amazon CodeWhisperer、あるいはあらゆる企業向けコーディングアシスタントであれ、このコードを分析するすべてのAIアシスタントは、潜在的な認証情報収集者になります。1つの侵害されたライブラリが、何千もの開発環境の暴露を意味する可能性があります。危険なのはLLMそのものではなく、私たちがそれに与える「エージェンシー(行為主体性)」です。これらのモデルをツールやAPIと統合し、データを取得させ、コードを実行させ、シークレットにアクセスさせた瞬間、私たちは役立つアシスタントを完璧な攻撃ベクトルに変えてしまいました。リスクはモデルの知性に比例して拡大するのではなく、その接続性に比例して拡大するのです。現在のアプローチが失敗する理由業界は現在、モデルの「アラインメント」とより優れたプロンプトファイアウォールの構築に夢中です。OpenAIはより多くのガードレールを追加しています。Anthropicは憲法AIに焦点を当てています。誰もが騙されないモデルを作ろうとしています。これは負け戦です。AIが役に立つほど賢ければ、それは騙されるほど賢いということです。私たちは「サニタイゼーションの罠」に陥っています:より良い入力フィルタリングが私たちを救うと仮定する罠です。しかし、攻撃はHTMLコメント内の不可視テキストとして、ドキュメントの奥深くに埋め込まれたものとして、あるいは私たちがまだ想像もしていない方法でエンコードされて隠される可能性があります。文脈的に理解できないものをサニタイズすることはできず、文脈こそがLLMを強力にしているものなのです。業界は厳しい真実を受け入れる必要があります:プロンプトインジェクションは成功するでしょう。問題は、それが成功したときに何が起こるかです。必要なアーキテクチャの転換私たちは現在、「パッチ適用フェーズ」にあり、必死に入力フィルターと検証ルールを追加しています。しかし、SQLインジェクションを防ぐには、より良い文字列エスケープではなくパラメータ化されたクエリが必要であることを最終的に学んだように、AIセキュリティにはアーキテクチャ的な解決策が必要です。答えは、単純に聞こえるがシステム構築方法の再考を必要とする原則にあります:AIエージェントは、使用するシークレットを決して所有すべきではない。これは、より優れた認証情報管理や改良されたボールトソリューションについてではありません。AIエージェントを、パスワードを必要とするユーザーではなく、独自の検証可能なアイデンティティとして認識することです。AIエージェントが保護されたリソースにアクセスする必要があるとき、それは以下のようにすべきです: その検証可能なアイデンティティを使用して認証する(保存されたシークレットではない) その特定のタスクのみに有効なジャストインタイムの認証情報を受け取る それらの認証情報を数秒または数分で自動的に失効させる 長期間有効なシークレットを保存したり、ましてや「見たり」しない いくつかのアプローチが登場しています。 AWS IAM roles for service accounts、 GoogleのWorkload Identity、 HashiCorp Vaultの動的シークレット、そしてAkeylessのZero Trust Provisioningのような目的特化型ソリューションは、すべてこのシークレットレスの未来を指し示しています。実装の詳細は異なりますが、原則は変わりません:AIに盗むべきシークレットがなければ、プロンプトインジェクションは大幅に小さな脅威になります。2027年の開発環境3年以内に、.envファイルはAI拡張開発において死語となるでしょう。環境変数に置かれた長期間有効なAPIキーは、私たちが平文のパスワードを現在どのように見ているかと同じように、より無知な時代の恥ずべき遺物と見なされるでしょう。代わりに、すべてのAIエージェントは厳格な権限分離の下で動作します。デフォルトでは読み取り専用アクセス。標準としてのアクションホワイトリスト。コンプライアンス要件としてのサンドボックス化された実行環境。私たちは、AIが何を考えるかをコントロールしようとするのをやめ、それが何をできるかに完全に焦点を当てるようになります。これは単なる技術的進化ではありません。信頼モデルの根本的な転換です。私たちは「信頼せよ、ただし検証せよ」から、「決して信頼せず、常に検証し、侵害を前提とせよ」へと移行しています。長く説かれてきたがほとんど実践されてこなかった最小権限の原則は、あなたのジュニア開発者がAIであり、毎日何千もの潜在的に悪意のある入力を処理するとき、非妥協的なものになります。私たちが直面する選択ソフトウェア開発へのAIの統合は避けられず、また大部分は有益です。 GitHubの報告によると、Copilotを使用する開発者はタスクを55%速く完了します。生産性向上は現実のものであり、競争力を維持したい組織はこれを無視できません。しかし、私たちは岐路に立っています。現在の道を進み続け、より多くのガードレールを追加し、より良いフィルターを構築し、騙されないAIエージェントを作れると望むこともできます。あるいは、脅威の根本的な性質を認め、それに応じてセキュリティアーキテクチャを再構築することもできます。サムスンの事件は警告でした。次の侵害は偶発的ではなく、1社にとどまることもないでしょう。AIエージェントがより多くの能力を獲得し、より多くのシステムにアクセスするにつれて、潜在的な影響は指数関数的に大きくなります。すべてのCISO、すべてのエンジニアリングリーダー、すべての開発者にとっての問いは単純です:あなたの環境でプロンプトインジェクションが成功したとき(そしてそれは成功するでしょう)、攻撃者は何を見つけるでしょうか?彼らは長期間有効な認証情報の宝庫を発見するでしょうか、それとも侵害されているにもかかわらず、盗むべきシークレットを持たないAIエージェントを発見するでしょうか?私たちが今行う選択は、AIがソフトウェア開発の最大の加速器となるか、それとも私たちがこれまでに作った中で最大の脆弱性となるかを決定します。安全でシークレットレスなAIシステムを構築する技術は今日存在します。問題は、攻撃者が私たちに強制する前に、それを実装するかどうかです。OWASPはすでにプロンプトインジェクションをLLMアプリケーションのトップ10リスクの第1位と特定しています。 NISTはゼロトラストアーキテクチャに関するガイダンスを開発中です。フレームワークは存在します。唯一の問題は、実装速度と攻撃の進化のどちらが速いかです。