![\"Amazon](\"https:\/\/www.europesays.com\/ai\/wp-content\/uploads\/2026\/05\/amazon_quick-650.webp\" "\\"Amazon")
<\/p>\nEnterprises running Amazon Quick, the AWS business intelligence and agentic AI service, rely on a feature called custom permissions to restrict who inside an account can use AI chat agents. Fog Security founder Jason Kao discovered that those restrictions were enforced only in the user interface for a period earlier this year, and direct calls to the backend API returned successful chat responses from agents that administrators had explicitly disabled.<\/p>\n
<\/p>\n
A locked door that was only closed<\/p>\n
Fog Security identified<\/a> missing server-side authorization checks in the Chat Agent API of Amazon Quick. The firm configured custom permissions to deny all Chat Agent capabilities across an entire Quick account, then signed in as a non-administrator user and issued a direct HTTP request to the chat endpoint with the prompt \u201cTell me about mangoes.\u201d The agent returned a normal response. The flaw maps to CWE-862, missing server-side authorization.<\/p>\n The impact stayed within a single AWS account. The researcher observed no cross-tenant access. The bypass did defeat the intra-account administrative controls that organizations depend on to block shadow AI<\/a> usage or to switch off AI features in Quick entirely. Because AWS automatically provisions a default system chat agent when the service is activated, the agent exists and is reachable from the moment Quick is turned on, even in accounts where administrators want AI functionality disabled.<\/p>\n Custom permissions carry the entire weight of Quick access control<\/p>\n Access to features inside Quick sits outside the reach of AWS Identity and Access Management policies, Service Control Policies, and Resource Control Policies. Custom permission profiles are the only mechanism that can restrict granular Quick capabilities such as Chat Agents, Analyses, Dashboards, Knowledge Base, and Research. An explicit deny written in an IAM policy or an SCP does nothing for Chat Agent access. Administrators who want to block the feature have one lever to pull, and during the affected window that lever held in the UI yet released at the API.<\/p>\n Timeline and AWS response<\/p>\n Fog Security reported the issue to AWS on March 4, 2026, through the AWS vulnerability disclosure program on HackerOne. AWS deployed a fix to initial production regions on March 11 and completed the rollout to all production regions on March 12. After the fix, the same direct request returns an HTTP 401 with an \u201cAGENT_ACCESS_DENIED\u201d error code.<\/p>\n AWS classified the severity of the issue as \u201cnone,\u201d sent no customer communication, and published no security advisory. Fog Security disputes that rating, pointing to the gap between AWS\u2019s published criteria for public communication and what customers were told about this case.<\/p>\n \u201cWe believe that AWS should have notified customers about the missing server-side authorization for using AI Chat agents since administrators could not reliably enforce restrictions on AI agent usage,\u201d Kao told Help Net Security. \u201cEven though this was limited to intra-account scope, the missing authorization still bypasses explicit administrative controls that are relied upon for access management and policy enforcement. We see this as analogous to AWS asserting that a door is locked when, in reality, it is merely closed and not locked.\u201d<\/p>\n The detailed technical write-up is posted on HackerOne as report 3577145<\/a>.<\/p>\n Where this leaves compliance teams relying on Quick controls<\/p>\n Administrators who set custom permissions in Quick before mid-March 2026 should reach out to AWS to understand the impact on their audit requirements, particularly if they require demonstrable enforcement of AI usage<\/a> restrictions. AI features in cloud services can ship fast, and security including authorization logic, must be robust so that customers can trust their AI usage is secure.<\/p>\n \u201cFrom a customer perspective, cloud providers should take ownership, be transparent, and proactively notify customers when security controls do not function as intended,\u201d Kao said.<\/p>\n![](\"https:\/\/www.europesays.com\/ai\/wp-content\/uploads\/2026\/04\/divider.gif\")
<\/p>\n