企業のセキュリティやコンプライアンスの規則をコードで管理する「Policy as Code」が広がる中、AIが生成したポリシーによって不正なアクセスを許してしまう恐れがあることが指摘されている。見た目には正しく動作していても、条件の欠落や属性の誤解釈によって、本来認めるべきでない権限が付与される可能性があるためだ。

Appleのシニアセキュリティエンジニアで独立研究者でもあるバチャル・グプタ氏はSecurityWeekのインタビューで、「LLMが生成したポリシーは、文法的には正しくても意味的には誤っている場合が多い」と述べた。条件が1つ抜けたり、属性の意味を取り違えたりするだけで、「誰が何にアクセスできるか」は大きく変わるという。

グプタ氏は、こうした誤りの典型例として5つのパターンを挙げた。

1つ目は、文脈条件の欠落だ。地域、部署、所有権などを基準にアクセスを制限すべきポリシーで条件が抜け落ちると、一見正常に見えても、適用範囲が過剰に広がる恐れがある。

2つ目は、拒否ロジックの欠落だ。アクセス制御は通常、「原則拒否」を前提に必要な例外を追加していくが、AIが例外条件だけを拾い、基礎となる制限を落としてしまうことがある。

3つ目は、ハルシネーション（幻覚）だ。実在しない属性をポリシーに含めてしまうケースで、コード自体はコンパイルできても、実行時に想定外の挙動を招く可能性があるという。

4つ目は、時間や状況に関する条件の単純化だ。特定の時間帯や承認手続きが必要なアクセスが、条件なしで常時許可される形に置き換わることがある。5つ目は行為の誤分類で、削除のような機微な操作を制限しようとして、より広い操作を制限したり、別の操作を対象にしたポリシーが生成されたりするという。

グプタ氏は「こうした誤りは、ビルドエラーやアラートを伴わないまま、静かにアクセス範囲を広げてしまう」と警鐘を鳴らした。さらに、ポリシーは一度作って終わりではなく、生成、修正、配布が繰り返されるため、小さな誤りでも蓄積していくと指摘した。

生成プロセス自体を信頼できなければ、リスクはシステム全体に波及する。数千件のポリシーに小さな欠陥が散在すれば、個別には軽微に見えても、全体として把握しにくい攻撃面を生み出す可能性があるという。

その上で同氏は、AIの活用をやめるべきだと主張しているわけではないと説明した。必要なのは利用停止ではなく、信頼モデルの見直しだという。生成したポリシーを無条件で正しいものとみなすのではなく、生成と適用の間に検証プロセスを設けるべきだとした。

「自動化そのものを目的にしてはならない。目指すべきなのは、正確性、監査可能性、信頼だ」と同氏は述べた。その上で、「アクセス権限の領域では、『ほぼ正しい』では不十分だ」と強調した。