Amazonが提供するAI搭載ビジネスインテリジェンスプラットフォームで新たに発見されたセキュリティ欠陥により、制限されたユーザーが管理者の明示的な拒否にもかかわらず、コントロールを静かにバイパスしてAIチャットエージェントと対話できることが明らかになりました。
Fog Securityの研究者Jason Kaoによって発見されたこの問題は、モダンなAI統合クラウドサービスにおけるユーザーインターフェースの制限とバックエンド実装の間に存在する重大なギャップを露呈しています。
Amazonクイックのセキュリティ欠陥
この脆弱性は、Amazon QuickのChat Agent APIにおけるサーバー側の認可チェックの欠落に起因していました。管理者はカスタム権限設定を通じてAIチャットアクセスを制限することができましたが、これらの制限はユーザーインターフェースでのみ実施され、APIレベルでは実施されていませんでした。
バックエンドエンドポイントに直接HTTPリクエストを送信することにより、ユーザーはアクセス制御違反をトリガーすることなくAIチャットエージェントと対話することができました。簡単に言うと、システムは外部からはロックされているように見えましたが、バックエンドのドアは開いたままでした。
たとえば、制限されたユーザーは「マンゴーについて教えてください」という基本的なプロンプトのようなリクエストを送信することができ、そのアカウントに対してすべてのAIチャット機能が無効になっているはずであるにもかかわらず、有効なAI生成応答を受け取ることができました。

セキュリティ研究者は、このタイプの欠陥をCWE-862(認可不足)として分類しています。これはシステムがサーバー側で権限を適切に検証できない周知の問題です。
この欠陥はクロスアカウントまたはクロステナントアクセスを許可しておらず、攻撃者が他の組織に侵入するのを防いでいました。
しかし、同じアカウント内のユーザーは管理上のコントロールをバイパスすることができました。これらのコントロールは、ガバナンス、コンプライアンス、および不正なAI使用の防止のためにしばしば依存されるものです。
Amazon Quick(旧QuickSightとして知られ、現在はより広い「Quick Suite」の一部)は、エンタープライズSaaSプラットフォームとして広く使用されています。Slack、Microsoft Teams、CRM、および内部データベースなどのサービスと統合し、AIエージェントがビジネスデータを分析して操作することを可能にします。
組織は、以下のようなリスクを防ぐためにしばしばこのようなAI機能をオフにします:
- 不正なデータ露出
- シャドウAI使用
- 規制コンプライアンス違反
この脆弱性は、これらのセーフガードを効果的に損なわせました。
さらに問題を複雑にしているのは、サービスが有効化されるとAWSが自動的にデフォルトのAIチャットエージェントをプロビジョニングすることです。これにより、管理者がAI機能を完全にオフにすることを意図している環境においても、攻撃面が増加します。

Fog Securityはこの問題をAWSに報告し、2026年3月4日にHackerOneの脆弱性開示プログラムを通じて報告しました。AWSは迅速に対応し、3月11日に初期リージョンで修正をデプロイし、3月12日にグローバルロールアウトを完了しました。
修正前のBURPリクエスト、AIチャットエージェントとの成功した対話を示す
修正後、認可されていないAPIリクエストは適切な401無認可応答を返すようになり、サーバー側のチェックが最終的に実装されていることを示しています。
しかし、AWSは脆弱性を重大度「なし」に分類し、公開アドバイザリーまたは顧客通知を発行しませんでした。脆弱性が明示的な管理上のコントロールをバイパスしたことを考えると、この決定はセキュリティ専門家の間で懸念を引き起こしています。
断片化されたアクセス制御
この問題の背景にある重要な要因は、Amazon Quickがアクセスをどのように管理しているかにあります。ほとんどのAWSサービスはAWS Identity and Access Management(IAM)に依存していますが、Quickは別の「カスタム権限」システムを使用しています。
これは矛盾を生じさせます:
- IAMポリシーとサービスコントロールポリシー(SCP)はAIチャットエージェントを制限できない
- Quick固有のカスタム権限のみが適用される
- バックエンドAPIは初期段階ではこれらのカスタム権限を完全に無視していた
この断片化されたモデルは、設定エラーと実装のギャップのリスクを増加させます。
このインシデントは、クラウドおよびAIセキュリティにおける増大する課題を浮き彫りにしています。UIとAPIの両方のレイヤー全体でアクセス制御を一貫して実装することを確保することが必要です。
組織がAI搭載ツールを急速に採用するにつれて、セキュリティメカニズムも同様に迅速に進化する必要があります。インターフェースレベルでのみ機能するコントロールは十分ではありません。特にAPIに直接アクセスできる場合はなおさらです。
AWSは問題を修正しましたが、透明性と公開開示の欠如により、顧客はコントロールが以前は効果的でなかったことを認識していないままかもしれません。
このケースは、AI駆動プラットフォームではセキュリティの仮定は常に表面を超えてテストされるべきであることを思い出させるものです。
翻訳元: https://gbhackers.com/amazon-q-security-flaw-allowed-restricted-users/