AIセクターでは、高度なモデルのガバナンスやデプロイ前の評価メカニズムについて広範な議論が行われていますが、こうした主要な議論では、AIエージェントが電子メールの送信、暗号鍵の変更、ソフトウェアブランチの統合、資金移動といった機密性の高いアクションを実行できるかどうかを決定する実際のプログラムコードがしばしば無視されています。これらの決定を下すのは大手研究所や規制文書ではなく、真偽値を返す単純なプログラム関数です。
エージェントのアクションを検証するためのオープンソースプロトコル「PIC」に対して実施されたストレステストでは、問題は必ずしも暗号化の失敗に起因するのではなく、プロトコルが複数の、表面上は正しいものの解釈が分かれる可能性のある形式を受け入れてしまうことに起因することが示されました。例えば、構造スキーマは大文字と小文字のハッシュコードを許容する可能性がありますが、インタープリタがシステム間で異なる結果を導き出す方法でこれらを処理し、宣言された標準仕様に違反しないケースがあります。
データ検証におけるJSONスキーマの限界
JSONスキーマはデータ構造の検証において基本的かつ限定的な役割を果たします。必須フィールドの存在、値の型の正確さ、一般的なルールへの適合性を確認しますが、スキーマは、特定の証拠参照がソース配列内の単一の要素を重複や曖昧さなしに指し示していることを保証するといった、複雑な相関ルールを強制することはできません。
プログラミング言語間での検索操作や識別子照合の実装の違いは「パーサーの不一致」として知られる脆弱性を引き起こします。これはHTTPやJWTなどのプロトコルで以前から見られた古いタイプの脆弱性であり、2つのコンポーネントが同じ入力を異なる方法で読み取ることで発生します。最新のエージェントプロトコルでは、こうした微妙な違いにより、同じポリシーと仕様を使用しているにもかかわらず、あるサービスではアクションが許可され、別のサービスでは拒否されるといった事態が生じます。
正規化処理がプロトコルのセキュリティに与える影響
開発者は通常、余分なスペースの削除、小文字への変換、Base64パディングの修正など、復元可能なデータを拒否しないように入力を正規化する傾向があります。しかし、これらの慣行は認証の境界において深刻なリスクをもたらします。例えば、インタープリタがツール名やスペースを許可リストと照合する前に正規化してしまうと、システムは署名当事者が承認していないアクションを実行したり、開発者が意図しない形で実行権限を操作したりする可能性があります。
さらに、エージェント自身が送信するフィールドに依存してソースの信頼性を確認することは、デジタル形式の「混乱した代理人（Confused Deputy）」問題への扉を開くことになります。信頼は、リクエストのペイロードに含まれる主張とは無関係に、デジタル署名を検証し、オペレーターが直接信頼する暗号鍵と照合することによって、法執行と検証の境界内でのみ導き出されるべきです。
3層構造と実行時の照合ベクトル
これらの脆弱性を回避するには、以下の3つの連続した層を明確に分離する構造が必要です：
- スキーマ検証：破損した構造やネットワークに適合しない表現を拒否する。
- 意味的検証：参照の解決、関連付けの確認、実際の信頼の導出を行う。
- ポリシー評価：アクションの実行を許可またはブロックする最終決定を下す。
ドキュメント上の注釈だけでは不十分であり、正確な入力、期待される結果、曖昧なケースを処理するための安定したエラーコードを含む、明確な実行時の適合性テストツールが必要です。これらのベクトルは、すべての実装において動作を統一し、さまざまなソフトウェアブリッジにおける異なるデフォルト設定にセキュリティを依存させることを防ぎます。