"We appreciate Fog Security's coordinated disclosure. This issue was addressed in March 2026. No customer data was at risk and there is no customer action required." — AWS, in a statement provided to Fog Security
What Fog Security reported on May 12
Fog Security publicly disclosed an authorization bypass in Amazon Quick on May 12. Their proof-of-concept showed a non-admin user issuing a simple prompt — "Tell me about mangoes" — from a session that, according to the service's admin configuration, had been explicitly denied chat agent access. Despite the UI hiding the feature for that user, the Quick API returned an agent response.
Fog reported the issue to AWS via HackerOne; AWS deployed a fix between March 11 and March 12, which the Register story notes occurred eight days after the original HackerOne report.
How Amazon Quick is described and why the bypass matters
Amazon Quick is described on its 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 Register account emphasizes that the default chat agent is automatically provisioned the instant Quick is enabled, making the chat front end the primary mechanism for interacting with a customer's business data.
Fog's finding matters because the chat agent is the intended path to that data. If authenticated users who an administrator thought were denied access could nevertheless call the agent endpoint, those users would, in the worst-case scenario described in the reporting, be able to receive responses grounded in internal data despite admin controls appearing to deny them.
AWS's response: fix deployed, severity rated "none," and a narrow defense
AWS told Fog Security that the bug had been fixed in March and asserted "no customer data was at risk" and "there is no customer action required." The Register details that AWS initially rated the severity as "none," issued no customer notification, and published no advisory.
In a subsequent comment the Register characterizes as more candid, an AWS spokesperson said: "The researcher was using the Admin Control capability that no customers were actively using when the server side validation was not present." The Register paraphrases that AWS thereby acknowledged the missing server-side authorization check while also asserting telemetry that, during the exposure window, customers were not using the specific custom-permissions control that would have been bypassed.
Access model specifics: custom permissions as the lone control
The Register reports that Amazon Quick's AI Chat Agent is governed outside of standard AWS mechanisms: "IAM policies don't govern Quick's AI Chat Agent, SCPs don't apply, and RCPs don't apply." According to the piece, custom permissions are the only control the service provides for denying agent access to specific users. Fog's exploit relied on that single knob being present in the UI but not enforced at the API layer.
The Register highlights a consequential telemetry claim from AWS: not only was the server-side check absent, AWS says no customers had configured the custom-permissions control during the vulnerable window. The publication treats that claim as both a defense and as an indictment of uptake for Quick's access-management model: the service documents a specific mechanism, yet according to AWS it had "zero recorded uptake" while the check was missing.
What this means for technologists, procurement leaders, and regulators
- Technologists and security teams: will note that Quick's chat agent sits outside IAM, SCP, and RCP controls and that custom permissions were the only access-control mechanism — a single missing server-side check enabled an intra-account bypass.
- Procurement and compliance leaders at firms using Quick: must weigh the product page claims that the agent "grounds every answer in your real business data" against the Register's reporting that an admin-configured denial could be circumvented via the API until March.
- Regulators and auditors: may focus on the combination of the patch timeline (fix in March after a HackerOne report) and AWS's choice not to notify customers publicly, despite a severity label of "none."
The Register frames the exchange as a compact microscope on two linked problems: a missing server-side authorization check in an AI-adjacent product, and a communications posture that treats the lack of customer uptake for a control as an exculpatory fact. AWS fixed the code; it also offered a telemetry-backed explanation that no customers had used the control while it was ineffective. The record left on the table by the reporting is crisp: an acknowledged authorization gap, a public patch in March, and a disputed claim that "no customer data was at risk" predicated on customers having not enabled the very control the service documents.
