AI の jailbreak 問題はなくならず、コンプライアンスの枠組みも追いつく必要があります

AI の安全対策に関する、耳の痛い真実

ほとんどのAIベンダーははっきり言わないのですが、次のような事実があります。今日展開されているすべてのモデルは、ある種の jailbreaking に対して脆弱です。プロンプトインジェクション、ロールプレイ攻撃、間接的なプロンプト操作、コンテキストドリフト。これらはすでに文書化されており、ますます自動化され、そして今まさに企業のAI導入環境に対して使われています。

しかし、最も危険な jailbreak の攻撃経路の多くは、そもそもモデルを狙いません。狙うのは、その周囲のインフラです。構成ファイル、デプロイ設定、監視コントロール、そして本番環境でモデルがどのように振る舞うかを決める監査パイプラインなどです。

正しい安全対策の制御を無効化し、正しい設定パラメータを変更すれば、賢いプロンプトなんて要りません。もう勝っています。

これは典型的な設定の整合性（configuration integrity）の問題です。そして、それについて私たちは正しく考える方法を知っています。

AIインフラの改ざんは実際にはどのように見えるのか

インフラの観点からAIシステムを守るという話は、多くの組織がまだ正式な変更管理の対象として位置づけていない、特定の一連の資産を保護することを意味します。

システムプロンプトファイルとポリシールールセット

多くのエンタープライズAIの導入では、モデルの振る舞い、コンテンツポリシー、アクセス制限を定義する保存済みのシステムプロンプトファイルに依存しています。これらのファイルはディスク上、または設定ストアに置かれています。多くの場合、ファイルシステムへのアクセス権を持つ誰でも編集できてしまいます。システムプロンプト内の1つの指示が変わるだけで、モデルが行う／行わないことが根本的に変わり得ますが、モデルレベルのセーフガードが発動することはありません。

モデルのデプロイ設定

温度、コンテキストの長さ、ツールへのアクセス、安全フィルターの有効化を制御するパラメータは、通常、設定ファイルまたは環境変数に保存されます。これらの設定を無断で変更すると、モデル自体に触れることなく安全な挙動を抑制することができます。

安全フィルターおよびコンテンツポリシーの設定

多くの AI プラットフォームでは、コンテンツのフィルタリングをモデルとは別の層として実装しています。これらのフィルタ自体もソフトウェアであり、設定ファイル、ポリシー定義、バージョン管理されたルールセットが含まれます。こうしたファイルを変更できる攻撃者は、モデルが生成する内容に対する基準を静かに引き下げることができます。

監視およびログ記録のパイプライン

監査証跡は、改ざんされずにそのまま保たれている場合にのみ有用です。攻撃者が AI システムのログ記録設定を無効化したり変更できるなら、自身の活動を隠して、フォレンジック調査を大幅に難しくできます。

これらの攻撃ベクトルはいずれも、高度なプロンプトを必要としません。必要なのはアクセス、機会、そして変更モニタリングがないことです。構成インテグリティ（configuration integrity）ツールが、まさにこのギャップを埋めるために設計されています。

Change Tracker はどこに位置づけられるか

Netwrix Change Tracker は、まさにこの種の課題のために作られました。重要なシステム全体で既知の良好なベースライン（known-good baseline）を維持し、それからのあらゆる逸脱をリアルタイムで検知します。

AI インフラに適用すると、つまり：

AI 設定アセットのためのファイル整合性モニタリング

Change Tracker は暗号学的ハッシュを使用して、監視対象のすべてのファイルに対する検証済みのベースラインを確立します。システムプロンプトのファイル、安全ポリシー定義、またはモデル設定が変更された場合、正当な更新であっても不正な改変であっても、Change Tracker は直ちに検知します。すべての変更は、タイムスタンプ、変更を行ったユーザーの身元、および変更された具体的な属性とともに記録されます。曖昧さはありません。コンテキストの欠落もありません。

Windows では、Gen 7 Agent の minifilter ドライバーがカーネルレベルで動作し、Windows Filter Manager スタックの altitude 388790 に配置されています。ファイルをロックしたりレイテンシを追加したりすることなく、ファイル I/O の変更をリアルタイムでキャプチャします。Linux では、Sysdig の統合によりシステムコールレベルで誰が変更を行ったかを取得します。いずれの環境でも、検知は継続的であり、フォレンジックにおいて正確です。

強化されたベースラインに対するセキュリティ設定管理

CIS Benchmarks サーバー設定を強化するための、指示に基づく出発点を組織に提供します。Change Tracker には、CIS、NIST 800-53、PCI DSS、HIPAA、DISA STIG などに対応付けた 250 以上の事前構築済みコンプライアンス レポートが付属しており、Windows、Linux、データベース、ネットワーク機器をカバーします。AI インフラに関しても、同じ強化の考え方が当てはまります。攻撃対象領域を減らし、OS レベルで最小権限を徹底し、デプロイした構成が実際に稼働している構成と一致していることを継続的に検証します。

AIシステムの変更のためのクローズドループ変更管理

AIのデプロイに対する正当な変更はすべて、実行される前に承認されるべきです。Change Tracker のクローズドループ変更管理は、ITIL および COBIT の原則と直接整合しています。計画された変更は事前に文書化され、承認済みの変更ウィンドウに照らして追跡され、観測されたアクティビティと自動的に突合されます。承認された変更依頼と一致しない変更（つまり未計画の変更）は、アラートとして直ちに表面化します。

ServiceNow、BMC Remedy、またはその他の ITSM プラットフォームを利用しているチームの場合、Change Tracker のネイティブ連携により、変更要求が自動的に取り込まれ、検出された変更を分類するために使用されます。承認済みチケットの外で AI インフラが変更された場合は、そのことが分かります。承認されたチケットの中で変更された場合はノイズが抑えられ、チームは本当に重要なことに集中できます。

ハイブリッドな AI 環境全体を対象としたエージェント／エージェントレスのカバレッジ

AI インフラは 1 か所に集約されません。計算基盤はオンプレミスにある場合もあります。モデルのホスティングは AWS や Azure にあるかもしれません。構成管理は複数のツールを組み合わせて行うこともあります。Change Tracker は、Windows と Linux で Gen 7 Agent を使ったエージェントベースの監視に対応し、エージェントの展開が現実的でないシステムでは SSH と WMI によるエージェントレスのカバーも提供します。ESXi とクラウド環境は、PowerCLI ベースのエージェントレス収集で対応します。監視のモデルは、インフラのモデルに合わせて設計されています。

コンプライアンスとフォレンジックのための不変の監査証跡

AIシステムで何かがうまくいかなかったとき、たとえば予期しない出力であったり、報告された安全性の不具合であったり、あるいはインフラの侵害が疑われる場合でも、最初に必ず問うべきことは「何が変わったのか？」です。 Change Tracker は、監視対象システム全体におけるあらゆる設定変更について、継続的かつ改ざんが分かる形で記録を保持します。その記録はすぐに利用でき、検索でき、監査人の要件を満たし、インシデント調査を支援する形式でエクスポート可能です。

規制が不足しているところ

EUのAI Actは意義のある一歩です。NISTのAI Risk Management Frameworkも、よく考えられています。とはいえ、どちらも、AIの導入・展開の周辺で実際に備えておく必要がある運用上のセキュリティ管理策を十分には扱えていません。つまり、セキュリティチームが実際に実装し、それに対して監査を行うような管理策のことです。

私が主張したいのは、あらゆるエンタープライズ向けAI導入において「最低限の基準として、必須要件にすべきもの」です。AI専用のガイダンスがまだ十分に整っていないとしても、CIS Controlsはすでにこの方向を示しています:

継続的な構成の監視

AIシステムの構成は、許可されていない変更がないかを継続的に監視する必要があります。例：バージョン、パラメータ、ガードレールなどのオンプレミスでのモデル配備。システムプロンプト、アイデンティティファイル、メモリストア、ツール定義などのエージェントの実行環境。さらに、MCPサーバー、キーボルト（key vaults）、資格情報ストア（credential stores）、監査パイプライン（audit pipelines）、スキルマーケットプレイス（skill marketplaces）のように、エージェントが認証し、書き込む外部インフラ環境。四半期ごとに見直さない。配備時に確認しない。継続的に。承認済みのベースライン（approved baseline）から何かが逸脱したときはリアルタイムでアラートを出す。

正式な変更管理

AIシステムへのあらゆる変更には、承認、ドキュメント化、レビューが必要です。官僚的な手続きのためではなく、計画されていない変更こそが、攻撃者と事故の両方が隙（opening）を作る方法だからです。クローズドループ（Closed-loop）による変更管理は、変更をリスクから証拠へと変えます。

AIアセットのためのファイル整合性監視

システムプロンプトのファイル、セーフティルールセット、モデル設定ファイルには、重要な OS ファイルと同等の完全性要件を適用する必要があります。SHA-256 ハッシュ検証。ベースラインとの比較。差異が生じたら直ちにアラート。これは PCI DSS の準拠における標準的な実践です。AI の導入においても同様に標準的な実践とすべきです。

改ざん不可の監査証跡

AI インフラに関わるすべての管理操作、設定変更、ポリシーの変更、およびセキュリティイベントは、簡単に改ざんされたり削除されたりできない形でログとして記録する必要があります。このログは、フォレンジックのためのリソースであると同時に、コンプライアンス上の成果物でもあります。

AI インフラに対する最小権限

AI の導入環境への特権アクセスは、Active Directory や重要なデータベースへのアクセスを管理するのと同じやり方で統制すべきです。つまり、厳格な管理、完全な説明責任、そして誰がアクセス権を持っているのか／その権限で何を行っているのかを継続的に監視します。

防御の多層化（defense-in-depth）の重要性

プロンプト レベルの安全策に注目することは重要ですが、それによって「AI セキュリティが実際に何を意味するのか」について誤った認識が生まれています。組織は、制御されたテスト環境で自社のモデルが jailbreak にどれだけ耐えられるかを基準に AI ベンダーを評価している一方で、その周辺のインフラは本質的に統制されないまま放置されています。

攻撃者はすでにこれを知っています。彼らは、巧妙なプロンプトを作ることに時間をすべて費やしているわけではありません。狙うのは、運用チェーンの中で最も弱い部分です。監視されていない設定ファイル、権限が過剰なサービスアカウント、静かに無効化された安全フィルター、そして誰も記録していない変更です。

それはモデルの問題ではありません。構成（configuration）と変更管理（change control）の問題です。そして、規制対象のワークロードを運用している組織がすでに展開方法を知っている、単純明快な解決策があります。

次にやるべきこと

規制当局は、より迅速に動く必要があり、かつ具体的に動く必要があります。AI ガバナンスに関する幅広い原則は出発点にはなり得ますが、実際にセキュリティチームが必要としているのは、具体的で監査可能なコントロール要件です。つまり、実装し、テストし、継続的に検証できる種類のものです。

IT インフラに対してすでに CIS Controls が定めている内容をモデルにし、さらに AI デプロイ環境へ明確に拡張した、必須のベースライン・コントロールは、組織にとって実用的な出発点となり、監査人にとって意味のあるベンチマークになります。構成の監視。変更管理。ファイル整合性の検証。監査証跡（audit trail）の要件。これらは、これまで十分に精査されてこなかった状況に適用する、規律あるセキュリティ実践にほかなりません。私たちは、それらのソリューションがどのようなものになるのかを知っています。ツールは存在します。フレームワークも存在します。コントロールを義務化する時が来ました。