Amazon Q Business answers employee questions from indexed company data, so its security rests on one promise: that every answer respects the permissions each user has in the source system, and that promise is only as good as the access control lists (ACLs) and identity mappings behind the index. Q Business connects to sources such as Amazon S3, Microsoft SharePoint and Salesforce, crawls documents with their ACLs, and can take actions in other applications through plugins. This guide covers the identity model, privileged roles, connector credentials and ACL sync, plugins, CloudTrail logging, guardrails and a hardening baseline for organisations already running Q Business. Coding use is covered separately in the Amazon Q Developer and Kiro Security Guide. Facts are from AWS documentation checked on 8 November 2026.
Status note: AWS states on its availability change page that Amazon Q Business is no longer open to new customers, that it will continue to provide bug fixes and security updates for existing customers, and that new feature requests will no longer be considered. AWS recommends migrating to Amazon Quick, starting with Bring Your Own Index (BYOI), which connects an existing Q Business index to Quick while the Q Business application keeps running in parallel. AWS gave no dates on that page when checked. The controls below matter during that transition, because the same index and ACLs may serve both products.
This is an independent guide from NHI Mgmt Group, based on AWS's public documentation as of November 2026. It is not sponsored or reviewed by AWS. Product features change, so confirm settings against AWS's current documentation.
Key takeaways
- Documents without ACLs are public. AWS states that documents crawled without ACLs are indexed as public to every user of the application. Check this before anything else.
- The User Store is a privileged system. Group and user mappings decide who sees what; AWS advises treating User Store changes as privileged operations with an approval process.
- Response source is a data control. Allowing the LLM to answer when enterprise data has no answer is on by default at creation; decide deliberately whether to restrict responses to enterprise data.
- Chat is not logged by default.
ChatandChatSyncare CloudTrail data events, which you must enable with advanced event selectors. - Each connector holds a credential. Data source credentials sit in AWS Secrets Manager; do not reuse secrets across data sources, and rotate them.
How identity and access work in Amazon Q Business
A Q Business application has an index filled by data source connectors, a retriever (the Q index, or an Amazon Kendra index), a web experience users chat in, optional plugins for actions, and chat controls (guardrails). Three identities meet in every answer:
| Identity | Where it lives | What it decides |
|---|---|---|
| End user | AWS IAM Identity Center (subscriptions assigned to users and groups), or IAM-based access | Who can sign in to the web experience and whose permissions filter results |
| Document principals | ACLs crawled from each source into the Q Business User Store: emails, local groups, federated groups such as Microsoft Entra ID groups for SharePoint | Which documents each user may see in answers |
| Service roles | IAM roles for the application, each data source and each plugin | What Q Business itself can read, write and decrypt in your AWS account |
Permissions-aware answers: AWS states that responses are based only on content the end user can access. That depends on the identity crawler mapping local source identities to the federated identity the user signs in with. AWS notes that if a user's attributes in the User Store do not match the IAM Identity Center user, API calls for that user are denied, and that a reused email address requires deleting the original user from the User Store. Joiner, mover and leaver processes therefore need to reach the User Store, not only IAM Identity Center. See the AWS IAM Identity Center Guide.
Anonymous applications: AWS documents anonymous applications for public-facing use without sign-in. Only index public content in them, and keep them in a separate application from anything internal.
Data use: AWS states that Q Business does not use customer data for service improvement or for improving underlying LLMs. Q Business is built on Amazon Bedrock and uses its safety controls. AWS requires TLS 1.2 and recommends TLS 1.3, offers FIPS endpoints, and asks customers not to put confidential data in tags or free-form name fields.
Admin roles and privileged access
The privileged roles in Q Business are AWS roles rather than in-app roles. AWS's best practice page asks for least privilege on application roles, regular audit of role permissions and strict control of RBAC permissions.
| Privileged capability | Why it matters | Control |
|---|---|---|
| Create or update applications, chat controls and web experiences | Can switch response sources, file uploads or orchestration for every user | Small admin group; IAM policies that limit update actions to that group; change approval |
| Create or update data sources | Can add a source with ACLs disabled, widen sync scope or change the IAM role | Restrict to data owners; alert on CreateDataSource and UpdateDataSource |
User Store and group operations (CreateUser, PutGroup, DeleteGroup) | Adding a user to a group grants document access | Treat as privileged with approval, as AWS advises |
| Plugin management | Plugins act in third-party systems | Restrict creation to the platform team |
| IAM Identity Center administration | Controls subscriptions and the identity source | Phishing-resistant MFA, separate admin permission set |
| Secrets Manager and KMS key policies | Expose connector credentials or decrypt index data | Resource policies naming only the Q Business roles |
AWS notes that once ACL and identity crawling are turned on they cannot be turned off, and that disabling ACLs at data source creation, where a connector allows it, requires specific IAM permissions. Deny that permission to everyone except a break-glass role. Service roles used for applications cannot be reused for data sources, which helps separation; keep one role per data source.
Integrations, API tokens and service accounts
Connector credentials and ACL sync
- Credentials: each data source authenticates with a secret in AWS Secrets Manager. For on-premises or server connectors, Q Business checks that the endpoint in the secret matches the configured endpoint, which AWS describes as protection against the confused deputy problem; changing the endpoint needs a new secret. AWS advises rotating credentials, granting only necessary access and not reusing secrets across data sources. The account behind the secret is a non-human identity that can usually read far more than any single user, so give it read-only access and an owner. See the Secrets Management Guide.
- ACL crawling: enabled by default, and changes are picked up on each crawl, so sync frequency is also access revocation latency. A user removed from a SharePoint group can still get answers from that content until the next sync.
- Sync schedule: on demand, hourly, daily, weekly, monthly or a cron expression. A new data source does not sync until someone selects Sync now.
- Deletion safeguard: the Sync scope threshold skips the delete phase if too large a share of documents would be deleted (0% means none are deleted, 100% means no protection). Set it to catch a misconfigured source wiping the index, but remember skipped deletes leave stale content searchable.
- Network: connectors can reach sources inside a VPC with a subnet, security groups and an IAM role permitted to manage elastic network interfaces; Q Business also supports interface VPC endpoints through AWS PrivateLink.
- Field mappings: map only the attributes you need; attributes are truncated at 2,048 characters.
Validating ACLs with ACL Analyzer
ACL Analyzer, on the data source's Troubleshooting tools tab, takes a Document ID and User ID and reports whether the user has access, every alias and group mapping for that user, and the document's allowlist. Use it routinely, not only for complaints: pick sensitive documents (board papers, HR cases) and test users who should not see them.
Plugins
Plugins connect Q Business to third-party applications so it can perform actions and query their data. Custom plugins are defined with an OpenAPI schema in JSON or YAML, uploaded to S3 or pasted in the console editor, with up to 20 API operations per plugin. Every plugin is a delegated path into another system: expose only the operations users need, prefer read operations, give write operations to small groups, and register the credential behind each plugin in your NHI inventory with an owner. The Orchestration global control lets Q Business route requests across plugins and data sources automatically; leave it off until plugins have been reviewed. See the OWASP LLM Top 10 LLM06 Excessive Agency Guide.
Indirect prompt injection
Any indexed document can carry instructions aimed at the model. With plugins that act, an injected document becomes a way to trigger actions as the user. Limit write-capable plugins, keep untrusted external content out of indexes used with action plugins, and test with planted documents before go-live. See the Prompt Injection Guide.
Logging and detection
| CloudTrail category | Default | Examples | Use |
|---|---|---|---|
| Management events | Logged | CreateApplication, UpdateApplication, CreateDataSource, UpdateDataSource, chat controls, web experience, index, plugin and retriever operations, TagResource | Configuration drift and privileged change alerts |
Data events on AWS::QBusiness::Application | Not logged; enable with advanced event selectors (charged) | Chat, ChatSync, ListConversations, PutFeedback, BatchPutDocument, CreateUser | Who asked, when and from where |
Data events on AWS::QBusiness::DataSource | Not logged | StartDataSourceSyncJob, StopDataSourceSyncJob | Unexpected sync stops that freeze stale ACLs |
Data events on AWS::QBusiness::Index | Not logged | PutGroup, DeleteGroup, BatchDeleteDocument | Group membership changes that grant access |
AWS's documentation shows the identity, time, source IP, user agent and request parameters in log entries; it does not state that chat content is captured, so do not rely on CloudTrail for conversation review. Deliver events to S3 through a trail, since event history only holds recent events. Alert on: data sources created or updated outside change windows; chat controls changes; PutGroup or CreateUser outside your provisioning automation; stopped sync jobs; and plugin creation.
Metrics:
- Percentage of indexed documents carrying ACLs (target 100% for internal sources).
- Maximum ACL sync interval per data source (your revocation latency).
- ACL Analyzer negative tests passed per quarter against sensitive documents.
- Number of data source secrets older than your rotation period.
- Number of write-capable plugin operations and the groups allowed to use them.
- Count of User Store changes made outside approved automation (target zero).
Hardening baseline
- Audit ACL coverage. For every data source, confirm ACL crawling and identity crawling are on and identify sources where documents lack ACLs. Fix permissions in the source system, then resync.
- Set global controls. Decide on response sources (enterprise data only for regulated content), disable file uploads if they are not needed, keep hallucination checks on, and enable Orchestration only after plugin review. Use topic-level controls scoped to users and groups for sensitive subjects.
- Tighten roles. One IAM role per data source and plugin, scoped to its secret and KMS key; deny ACL-disabling permissions; separate administrators of applications, data sources and the User Store.
- Rotate and isolate connector secrets. One secret per data source, read-only source accounts, rotation in Secrets Manager.
- Shorten sync intervals for sources with frequent permission changes, and set a deletion safeguard threshold.
- Enable data events for the application and index resource types and send them to your SIEM.
- Test before widening access. Pilot with one group, run ACL Analyzer negative tests and planted prompt injection documents, then expand subscriptions.
- Plan the migration. Before using BYOI with Amazon Quick, document which ACL and identity settings the index carries and re-run negative tests from the new product.
Rollback: chat controls and data source settings can be reverted in the console; a data source found to expose content can be removed or its sync stopped while permissions are fixed. ACL crawling cannot be turned off once enabled, which is a safety feature rather than a rollback path.
Small versus large deployments: a small deployment with one or two sources can rely on daily sync, a single admin group and monthly ACL Analyzer checks. A large one with many sources and federated groups needs the identity crawler, change-controlled User Store automation, data event logging and quarterly access testing.
Framework mapping
| Q Business control | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | Threat addressed (ATT&CK v20) |
|---|---|---|---|
| IAM Identity Center subscriptions, User Store governance | AC-2, IA-2 | PR.AA-01 | T1078.004 Cloud Accounts |
| ACL crawling, topic controls, least-privilege roles | AC-6 | PR.AA-05 | T1213 Data from Information Repositories |
| Connector secrets in Secrets Manager, rotation | IA-5 | PR.AA-01 | T1552 Unsecured Credentials |
| TLS, FIPS endpoints, VPC endpoints | SC-8, SC-28 | PR.DS-01 | T1530 Data from Cloud Storage |
| CloudTrail management and data events | AU-2, AU-6 | DE.CM-03 | T1567 Exfiltration Over Web Service |
Common misconfigurations
- Sources indexed without ACLs. AWS treats them as public, so every subscribed user can retrieve them through chat.
- Manual User Store edits. Recreating a group with the same name but different members, or reusing an email, silently changes who sees what.
- Infrequent syncs. Revoked access persists in answers until the next crawl.
- One over-privileged connector account. A shared domain admin or global reader secret reused across sources turns one leak into total exposure.
- Chat data events left off. When a data exposure is reported, there is no record of who asked what or when.
- Write plugins with broad audiences. Combined with indirect prompt injection, they let a document trigger actions.
Practitioner checklist
- Confirm ACL and identity crawling on every data source and fix documents without ACLs at source.
- Set the response source deliberately and review every global and topic-level control.
- Treat User Store and group changes as privileged, automated and approved.
- Use one read-only, rotated Secrets Manager secret per data source.
- Scope IAM roles per data source and plugin; deny ACL-disabling permissions.
- Limit plugins to required operations and keep Orchestration off until reviewed.
- Enable CloudTrail data events for application and index resources and alert on privileged changes.
- Run ACL Analyzer negative tests quarterly and before any Amazon Quick migration step.
Standards and references
- AWS: Amazon Q Business availability change
- AWS: Amazon Q Business data source connector concepts
- AWS: Admin controls and guardrails in Amazon Q Business
- AWS: Using ACL Analyzer in Amazon Q
- AWS: Logging Amazon Q Business API calls using CloudTrail
- AWS: Custom plugins for Amazon Q Business
- AWS: Amazon Q Business service improvement
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Amazon Q Developer and Kiro Security Guide · AWS IAM Identity Center Guide · RAG Security Guide · Secrets Management Guide