We discovered an authorization bypass in Amazon Quick’s AI Chat Agents that allows users to access and interact with AI agents despite explicit administrative restrictions. AWS responded by deploying a fix without notifying customers, classified the issue as “none,” and did not publish an advisory.
Finding
We identified missing server-side authorization checks in the Chat Agent API, resulting in unauthorized access to AI Chat Agents. We were able to chat with the AI Chat Agent, despite access only being restricted in the UI. By issuing direct API requests to the Chat Agent endpoints, we were able to bypass these restrictions and successfully interact with the agent.
This is analogous to AWS asserting that a door is locked when, in reality, it is merely closed and not locked.
Despite explicit administrative configuration denying access via custom permissions, the backend accepted these requests and returned successful responses. This demonstrates an absence of server-side authorization enforcement for this functionality and is a classic case of missing server-side authorization (CWE-862). We observed no cross-tenant access; impact is limited to bypassing intra-account administrative controls.
This access required no additional user action. AWS automatically provisions a default chat agent upon service activation, expanding the attack surface even when administrators intend to disable AI functionality. As a result, administrators could not reliably enforce restrictions on AI agent usage. Although limited to intra-account scope, it bypasses explicit administrative controls that are relied upon for access management and policy enforcement.
Timeline
- March 4th, 2026: Fog Security reported vulnerability to AWS via AWS’s VDP on HackerOne.
- March 11th, 2026: AWS deployed a fix to initial production regions.
- March 12th, 2026: AWS deployed fix to all production regions.
To our knowledge, AWS did not send customer communications nor make any public announcements.
Impact
Amazon Quick (formerly Amazon QuickSight, later rebranded as Quick Suite), AWS’s business intelligence service, has integrations with AI Chat Agents. Amazon Quick is often deployed as an enterprise SaaS platform, where administrators configure access for broad groups of business users. Organizations may choose to restrict or disable AI capabilities. Organizations may want to prevent unapproved (shadow) AI usage or to disable AI functionality within Quick entirely.
AWS classified the issue as ‘none,’ which differs from our assessment given that the issue bypassed explicit administrative controls relied upon for access enforcement. From AWS’s own criteria for public communication, we see a gap between AWS’s published scope and their actual communication of security issues.
Background
Amazon Quick
Amazon Quick is AWS’s Business Intelligence Service that has been rebranded (formerly Amazon QuickSight, later Quick Suite) with an AI focus. On https://aws.amazon.com/quick/, Quick is described as “an AI assistant for work that brings it all together - connecting Slack, Microsoft Teams and Outlook, CRMs, databases, and documents in one place. It learns what matters to you and your team, grounds every answer in your real business data, and goes beyond answers: scheduling, building deliverables, creating dashboards, and acting on your behalf. One person's insight becomes the whole team's advantage.”
Quick has multiple integrations with AI including access to create AI Agents to chat with that can interact with data within Quick. By default, AWS creates a system-provided chat agent in Quick.
Access Management in Amazon Quick
Access in AWS is typically governed by AWS Identity and Access Management, a policy language.
Not all services and features in AWS are governed by AWS IAM. There are exceptions such as S3 via ACLs (a legacy authorization mechanism) and Amazon Quick.
Currently, the only way to restrict granular access to capabilities within Quick is to use “custom permissions”. AWS IAM policies, SCPs, and RCPs do not govern access to Quick’s AI Chat Agent functionality; only custom permission profiles can restrict it. Thus, explicit denies via AWS IAM Policies or organization-level policies in Service Control Policies (SCPs) cannot restrict access to AI Agents in Quick.
Walkthrough
To create the Quick environment, we applied Custom Permissions to deny access and restrict all Chat Agent-related features. We applied this to the entire Quick account so it applies to all users within the Quick account.
Then, we logged into a non-administrator user within the same Quick account and sent an HTTP chat request and were able to get a response. In this case, we used an innocent chat request without data: “Tell me about mangoes.” This should not have been possible and should have resulted in an Access Denied or Unauthorized since we’ve explicitly blocked all interactions and usage with AI chat agents.
Now that AWS has fixed this authorization issue, here’s what the same command looks like now. As we can see, there’s now a “401 unauthorized” response from the server.
For a detailed technical walkthrough, see the disclosed finding on HackerOne: https://hackerone.com/reports/3577145
Conclusion
The chat agent authorization bypass is caused by missing server-side authorization for AI Chat Agent functionality in Amazon Quick. While limited to intra-account scope, it allows users to bypass explicit administrative deny controls configured via custom permissions, which are relied upon for access management and compliance enforcement. Such controls are expected to be consistently enforced across UI and API access paths.
This issue highlights the importance of maintaining strong security controls in rapidly evolving AI-integrated services, where there may be pressure to deliver new functionality quickly.
AWS classified this issue as “none,” and did not provide customer notification or publish a public advisory.
Contact
To discuss our research or to continue the conversation about AI and cloud security, reach out to us at info@fogsecurity.io.
Edit: After we published this blog and disclosed the report on HackerOne, AWS provided the statement below:
