Amazon Q Compliance After the Closure to New Customers

The Amazon Q Business security documentation now opens with a banner rather than a control statement: Amazon Q Business is no longer open to new customers, and AWS directs organisations seeking similar capabilities to Amazon Quick. For anyone already running it inside a regulated environment, that notice belongs in the risk register before any of the security topics below it get reviewed.

A service closed to new customers is still a supported service. It is also a dependency with a changed trajectory, and compliance files are supposed to record that.

TL;DR

• AWS has closed Amazon Q Business to new customers and points prospective users toward Amazon Quick, which makes service lifecycle a named risk for existing deployments.
• The shared responsibility model applies unchanged: AWS secures the infrastructure, and the customer owns data sensitivity, internal requirements, and applicable law.
• Identity flows through IAM Identity Center, and Q Business inherits access control lists from connected data sources, so answer scope follows source permissions.
• AWS publishes ACL Analyzer for reviewing effective access, which produces a reviewable artefact rather than an assumption.
• Neither IAM nor CloudTrail evaluates whether the content of a particular prompt was permitted to reach a model.

The lifecycle notice is a compliance fact

AWS states the change plainly on the security page and links to a dedicated availability-change document. For an existing customer, three things follow.

The vendor risk file needs a dated entry recording the closure and the named successor path. A supervisory question about continuity is now foreseeable, and "we were not aware" is a poor answer to give twice.

Renewal and dependency planning needs an owner and a review date. Nothing in the notice says the service is being withdrawn from existing customers, and nothing in it promises feature parity with a successor either. Record what AWS actually said, with the link, and avoid inferring either outcome.

Third, any control description referencing roadmap features should be re-read. Controls that depend on a capability arriving later are weaker than they look when the product has stopped taking new customers.

Shared responsibility, stated exactly

The documentation sets out the standard split, which follows the AWS shared responsibility model. Security of the cloud is AWS protecting the infrastructure running its services, verified by third-party auditors under the AWS compliance programs. Security in the cloud is the customer's responsibility, determined by the service used, the sensitivity of the data, the organisation's requirements, and applicable laws and regulations.

The security section then breaks into the topics that carry the customer's actual work: data protection, VPC interface endpoints through AWS PrivateLink, identity and access management, compliance validation, ACL Analyzer, resilience, infrastructure security, cross-service confused deputy prevention, and security best practices.

Compliance validation follows the same pattern as the rest of AWS. Scope by program lives on the services-in-scope page, audit reports download through AWS Artifact, and responsibility for the deployment stays with the customer. That is due diligence at the procurement boundary, and due care is the continuing obligation that produces sampled transactions and dated tests.

ACL propagation is the control most reviews get wrong

Q Business answers from connected data sources, and it inherits the access control lists attached to those sources. Two employees asking an identical question receive different answers because their underlying permissions differ. That behaviour is a feature, and it is also the reason a permissions error in a connected repository becomes an AI disclosure.

AWS ships ACL Analyzer for exactly this review. Using it produces an artefact with a date and an owner, which is materially better evidence than a paragraph asserting that permissions are inherited correctly.

A sampled test is stronger still. Pick a restricted document in one connected source, run the same query as two controlled users with different entitlements, and retain both responses with the source attributions. Then change one entitlement and repeat. Our Amazon Q security material covers the control configuration, and the audit log piece covers where the retrieval record lands.

What the logs answer and what they leave open

CloudTrail records API activity for the service, which supports an access review and an administrative change history. That is the record of what the platform was asked to do.

It is not a per-request policy record. A log entry describes an action that already completed, which makes it forensic rather than preventive, and at the speed automated attacks now move the gap between those two is the whole argument in why AI security must be inline.

The question no AWS-side setting answers is whether the content of a specific prompt, sent by a specific authenticated identity, was permitted to reach a model at that moment. Identity Center establishes who is asking. Source ACLs establish what they may retrieve. The classification of what they typed into the box is evaluated by neither.

The evidence package for one sampled request

Start with the originating identity from IAM Identity Center and the timestamp. Add the connected sources in scope, the effective ACL result, and the source attributions returned in the answer. Preserve the administrative configuration snapshot for that date, the approved use case, and the processor record.

Add one denied test. Send a controlled payload whose classification is prohibited for the deployment and retain the refusal. Repeat after a permission change and after a connector scope change. A screenshot of a settings page proves a setting existed, and a denied test with a timestamp proves a control operated.

The AI vendor risk assessment template covers the procurement side of this file, including the lifecycle entry the closure notice now requires.

DeepInspect

DeepInspect provides an independent policy decision at the HTTP AI request boundary. For model traffic deliberately routed through it, DeepInspect evaluates the application-supplied identity and role against organisational policy for the content classification and model authorisation before the request reaches the model.

Each decision produces a signed, tamper-evident record held outside the calling application's write path. For an organisation running a service now closed to new customers, that record also survives a platform migration, because it lives in the enforcement layer rather than inside the product being replaced.

Book a technical deep dive at deepinspect.ai.