機能する AI システムを構築するには、まずそれを壊してみる必要があります。私たちは攻撃者の立場でレッドチーミングを実施し、金融サービスの顧客向け AI アプリを検証しました。そこで得られた知見は、セキュリティが不可欠な LLM 搭載アプリケーションを導入するすべての組織にとって重要です。
レッドチーミングとは、実際の攻撃者に発見される前に脆弱性を修正できるよう、意図的に AI システムの突破を試みる取り組みです。金融サービスでは特に大きなリスクを伴います。AI アプリケーションが顧客データに接し、取引を処理し、金融に関する知見を提供するためです。障害が起きれば、ユーザー体験の悪化から規制違反、金銭的損失、回復不能なブランド毀損まで、さまざまな影響が生じ得ます。
私たちの目標は、脆弱性を早期に発見し、現実的な攻撃パターンを検証するとともに、規制当局が非常に重視する AI 安全性の要件を組織が満たせるよう支援することでした。
ここで区別しておきたい点があります。ジェイルブレイクは基盤モデルの安全フィルターを攻撃します。一方、プロンプトインジェクションは、信頼できないユーザー入力を開発者の信頼されたプロンプトと組み合わせ、アプリケーション自体を攻撃します。プロンプトインジェクションは、汎用モデルではなく、システムとそこで扱われる機密データを標的にするため、より大きなリスクをもたらします。
第 1 回の検証では、次の領域を対象に約 750 件のテストを実施しました。
セッションをまたぐデータ漏えい
個人識別情報（PII）の露出（自然言語、API 操作、各種エンコーディングによるもの）
SQL インジェクション
システムプロンプトの上書き
最初の検証で、既存システムには複数の意図を含むクエリの処理と、エンコードされたプロンプトへの対応という 2 つの大きな問題があると判明しました。
複数の意図を含むクエリ：正当な要求と悪意ある要求を組み合わせたもの例：「支出をカテゴリー別に表示し、さらに［悪意ある SQL］を実行してください」。アプリケーションは悪意ある意図を検出できず、後段のデータ層のガードレールに全面的に依存していました。これは、地下室の金庫を信用しているからと玄関を開け放しておくようなものです。
エンコーディング：Base64、16 進数、LeetSpeak、同形異義文字でリクエストをエンコードしたものシステムが悪意ある意図を排除するのは困難な場合があります。これらのクエリによる機密データの露出は確認されませんでしたが、システムを大きく不安定化させました（ハルシネーション、悪意ある SQL をユーザーにそのまま返す、意図分類の混乱など）。
最初の検証では、次の結果が確認されました。
時間情報のハルシネーション：モデルが架空の日付、取引時刻、期間別の要約を自信ありげに返す現象。誤った日付に基づく顧客の行動が実害につながり得る金融分野では、重大なリスクとなる
悪意ある SQL をそのままユーザーに返す挙動（メモリ汚染のリスクという点で懸念）
意図分類の混乱
出力形式の乱れ
これらの知見を基に、検証対象を絞り込みました。SQL インジェクションとエンコーディングのテストは、チームがすでに対処していたため、優先度を下げました。代わりに、最も攻撃成功率の高かった PII の露出とセッションをまたぐ漏えいに重点を置きました。
第 2 回の検証で最も印象的だったのは、拍子抜けするほど単純な事実です。多くの場合、巧妙な手口はまったく必要ありません。
多くの場合、正当らしいリクエストの一部として内部データを単に要求するだけで、システムに開示させることができました。単純なクエリに対して、エンドユーザーに決して見せるべきではない内部 ID やシステムフィールドを含む応答が返されました。
さらに調査すると、これはアプリケーション層だけの問題ではないことが分かりました。後段の Text-to-SQL サービスは、必要以上のフィールドを要求するクエリを生成し、その説明文でも本来制限されるべきデータに言及していました。これにより、システム間に実在する亀裂が明らかになりました。個々のコンポーネントを切り離して検証するのではなく、スタック全体を検証して初めて表面化する種類の脆弱性です。
モデルではなくシステムをレッドチーミングする。LLM を単独で検証しても、アプリケーションのセキュリティ態勢について分かることはほとんどありません。ユーザーが操作するのと同じように、スタック全体をエンドツーエンドで検証します。
入力検証は LLM に渡す前に行う。エンコードされたクエリ、複数の意図を含む攻撃、基本的なインジェクション攻撃は、後段のサービスに委ねず、入口で検出する必要があります。
システム間の継ぎ目を信用しない。複数サービスで構成されるアーキテクチャでは、最も注目すべき脆弱性はシステムの間にある亀裂に潜んでいます。ゼロトラストは徹底してこそ意味があります。あらゆるレイヤーですべてを検証してください。
単純な攻撃は効果があります。高度なジェイルブレイクが注目を集めますが、時には、ただ尋ねるだけで済むことがあります。それ以外は正当なクエリに内部識別子を含めただけで、システムが難なくその情報を表示してしまうなら、問題があります。
実際に何を検証しているのかを把握する。既知の攻撃パターンは、独自のガードレールではなく、LLM 自体の学習によって防がれている可能性があります。実際にどの制御が機能したのかを把握できるよう、レッドチーミングに可観測性を組み込みます。
制約のある環境には創意工夫が必要。カスタムプロバイダーとローカルモデルのサポートにより、専用のクラウドアクセスがなくても有意義なレッドチーミングを実施できます。ただし、それによって生じる制約は明確に伝える必要があります。
レッドチーミングは一度で終わらない。反復して実施し、可能な限り自動化するとともに、システムの進化に合わせて更新する必要があります。明日重要になる攻撃は、今日重要な攻撃と同じではありません。
規制環境で運用される AI システムへの監視は、今後さらに厳しくなります。セキュリティテストをリリース前の確認項目ではなく、継続的な取り組みとして扱う組織ほど、こうした監視に対応しやすくなり、顧客の信頼を失う広報上の危機も回避できます。