Does Amazon Q respect source permissions?

Yes, through connectors that capture source ACLs and apply them at query time, and this works as documented. The qualification is temporal rather than functional. Permissions applied to a query are the ones captured at the last connector sync, so a revocation at the source takes effect in Q only after the next sync completes. Measure that interval in your own deployment by revoking access and timing how long Q keeps answering. Treat the result as a documented control gap with a known duration rather than assuming the propagation is immediate.

Is the Q index in scope for our data retention policy?

Treat it as in scope. The index holds copies of content drawn from systems that each have their own retention schedules, and those schedules do not automatically govern the copy. A document deleted at the source under a retention rule persists in the index until a sync removes it, which means a deletion obligation is met in one place and unmet in another. Map connector sync behaviour against each source system's retention rules and document the divergence, because the first time this surfaces should not be during a deletion request.

How is aggregation risk different from ordinary over-permissioning?

The permissions are identical; the exploitation cost collapsed. A user with read access across forty repositories always had the ability to synthesize across them, and the labour involved meant almost nobody did. An assistant performs that synthesis on request, which converts dormant over-permissioning into an active capability. The right response is an access review calibrated to the new cost rather than a control on the assistant, since the assistant is doing exactly what it was deployed to do with entitlements the organization granted.

Can we put an inline control in front of managed Q Business?

No, and any vendor saying otherwise should be asked to draw the path. In the managed service, retrieval and inference happen inside AWS, and the organization's touchpoints are connector configuration, source-side classification and the audit data AWS exposes. The enforcement options are therefore upstream: control what is eligible for indexing, scope connectors tightly, classify content before it enters a connected source, and keep the ACL sync interval short. Inline request-layer enforcement applies to Q Developer under proxied routing and to custom applications built on the APIs.

What should we test in the first week of a Q deployment?

Four things, in roughly this order. Measure the ACL propagation delay by revoking access and timing the answers. Enumerate every connected source and review the union of what a single user can reach through them. Run a set of adversarial questions designed to surface content across repository boundaries, phrased the way a curious employee would phrase them. And confirm what the available audit data lets you reconstruct about which sources contributed to a given answer. Each produces a documented number rather than an assumption.

How does this fit with the rest of our AI surface?

Q is one endpoint among several in most organizations, alongside direct provider calls, an IDE assistant, embedded AI features in SaaS tools and whatever the data science team is running. A policy that exists only in the Q console governs the Q slice. The value of a single enforcement boundary is that the same classification rules and the same audit format apply across every surface you can reach, so the answer to what left the organization does not depend on which console someone remembers to check. The general practice is covered in AI DLP.

Amazon Q DLP: The Index, the ACL Window, and What an Enforcement Layer Can Reach

Amazon Q Business connects to enterprise data sources, builds an index over their content, and answers questions with the acting user's permissions applied to what it retrieves. The permission model is the feature AWS leads with, and it does most of what it claims.

Two data-protection problems survive it. The index is a second copy of the organization's content, held in a different place under different controls than the systems it was copied from. And the permissions applied to a query are the permissions captured at the last sync, which is a different thing from the permissions in force right now.

I want to walk through both, then separate the Amazon Q surfaces an enforcement layer can reach from the ones it cannot, because the honest answer differs by surface.

The index is a second copy

A connector to SharePoint, S3, Confluence, Salesforce or a shared drive reads content and writes it into an index that Q queries at answer time. The retrieval quality depends on that index being reasonably complete.

Completeness has a governance consequence. Content that lived in one repository with one owner, one retention schedule and one set of access reviews now also lives in an index with a different owner, a different retention behaviour and a different review cadence. A document deleted from the source stays in the index until the next sync removes it. A repository excluded from the corporate DLP scan because it was considered low-risk contributes its contents to an index that answers questions across the whole estate.

The inventory question follows directly. Which sources are connected, what does each contribute, and has anyone reviewed the union rather than the individual items. That union is what a single well-phrased question can traverse.

The ACL sync window

Q's connectors capture source permissions and apply them at query time so a user cannot retrieve content they lack access to. The mechanism works as described, and the gap it leaves is one of timing.

Permissions change at the source continuously. Someone leaves a team and loses access to a SharePoint site. A project folder is locked down after a reorganization. An access review revokes a stale grant. Those changes reach the index at the next connector sync, and the interval between them is a window in which the index answers using permissions that the source no longer honours.

The stale-ACL window is the failure mode I would test first in any Q Business deployment, ahead of anything about content classification. Revoke a user's access to a specific document at the source, then immediately ask Q a question that document uniquely answers, and record how long the answer keeps coming back. That number is a control gap measured in hours, and most teams have never measured it.

Evidence for the test includes the revocation timestamp, the query timestamps, the first query that returned no result, and the connector's configured sync schedule.

Aggregation, which permissions do not address

A user with legitimate access to forty documents can read all forty, and always could. What changes is the effort.

Before, extracting the pattern across forty documents required someone to sit down and do it, and that friction was doing quiet security work nobody had written down. Now a single question synthesizes across the set in seconds. The organization's actual exposure to an insider with broad read access shifts from theoretical to operational, without a single permission changing.

This is the argument to bring to an access review rather than to a product evaluation. Entitlements that were tolerable when the cost of exploiting them was a week of manual reading deserve a second look when the cost is one prompt. Access breadth is now a first-order risk parameter, and the review cadence most organizations run was calibrated for the old cost.

Which surfaces an enforcement layer can reach

This is where the honest split matters, and it mirrors the situation with other managed assistant products covered in Copilot DLP.

For Q Business in its managed form, the retrieval and the model call both happen inside AWS. The deploying organization configures connectors and reads audit data, and cannot place an inline control between Q's retrieval layer and the model behind it. Claiming a gateway intercepts that path would be false. The controls that apply are the ones on the input side: which sources are connected, what each connector is scoped to include and exclude, whether content is classified before it is eligible for indexing, and how quickly ACL changes propagate.

For Q Developer in the IDE, the traffic leaves a developer's machine over HTTPS, and in deployment configurations that support proxied routing that path is reachable. Source code context, including whatever sits in adjacent files, is what moves there.

For custom plugins and applications built against Q's APIs, the organization controls the request path, so classification and per-request authorization apply normally, and the per-decision record is produced by infrastructure the organization owns.

Sorting your Q footprint into those three buckets before evaluating any tooling is the step that prevents buying a control for a surface it cannot see.

What to classify where you can

For the reachable surfaces, the classes follow existing policy applied at prompt granularity: customer PII, PHI for healthcare, NPI and pre-announcement material for financial services, CUI for federal contractors, source code with IP indicators, credentials embedded in configuration files that a developer assistant happens to read.

The credential case is the concrete one for Q Developer. An IDE assistant assembling context from the working directory will include a .env file or a configuration block if it is open or adjacent, and the developer never typed any of it. Classification at the request boundary catches content the human never consciously submitted, which is the category endpoint DLP was never positioned to see. The broader practice is covered in prompt-level DLP.

The record

For the reachable surfaces, a per-decision record carrying the originating identity, the classification of the content, the policy applied, the decision, the destination and the timestamp is produced by infrastructure you control, which is what makes it usable when someone asks what left.

For the managed Q Business surface, the record you have is the audit data AWS provides, on AWS's schedule and in AWS's format. That is a real artifact and it is worth wiring into your SIEM. Understand what it does and does not contain before an incident makes the question urgent, and specifically whether it lets you reconstruct which documents contributed to a given answer.

DeepInspect

This is the gap DeepInspect closes on the reachable half. DeepInspect sits at the AI request boundary as a stateless proxy between authenticated users or agents and the model endpoints they call. For proxied Q Developer routing, for custom applications built on Q's APIs, and for the other model endpoints in the same estate, prompt content is classified, each request is evaluated against the identity that originated it, and a signed per-decision record is written under your control.

The boundary claim is deliberately limited. For managed Q Business, the retrieval and inference path runs inside AWS and DeepInspect does not intercept it. What DeepInspect covers is the AI traffic that crosses a boundary you own, which for most organizations running Q is a majority of their total AI surface once the direct provider calls, the self-hosted models and the custom applications are counted.

If your Q footprint has never been sorted into what you can enforce on and what you cannot, that sort is the first step. Book a demo today.