allow、review、quarantineの結果を伴う候補評価を表示するCrucible Model Vetting Firewallダッシュボード。

人工知能サイバーセキュリティソフトウェアエンジニアリング

モデル受入には未解決ステータスが必要である

Ashutosh Singhal 2026年8月9日7 min

AIモデルの受入決定では、アーティファクトの進行を許可する証拠を明示する必要があります。ロード時にブロックされた事象が発生しなくても、静的検査で危険なグローバルが特定された場合、承認という判断は2つの異なる所見を1つの安心できる回答へと圧縮してしまいます。私は未解決の所見を決定後も残し、何がまだ確定されていないのかを明確に説明することを求めます。

当社は、この区別を中心に据えてローカルのModel Vetting FirewallデモであるCrucibleを構築しました。これには合成アーティファクトが使用されており、署名スキャナーはフラグを立てないもののロード時にデータベース操作を試みるファイルや、実行されない条件分岐を持つファイルなどが含まれます。前者は観測された試行がなぜ重要であるかを示しています。後者はより困難な設計課題、すなわち利用可能なチェック結果が食い違っているときに、その不一致が解決されたかのように見せかけることなくどう対処すべきかを浮き彫りにします。

証拠が決定を変える

合成データベースの例では、PickleScanはアーティファクトにフラグを立てません。ロード中に、設定されたCPython監査フックが試行されたSQLiteデータベース操作を記録しブロックします。ローカルパイプラインはQUARANTINEを返し、署名は発行されません。データベース操作は成功しませんでした。有用な証拠とは、試行された影響とその記録されたブロックです。

これにより、スキャナーのクリーンな結果だけでは得られない受入決定の根拠が得られます。チームはスキャナーのラベルにロードに関するすべての疑問への回答を求めるのではなく、禁止された操作を指摘できます。スキャナーは比較対象として依然として有用ですが、フラグが存在しないからといって観測されたブロック済みの試行が無効になるわけではありません。

ブロックされた合成SQLiteの試行、QUARANTINEの判定、およびフラグ未設定のPickleScan結果を示すCrucible — このローカル合成フィクスチャにおいて、PickleScanはアーティファクトにフラグを立てませんでしたが、設定された監査フックはその試行されたSQLite操作を記録してブロックしました。静的な「NO CODE SURFACE」バッジは、設定された拒否リストのグローバルが見つからなかったことを意味しますが、`_sqlite3.connect`は依然として存在しています。スコアボードは固定の合成セットを説明するものであり、未知のモデルのパフォーマンスを示すものではありません。

私がこの分離を好むのは、決定を検証可能にするためです。レビュー担当者は所見と結果の関係を追跡できる必要があります。「設定されたフックがこの試行されたデータベース操作をブロックした」というのは限定された記述です。それは証拠、メカニズム、そしてローカルな判定の理由を明確に特定します。包括的な安全ラベルはそれらの関係性を隠してしまいます。

観測はまた、独自の信頼境界を生み出します。ここではワーカーがPythonサブプロセス内でロードを試行し、設定された監査イベントを監視します。これはOSやコンテナの封じ込めではなく、プロセス分離を伴うデモの計装です。本番設計では、信頼できないアーティファクトを処理する前に、観測ワーカー自体がどのように分離されているかを確立する必要があります。行動の証拠を追加しても、それを収集する環境を精査する義務がなくなるわけではありません。

静かなロードが残す、より困難な問い

条件付きの合成フィクスチャは異なる結果に至ります。静的検査では、builtins.evalが検出されます。これはデモの設定済み危険リストに含まれるグローバルです。この環境では条件分岐が実行されないため、観測されたロードではブロックされた危険事象は記録されません。パイプラインはアーティファクトを署名なしでREVIEWへとルーティングします。その経路では人間の調査は完了していません。

builtins.evalが静的に検出されロード中に危険な操作が観測されなかった合成条件付きフィクスチャに対するREVIEWを示すCrucible — 静的検査で`builtins.eval`が見つかりますが、この観測されたロードでは条件付きの動作は実行されません。REVIEWは未解決の所見を保持するものであり、人間によるレビューの完了を証明するものではありません。これは新規に設定されたチェックとキャッシュされたCodex助言を用いたローカルな合成例です。

検討すべき妥当な対応は3つあり、それぞれ犠牲にするものが異なります。承認は不確実性を受け入れます。拒否はこのアーティファクトの使用を回避しますが、より詳細な調査によって説明できる可能性のあるものを破棄することになります。さらなるレビューは決定を遅らせ、どのような追加証拠があれば判断を変えられるかを定義することを求めます。

この事例では、不確実性が具体的であるため、私はレビューを選びます。特定された静的な懸念と、特定された観測のギャップが存在します。静かな実行では、なぜ危険なグローバルが存在するのか、あるいは分岐に達した場合に何が起こるのかは説明されません。承認にはそのギャップを受け入れることが必要になります。即時拒否は組織のポリシーとして合理的かもしれませんが、それは禁止された影響が発生したという証拠ではなく、未解決の静的証拠に基づいてアーティファクトを除外するという選択になります。

チームが受入ポリシーを策定する際、この区別が重要になります。影響が観測されなかったことが、その影響が発生し得ないという所見へと暗黙のうちに変わるべきではありません。同様に、疑念が攻撃成功の証拠へと暗黙のうちに変わるべきでもありません。REVIEWは、組織が許容できる不確実性のレベルを選択する間、両方の事実を保持する場を提供します。

REVIEWには終了基準が必要である

レビュー状態単独では、コストのかかる保留領域になりかねません。記録が未解決の疑問と次に下すべき決定を説明している場合にのみ、それは価値を持ちます。この例では、疑問は静的グローバルと未実行の分岐に関するものです。調査対象を変更せずに同じ静かなロードを繰り返しても、その疑問に答えることなく別の観測が追加されるだけです。

仮定のエンタープライズプロセスでは、チームは分岐を検査したり、アーティファクトの提供元から信頼できる説明を求めたり、より検査しやすいロードパスを持つ代替アーティファクトを選択したりするかもしれません。これらは提案される対応策であり、このデモが完了するワークフローではありません。それぞれにコストがかかります。より深い検査には専門知識が必要であり、サプライヤーの証拠には独自の検証が必要であり、代替品の選定では必要な機能が犠牲になる可能性があります。選択は、チームがどのような証拠を入手できるか、またそのポリシーがどの程度の不確実性を許容するかに依存します。

私はその選択を明確にしたいと考えます。チームの制約内で懸念を解決できる調査が存在しない場合、アーティファクトを拒否することがレビューの適切な終了となる場合があります。REVIEWは、すべてのファイルが最終的に承認を得られると約束するべきではありません。その目的は、未解決の疑問が判定の中に消えてしまうのを防ぎ、最終的な決定を表明されたポリシーに対して説明可能なものにすることです。

同じ原則がAIによる解説にも当てはまります。デモでは、アナリストとチャレンジャーを組み合わせた助言によって注意を促し、基本のALLOW結果をREVIEWに移行させることはできますが、QUARANTINEを解除することはできません。記録されたプレゼンテーションでは、新規に設定されたチェックとともにキャッシュされたCodex助言が使用されています。ある合成参照記録は、物語を権威として扱うことの危険性を示しています。その助言は署名と昇格を推奨していますが、最終的な構造化された結果はREVIEWであり、署名は発行されません。

したがって、受入利用者は構造化された判定、ゲートの理由、および実際の署名フィールドを読み取る必要があります。有益な解説文は決定を説明できますが、アーティファクトを進行させるための第2の矛盾する許可になってはなりません。最終ゲートよりも推奨文を信頼するレビュープロセスは、本来保持すべきであった区別を見失っています。

承認にも境界が存在する

合成クリーン重みディクショナリは、ローカル開発キーを使用してモデル名、アーティファクトハッシュ、およびインベントリペイロードに対する署名とALLOWを受け取ります。そのトレーニングデータの来歴とファインチューニング履歴はUNKNOWNのままです。ALLOWのみがその署名を受け取り、REVIEWとQUARANTINEは受け取りません。

これはクリーンパスと同様にレビューからの脱出にとっても重要です。ロード時の懸念を解決しても、それ自体でトレーニング履歴が確定するわけではありません。アップストリームの疑問が未解決のままであっても、署名はそのキーに関連する指定されたローカルペイロードを認証できます。チームは、受入証拠がロードの決定に十分であるか、また欠落している来歴が意図された用途に許容できるかを個別に問う必要があります。承認された1つのチェックが、一度も調査していない疑問を決着させるべきではありません。

こちらのCrucible解説では、これらのローカルな例とその証拠を示しています。レジストリ統合、エンタープライズ受入の適用、本番署名の保管は、このデモの範囲外の作業です。その価値は、ローカル実装がエンタープライズに必要なすべての統制を提供するという主張ではなく、可視化された決定境界にあります。

こちらは、ローカル合成モデル審査デモを紹介する創業者の動画です。

受入設計を評価するプラットフォームチームに対して、私は証拠が綺麗に揃わない事例から始めることをお勧めします。何が未解決の所見を可視化し続けているのか、誰が追加調査にコストをかける価値があるかを判断するのか、そしてどのような証拠が結果を変え得るのかを問いかけてください。クリーンなパスを説明するのは簡単です。未解決のパスこそが、責任ある決定を下すのに十分な期間、システムが不確実性を保持しているかどうかを明らかにします。