秘密なしの義務：伝統的なセキュリティモデルは、AIエージェントがコードに触れたときに壊れる理由

2023年4月、サムスンは、エンジニアがChatGPTに機密情報を漏らしたことを発見した。しかし、それは事故であった。では、コードリポジトリに故意に埋め込まれた指示が含まれていると想定してみる。人間には見えないが、AIによって処理される指示で、コードだけでなく、APIキー、データベース資格情報、サービストークンなど、AIがアクセスできるすべての情報を抽出するように設計されている。このことは仮定ではない。セキュリティ研究者はすでにこれらの「見えない指示」攻撃が機能することを実証している。疑問はそれがいつ起こるかではなく、起こるかどうかである。

もはや存在しない境界

数十年間、私たちはセキュリティを基本的な前提に基づいて構築してきた。コードはコードであり、データはデータである。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エージェントを、パスワードが必要なユーザーではなく、ユニークで検証可能なIDとして認識することについてである。AIエージェントが保護されたリソースにアクセスする必要がある場合、次のようにする必要がある。

1. 検証可能なID（保存されたシークレットではない）を使用して認証する

2. 特定のタスクにのみ有効な、ジャストインタイムの資格情報を受け取る

3. 数秒または数分以内に自動的に期限切れになる資格情報

4. 長期的なシークレットを保存したり「見たり」することはない

いくつかのアプローチが登場している。AWS IAMロール、GoogleのワークロードID、HashiCorp Vaultのダイナミックシークレット 、およびAkeylessのZero Trustプロビジョニングなどの特定の解決策はすべて、シークレットなしの未来に向けての道を示している。実装の詳細は異なるが、原則は同じである。AIエージェントがシークレットを盗むことができない場合、プロンプトインジェクションは大幅に小さな脅威になる。

2027年の開発環境

3年以内に、.envファイルはAIを使用した開発で死に絶える。環境変数に長期的なAPIキーを置くことは、現在のプレーンテキストのパスワードのように、よりナイーブな時代の恥ずかしい遺物と見なされるようになる。

代わりに、すべてのAIエージェントは厳格な特権分離の下で動作する。デフォルトでは読み取り専用。アクションのホワイトリスト化が標準となる。サンドボックス化された実行環境がコンプライアンス要件となる。AIが何を考えるかを制御するのではなく、AIが何をするかを完全に制御することに集中する。

これは技術的な進化だけではなく、信頼モデルにおける根本的なシフトである。私たちは「信頼して検証する」から「信頼しない、常に検証し、危害を受けることを前提とする」に移行している。最小特権の原則は、長い間説かれてきたが、まれにしか実践されなかったが、AIエージェントが毎日数千の潜在的に悪意のある入力を処理する場合、非交渉となる。

私たちが直面する選択

ソフトウェア開発へのAIの統合は、避けられないものであり、主に有益である。GitHubは、Copilotを使用する開発者が55%のタスクを速く完了できると報告している。生産性の向上は実際であり、競争力を維持したい組織はそれを無視できない。

しかし、私たちは分岐点に立っている。現在の道を続けることができる。ガードレールを追加し、フィルタを改善し、トリックできないAIエージェントを作ることを希望する。あるいは、脅威の根本的な性質を認識し、セキュリティアーキテクチャをそれに応じて再構築することができる。

サムスン事件は警告の発射であった。次の侵害は偶発的ではなく、1社に限定されないだろう。AIエージェントがより多くの機能とシステムにアクセスするにつれて、潜在的な影響は指数関数的に増大する。

CISO、エンジニアリングリーダー、開発者にとっての質問はシンプルである。プロンプトインジェクションがあなたの環境で成功したとき（そして成功するだろう）、攻撃者は何を見つけるだろうか。長期的な資格情報の宝庫を見つけるだろうか、それともシークレットを盗むことができないAIエージェントを見つけるだろうか。

私たちが今選択することは、AIがソフトウェア開発の最大の加速器か、最大の脆弱性かどうかを決定する。セキュアでシークレットなしのAIシステムを構築する技術は、今日から利用可能である。質問は、攻撃者が私たちを強制する前にそれを実装するかどうかである。

OWASPはすでにプロンプトインジェクションをLLMアプリケーションのトップ10リスクの1つとして識別している。NISTはゼロトラストアーキテクチャに関するガイダンスを開発中である。フレームワークは存在する。唯一の疑問は、実装の速度と攻撃の進化の間のバランスである。

Bio：Refael Angelは、Akeylessの共同創設者兼CTOであり、同社の特許取得済みのZero-Trust暗号化技術を開発しました。暗号化とクラウドセキュリティの分野で深い専門知識を持つベテランソフトウェアエンジニアです。Refaelは、IntuitのイスラエルのR&Dセンターでシニアソフトウェアエンジニアを務め、パブリッククラウド環境での暗号化キーの管理システムを構築し、マシン認証サービスを設計しました。彼は19歳でエルサレム工科大学でコンピューターサイエンスの学士号を取得しました。