AWS Patched Authorization Bypass in Amazon Quick AI Chat Agent, Says No Customer Data at Risk
AWS fixed an authorization bypass in Amazon Quick that let denied users query the AI Chat Agent via API, but classified the severity as 'none' and issued no advisory, sparking criticism over its response.
AWS has patched an authorization bypass vulnerability in Amazon Quick (formerly QuickSight) that allowed users explicitly denied access via custom permissions to still query the AI Chat Agent through the API. The flaw was disclosed by Fog Security on March 3, 2026, and AWS deployed a fix by March 12, but classified the severity as "none" and issued no customer advisory or public notification. The company's initial response stated that "no customer data was at risk," a claim that has drawn sharp scrutiny given the product's own description of the chat agent as an AI assistant that "grounds every answer in your real business data."
Fog Security reported that when an Amazon Quick administrator uses "custom permissions" to explicitly deny access to AI Chat Agents, the UI correctly hides the feature. However, the API continued to respond to chat requests for any authenticated user in the account who knew how to send them. Fog's proof-of-concept involved a non-admin user asking the agent "Tell me about mangoes" from a session that was, on paper, locked out of the agent entirely. The agent responded without restriction.
Amazon Quick is described on its own product page as an AI assistant that "connects Slack, Microsoft Teams and Outlook, CRMs, databases, and documents in one place" and "grounds every answer in your real business data." The default chat agent is automatically provisioned when Quick is enabled, whether the customer wants those AI features or not. The bypass could have exposed sensitive business data from connected sources to unauthorized users, including contractors or employees in restricted business units.
After the story circulated, AWS offered a follow-up comment stating: "The researcher was using the Admin Control capability that no customers were actively using when the server side validation was not present." This defense essentially argues that the access control mechanism was broken, but no customer had configured it during the exposure window. Critics have compared this to saying "the lock on the front door didn't work, but nobody had locked it anyway."
Fog Security disclosed the flaw via HackerOne on March 3, and AWS deployed the fix between March 11 and March 12. The company classified the severity as "none," issued no customer notification, and published no advisory. Fog Security published a blog post detailing the issue on May 12, prompting AWS's initial statement.
The incident raises broader questions about AWS's vulnerability disclosure practices and its definition of "customer data at risk." If the chat agent does not actually have access to the data the product page claims, then the marketing is misleading. If it does, then unauthorized users could query an agent wired into customer data, making "customer data was at risk" the accurate description. The company's response has been criticized as dismissive, particularly for a service that is increasingly positioned as a central AI interface for business intelligence.