AWS Quick AI Chat Bypass Highlights Gaps in Cloud Authorization and Data‑Protection Obligations

What happened

On 12 May 2026 security firm Fog Security reported a critical authorization bypass in Amazon Quick (formerly QuickSight). The service provides an AI‑driven chat assistant that can answer questions using a customer’s own data stored in AWS. Administrators can configure custom permissions to deny the chat agent access for specific users or groups. Fog demonstrated that, while the console correctly hid the option, the underlying API ignored the custom‑permission setting. A non‑admin user with valid SSO credentials could send a request to the chat endpoint and receive a response that included the customer’s proprietary data.

AWS fixed the missing server‑side check between 11 March and 12 March 2026 – eight days after the bug was reported through HackerOne – and classified the severity as “none.” No public advisory was issued, and the company’s initial statement claimed that “no customer data was at risk.”

Legal basis for scrutiny

GDPR (EU)

• Article 32 – Security of processing requires controllers and processors to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. A missing server‑side authorization check that allows an authenticated user to access data they are not entitled to is a direct breach of this obligation.
• Article 33 – Notification of personal data breach obliges a data controller to notify the supervisory authority within 72 hours of becoming aware of a breach that is likely to result in a risk to the rights and freedoms of natural persons. If the chat agent can expose personal data (e.g., employee names, client identifiers), the incident would trigger a notification requirement, regardless of whether the specific customer had enabled the custom‑permission feature.
• Article 5(1)(b) – Purpose limitation and (c) – Data minimisation also come into play. Allowing unrestricted AI queries defeats the purpose‑limitation principle if the service can retrieve data beyond what the user’s role permits.

CCPA (California)

• Section 1798.150 – Security of personal information mandates reasonable security measures. An exploitable bypass of a built‑in access control could be deemed unreasonable, especially for services marketed as “grounded in your real business data.”
• Section 1798.82(b) – Business‑to‑business breach notification requires a service provider to notify a business customer “in the event of a breach of the security of the system.” The lack of any customer‑facing notification may conflict with this provision.

Sector‑specific rules (e.g., FINRA, HIPAA)

Financial institutions and healthcare organisations that use Quick for confidential data are subject to additional safeguards. A breach that permits unauthorised access to protected health information (PHI) or regulated financial records could constitute a violation of HIPAA Security Rule or FINRA Rule 3110, exposing both the cloud provider and the customer to enforcement actions.

Impact on users and companies

Affected party	Potential consequence
End‑users (employees, contractors)	Exposure of internal knowledge, trade secrets, or personal data through AI responses.
Enterprises (especially regulated ones)	Non‑compliance with GDPR/CCPA could lead to fines up to €20 million or 4 % of global turnover (GDPR) and up to $7 500 per consumer per incident (CCPA).
AWS	Reputation damage, possible regulator‑initiated audits, and the risk of being named in enforcement actions if the breach is deemed a data‑protection failure.
Third‑party developers	Reliance on Quick’s API for custom applications may inherit the same security gap, propagating risk downstream.

What changes are needed

1. Transparent breach communication – Under GDPR Art. 33 and CCPA § 1798.82, AWS should have issued a formal advisory to all Quick customers, even if the feature was rarely used. A “severity: none” rating does not exempt the provider from notification duties when personal data is at stake.
2. Server‑side enforcement of all access controls – The custom‑permission setting must be validated both in the UI and on every API call. Relying on client‑side hiding is insufficient under any data‑protection regime.
3. Audit logs and telemetry – AWS should expose detailed logs showing which accounts configured custom permissions and whether any unauthorized calls were made. This would help customers demonstrate compliance with GDPR Art. 30 (records of processing activities).
4. Independent certification – Obtaining ISO/IEC 27001 or SOC 2 Type II attestation that includes AI‑driven services can reassure regulators that systematic testing of authorisation logic is performed.
5. Policy guidance for regulated sectors – AWS should publish sector‑specific best‑practice guides (e.g., “Using Quick in a GDPR‑compliant manner”) that explain how to combine IAM policies, Service Control Policies (SCPs), and custom permissions to achieve defence‑in‑depth.
6. Bug‑severity taxonomy revision – Classifying a bypass of the only access‑control mechanism as “none” misrepresents the risk. A more granular severity scale that reflects regulatory impact would improve stakeholder trust.

Bottom line for digital‑rights advocates

The Quick bypass is a textbook example of how a cloud provider can unintentionally expose customer data while claiming the risk is negligible because “no one used the feature.” Data‑protection law does not accept that defence. Whether or not a customer actively configured a control, the provider is still obligated to secure the service and to inform customers when a breach of that security occurs. Organizations that rely on AI‑enhanced analytics should audit their Quick deployments, verify that custom permissions are enforced server‑side, and request detailed breach notifications from AWS.

---

For further reading on cloud‑security obligations under GDPR, see the European Data Protection Board’s guidelines on “Security of personal data processing” (EDPB 2023/01).