Most users put up with AWS the way you put up with the DMV. The interface feels stuck in a time machine that never got new parts. Pricing pages look like they were built by someone who actively resents your existence. Yet everyone tolerates this because AWS historically nailed the boring, critical stuff: the security model, the IAM language nobody enjoys but everyone trusts, the crisp boundary between one account and the next. Break that trust, and the whole deal unravels. Because it sure isn’t the obvious one.
The Authorization Bypass in Amazon Quick
Amazon Quick is the business intelligence service that began life as QuickSight, then became Quick Suite, then apparently just Quick (though the name might shift again next week). Fog Security discovered that when an administrator — a role the researcher called “an absolutely devastating personal insult” — uses custom permissions to explicitly deny access to AI Chat Agents, the user interface hides the feature accordingly. That sounds good. That sounds like security working as intended.
Except the API did not get the memo. The backend continued answering chat requests from any user in the account who knew how to craft and send them. You could be a low-privileged user, locked out of the agent on paper, and still fire an HTTP request directly to the chat endpoint and receive a full response. The aws quick auth bypass meant that an admin’s explicit denial in the UI was essentially theater — the real gate was gone.
The Mango Test
Fog’s proof-of-concept was deliberately harmless. A non-admin user, in a session that should have been blocked from the AI Chat Agent, asked the agent to “tell me about mangoes.” The agent happily obliged. That is the clean disclosure a security firm provides: show the bypass, prove the risk, don’t cause damage. A malicious insider would not have asked about mangoes.
How the Flaw Worked
Amazon Quick connects to a broad ecosystem: Slack, Microsoft Teams, Outlook, CRMs, databases, and documents. Its product page describes it as an AI assistant that “grounds every answer in your real business data.” The default chat agent is provisioned automatically the moment you enable Quick — whether you want the AI features or not. That agent is the front door to your data.
Administrators can set custom permissions to deny certain users access to that front door. Until March of this year, that denial only affected the UI layer. The API endpoint remained open. Anyone who knew the endpoint URL and had valid session credentials could send requests and receive answers grounded in the organization’s actual data. It was a server-side authorization gap: the permission check existed in the client but not on the backend.
The Rights Nobody Asked For
Consider a regulated bank. Compliance rules may forbid contractors or certain business units from using AI tools on internal data. The IT admin configures custom permissions, denies the AI Chat Agent to those groups, and considers the problem solved. Until March 11, every single one of those denied users could bypass the restriction with a simple API call. They did not need to know about the bypass — all they needed was a reason to ask the agent a question that the agent would answer using the bank’s real data.
The Response from AWS
Fog reported the aws quick auth bypass via HackerOne. AWS deployed a fix between March 11 and March 12 — eight days after the disclosure. For a company of AWS’s scale, that is superhero speed. Full credit where due. But then came the classification and communication.
AWS assigned the issue a severity of “none.” It issued no customer notification. It published no security advisory. When Fog disclosed publicly, AWS provided a statement: “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.”
That sentence does an enormous amount of work with the phrase “no customer data was at risk.” Let’s examine what it actually means.
What “No Customer Data” Means in Practice
Amazon Quick’s own documentation says the AI agent is the front end for your business data. It connects to databases, CRMs, and documents. It grounds every answer in that data. A user making an unauthorized request could potentially pull answers derived from that data. Fog asked about mangoes, so the response was about mangoes — no customer data leaked there. But what if the malicious insider asked “What is the quarterly revenue forecast for the Healthcare division?” or “List all customer records that include a Social Security number”?
The agent would answer. The answer would be derived from customer data. That data would leave its authorized context. How is that not “customer data at risk”?
Why ‘No Customer Data at Risk’ Is Hard to Swallow
The uncomfortable gap lies between two possibilities. Either the chat agent does not actually have access to the data the product page claims it does — meaning the marketing overstates the feature — or unauthorized users could query an agent wired into customer data, meaning the data was indeed at risk. AWS’s statement suggests it was neither, but the explanation is not fully reassuring.
Follow-up comments from AWS clarify that “the researcher was using the Admin Control capability that no customers were actively using when the server side validation was not present.” Read that sentence twice. It implies that the specific combination of custom permissions and API bypass had no real-world customers in the window between the vulnerability’s existence and its fix. Even if true, that is a remarkable coincidence, and it leaves open the question: what about the next similar bypass?
You may also enjoy reading: Europe First to Authorize Moderna Combo mRNA Vaccine.
The Mismeasured Severity
AWS classified the severity as “none.” Yet the bypass allowed any authenticated user to circumvent an explicit administrative restriction and query an AI agent that answers from real business data. If the agent has any access to customer data — which the product page states it does — then the bypass exposes that data to unauthorized querying. Calling that “none” sets a precedent that could discourage proper disclosure and customer awareness.
What the Fix Means for AWS Customers
The server-side validation patch was deployed in March. AWS says no customer action is required. For most organizations, that is likely true — the fix is applied, and the aws quick auth bypass is closed. However, the incident serves as a valuable lesson in defense in depth.
If you are an AWS administrator using Quick, consider taking these steps to ensure your permissions work at all layers:
- Verify custom permissions programmatically: Do not rely solely on the UI. Use the AWS CLI or SDK to call the API and confirm that denied users truly cannot access chat endpoints.
- Monitor API logs: Enable CloudTrail logging for Quick and review for any requests to chat agent endpoints from users who should not have access. Look for unusual patterns — a contractor asking about revenue forecasts, a low-privilege user querying document summaries.
- Implement additional controls: Consider network-level restrictions such as VPC endpoints or service control policies that limit which accounts can interact with the chat agent. This adds a second layer of protection.
- Review your data grounding: Understand exactly what data sources your Quick chat agent can access. If it connects to a database containing sensitive information, restrict that at the source — don’t rely solely on user permissions within Quick.
The Broader Implications for Cloud Security
This incident highlights a tension between speed of fix and transparency. AWS patched in eight days — impressive. But the lack of a public advisory and the “no severity” classification mean that customers who rely on custom permissions to meet compliance requirements had no way to know their control was partially broken for months. Regulatory frameworks like SOC 2 or PCI-DSS often require organizations to review all security advisories. If no advisory exists, that review never happens.
The aws quick auth bypass also raises questions about how cloud providers define “customer data risk.” To a security professional, any scenario where an unauthorized user can send requests to a system that returns information derived from customer data is a data risk — even if the researcher’s demo question was about mangoes. A clear, conservative definition would benefit everyone.
What You Can Do as a Customer
You cannot control how AWS classifies vulnerabilities, but you can control how you respond to them. Adopt a practice of regularly testing your own permissions boundaries. Use tools like the IAM Access Analyzer or third-party cloud security platforms to detect authorization gaps. Engage with AWS Support about any ambiguity in their security notifications — ask direct questions: “Does this patch affect my organization? Was data ever potentially exposed in my account?”
Where AWS Goes from Here
AWS’s follow-up comment attempts to minimize the impact by stating that no customers were actively using the specific admin control that had the bypass. That is difficult to verify independently, and it does not address the principle: a bypass existed, it was not obvious, and it took an external researcher to find it. Cloud customers need reassurance that the security model they trust is actually enforced at every layer.
The good news is that the fix is in place, and AWS’s engineering response was rapid. The less comforting news is that the communication process — no advisory, no severity, a vague public statement — leaves customers wondering what else might be hidden. The next time someone finds an aws quick auth bypass that is actually being exploited, the silence could have real consequences.
For now, the mangoes are safe. And so, apparently, is your data — depending on who you ask.
