AIコーディングエージェントが不適切なアクセス制御を繰り返し実装する理由

AIコーディングエージェントは、コンパイルが通り、レビューを通過しながら、誤ったポリシーを適用する認可ロジックを生成します。不適切なアクセス制御はOWASP Top 10:2025で第1位にランクされており、記録された1,839,701件の発生事例にわたり、テスト対象のアプリケーションの100%で何らかの形で確認されました。これはリスト内のどのカテゴリよりも多い件数です。

このカテゴリの一部は、パターンベースのスキャンでは決して検出できない領域でもあります。エージェントが所有者確認を省略した場合、違反したルールは署名データベースではなく、アプリケーションに属しています。そのため照合できる既知の不正パターンはありません。

不適切なアクセス制御とは？

不適切なアクセス制御とは、認証済みユーザーが何を実行または閲覧できるかを適切に制限できていない状態です。ユーザーが本人確認を済ませると、アプリケーションが他者に属するデータや操作を渡してしまいます。チームが遭遇するケースの大半は、次の2つに分類されます。

1. BOLA：オブジェクトレベル認可の不備

BOLAとは、リクエスト元が要求した特定のオブジェクトにアクセスする権限を持つか確認できていない状態です。OWASP API Security Top 10で第1位にランクされており、現代のアプリケーションに関わるOWASPの両リストで最上位に位置しています。

2. IDOR：安全でない直接オブジェクト参照

IDORとは、攻撃者の視点から見た同じ不備です。アプリケーションがレコードIDなどの内部識別子を公開し、別の値に置き換えると、他のアカウントに属するデータが返されます。通常、1つのバグがBOLAとIDORの両方に該当します。

OWASPは2021年にこのカテゴリをリストの最上位に移し、2025年版までその順位が続いています。これらは単純な欠陥です。それでも上位にとどまるのは、簡単に入り込み、自動検出が難しく、見つかればすぐに悪用する価値があるためです。

AIコーディングエージェントが認可を誤ることが多いのはなぜ？

ソフトウェア開発はエージェント型へ移行しましたが、セキュリティはそうではありません。アプリケーションセキュリティは、既知の不正パターンを照合し、製品のルールを理解する人に結果を引き渡すスキャンを中心に構築されてきました。エージェントがエンドポイントを作成する場合、ループ内の誰もデフォルトでそのルールに従うわけではなく、結果として生じる欠陥に照合できるパターンもありません。このギャップを埋めるには、単にルールを追加するだけでは不十分です。

認可要件が明示されていないからです。エージェントは、与えられたタスクに対して間違っているわけではありません。開発者がコーディングエージェントに、IDで請求書を返すエンドポイントの追加を依頼するケースを考えてみましょう。エージェントは、呼び出し元がログイン済みであることを確認し、URL内の識別子を使って請求書を検索し、一致するものがなければ404を返し、レコードをクライアントに送るルートを生成します。

こうした判断はすべて、記述されたタスクに照らせば正しいものです。エンドポイントは認証を行い、レコードが見つからない場合に対応し、レビューでも読みやすいコードになっています。しかし、URL内の値を1つ変えるだけで、認証済みのユーザーなら誰でもシステム内のあらゆる請求書を読めてしまいます。

修正には検索条件を1つ追加するだけです。請求書の識別子に加えて、呼び出し元が所属する組織でも照合します。エンドポイントのその他の部分は変わりません。

コードだけでは修正方法が分からない理由

2つ目の実装が正しいと判断するには、生成対象のコードには一切記載されていない次の3つの事実が必要です。

• 請求書は組織に属している。

• ユーザーのアクセス範囲は、所属する組織に限定されている。

• この製品では、組織をまたいだ読み取りは決して許可されない。

別の製品では、監査担当者、再販業者、親アカウントなどがテナント境界を越えて読み取れる設計になっている場合もあり、3つ目の事実が当てはまらない可能性があります。このルールは製品の特性であり、言語やフレームワークの特性ではありません。データモデルや、2年前に下された判断、そしてその判断を下したエンジニアたちの知識の中に存在します。

代わりにレビュー担当者が確認すべきこと

そのチームの人間の開発者が通常この問題に気づく理由は、製品を知っているからです。プロンプトと周辺ファイルをもとに作業するエージェントには、確認が必要となる理由を示す情報にアクセスできません。

レビューで押さえておくべき点が2つあります。1つ目はレスポンスコードです。所有者の条件を検索条件に含めることで、別組織の請求書を要求した場合も、存在しない請求書を要求した場合と同じ404が返されます。これが望ましい動作です。403を返すとレコードが存在することを明らかにし、攻撃者が有効な識別子を列挙できてしまうからです。2つ目は、何を返すかです。保存されたレコードをそのまま返すと、すべてのフィールドが送信されるため、同じハンドラーに認可の問題と並んでデータ漏えいの問題も含まれることがよくあります。

SASTツールで不適切なアクセス制御を検出できますか？

パターンが存在する脆弱性クラスでは、検出はおおむね解決済みです。例外は認可であり、AI生成コードが最も弱い領域とまさに重なっています。静的解析は記述可能なパターンを追跡しますが、オブジェクトレベル認可にはそのようなパターンがありません。

対照的な例として、インジェクションを考えてみましょう。インジェクション脆弱性には、信頼されていない入力がサニタイズされずに危険なシンクへ到達する、という記述可能なパターンがあります。そのパターンをルール化し、エンジンがソースからシンクまでデータを追跡して、一致する経路をすべて報告します。

不適切なアクセス制御のうち、静的解析でカバーできるもの

不適切なアクセス制御はOWASP Top 10で最大のカテゴリですが、すべてがスキャンに抵抗するわけではありません。A01:2025には40個のCWEが対応付けられており、そのうちいくつかは、パストラバーサル、オープンリダイレクト、サーバーサイドリクエストフォージェリなど、静的解析が得意とする追跡可能なパターンを持っています。最新のセマンティックエンジンは、シグネチャ照合にとどまらず、データフローとコードの意図をモデル化します。また、コードベース全体で一貫した規約がある場合、ルートに認可デコレーターやミドルウェアが構造的に欠けていることも検出できます。

検出範囲の境界

解析が難しい部分は、より限定的です。それはオブジェクトレベル認可で、CWE-639（ユーザーが制御するキーを介した認可の回避）、CWE-862（認可の欠如）、CWE-863（不適切な認可）として分類されています。ここでは危険な関数は呼び出されず、信頼されていない値が不適切な場所へ到達することもなく、コードはすべて慣用的です。欠陥は、アプリケーション独自のルールだけが求める比較がないことです。

これを検出するには、エンジンがこのスキーマでどのフィールドが所有権を表すのか、どの呼び出し元に権限があるのか、テナント間の境界がどこにあるのかを理解する必要があります。これはルールの品質の問題ではありません。スキャン対象のファイル内には存在しない情報の問題です。

決定論的エンジンと推論は、競い合わせるのではなく、組み合わせるべきです。エンジンは対象とするクラスについて毎回同じ結果を返すため、チームはそれをパイプラインのゲートとして利用できます。オブジェクトレベル認可はルールで記述できる範囲外にあるため、対処には別の手段が必要です。

パターンのない欠陥をどう見つける？

目の前のファイルではなく、アプリケーションのモデルをもとに推論すれば、パターンのない欠陥も見つけられます。

請求書のバグを見つけるには、4つの事実が必要です。このエンドポイントを呼び出すもの、取得対象のオブジェクトが属する先、そのオブジェクトへのアクセス権を持つユーザー、そしてテナント間の信頼境界です。これらの事実は、コードベース、スキーマ、本番環境の実態から把握できますが、解析可能な形に組み立てる必要があります。Snykでは、この組み立てたモデルをアプリケーションコンテキストグラフと呼びます。アーキテクチャ、データフロー、データ分類、信頼境界、本番環境の実態をまとめたもので、コードの変更に応じて更新されます。これがあれば、エンドポイントが適用する制御と、アプリケーション独自のルールが求める制御を解析で比較できるため、所有者確認の欠落が明らかになります。

信頼できる結果を得るには、3つの条件が必要です。

1. 推論は、そのモデルに基づいて行う必要があります。モデルがなければ、最先端の推論は一部を想像で補ったコードベースについて、もっともらしい検出結果を出し、無差別なスキャンにトークンを浪費します。

2. 検出結果は、生成したものとは別の仕組みで確認する必要があります。脆弱性を見つけたエージェントに自ら修正を検証させても信頼できません。また、自分の出力を自分で評価するシステムでは、解析で見落とした問題がそのまま残ります。

3. 修正は提案するだけでなく、立証する必要があります。1行の修正がアプリケーションのルールに照らして検証され、コードが変更されても有効であることを示さなければなりません。修正がマージされないままの検出結果では、エンドポイントは依然として脆弱なままです。

組み立てたアプリケーションを推論で解析し、決定論的エンジンも並行して実行する。これが、8月に初めてプレビュー公開されたEvo Agentic AppSecでSnykが進めている方向性です。その後のランタイムテストで、攻撃者が実際に到達できる範囲を確認します。これが現在のEvo Continuous Offensive Securityの役割です。

今、チームで取り組むべきことは？

まずは、新しいツールを導入せずに始められる5つのステップです。

1. リクエストからオブジェクト識別子を受け取るエンドポイントを洗い出す。URLや本文からID、ファイル名、キーを受け取るすべてのルートが候補です。このリストは、チームが予想するより短いことも、期待するより長いこともあります。

2. 所有権のルールを書き出す。リソースの種類ごとに、何に属するのか、誰が読み取りや変更をできるのかを記録します。認可の欠陥がレビューで見逃されるのは、レビュー担当者や解析ツールが確認できる場所に、こうした情報が書かれていないからです。

3. エージェントが作成したプルリクエストのレビュー項目に、認可を明示的に加える。「注意深くレビューする」という一般的な指示ではなく、具体的に確認します。このエンドポイントは、呼び出し元が対象オブジェクトへのアクセス権を持つか確認しているか？どのフィールドを使って確認しているか？

4. リソースの種類ごとに、テナントをまたぐテストを追加する。OWASPの予防ガイダンスは明確です。開発者とQA担当者は、ユニットテストと統合テストに機能的なアクセス制御テストを含めるべきです。リソースごとに1つ、あるテナントの有効なセッションで別のテナントのオブジェクトにアクセスすると404が返ることを検証するテストを追加すれば、ステップ2で書き出したルールを継続的に適用できます。

5. コードベース全体に対する詳細な解析を定期的に実行する。制御のポイントは3つに分かれています。エージェントの内部ループでのリアルタイム制御、CIで変更のたびに実行する高速な決定論的スキャン、そしてコードベース全体を対象とする詳細なコンテキスト解析です。オブジェクトレベル認可の欠陥は、3つ目で明らかになります。

今日、テナントをまたぐテストに失敗するエンドポイントはどれでしょうか？まずはステップ1の一覧から始めてください。Snykがエージェント型アプリケーションセキュリティで目指す方向については、Evo Agentic AppSecの初公開をご覧ください。