Amazon Q for Business Security: CISO Guide 2026

Amazon Q for Business is now deployed across thousands of enterprise environments, indexing SharePoint repositories, Salesforce CRM records, Confluence wikis, and ServiceNow tickets into a unified AI assistant. The security model is fundamentally different from a standard SaaS application: the threat surface is defined by what you connect to it, how you map identities, and whether your Access Control Lists survive the synchronization from source system to index.

This guide covers the specific attack vectors that AWS documentation underemphasizes, including cross-user data leakage through ACL misconfiguration, prompt injection via indexed enterprise documents, Q Apps permission boundary gaps, and audit trail gaps that leave security teams with no visibility into what Q is telling employees. You will also find a 10-step hardening checklist based on real deployment patterns.

Amazon Q for Business Architecture: What CISOs Need to Understand

Amazon Q for Business is not a chatbot layered on top of a search index. It is a Retrieval-Augmented Generation (RAG) system that processes user queries, retrieves relevant document chunks from its index, and synthesizes responses using a large language model. The security implications of this architecture differ substantially from traditional enterprise search or a standard API-connected SaaS tool.

Three components define the security perimeter:

The index: Documents ingested from connected data sources. ACLs from the source system are crawled and stored alongside document content. The fidelity of this ACL copy is the primary determinant of whether cross-user data leakage occurs.

IAM Identity Center: The identity plane. Amazon Q resolves user queries against IAM Identity Center (IdC) user IDs. If the mapping between your Active Directory groups and IAM IdC groups is incorrect, a user may access documents in Q that they cannot access in SharePoint directly.

Q Apps: User-created lightweight applications built within the Q Business environment. Q Apps inherit permissions from the consuming user's session but are shareable across the organization, creating a risk that permission boundaries are not re-evaluated when an App is shared with users outside the original scope.

Amazon Q Business is architecturally distinct from Amazon Bedrock and Amazon Q Developer. CISOs who have reviewed AWS Bedrock enterprise security should not assume that coverage transfers to Q Business deployments. The data connector model, identity architecture, and RAG attack surface are entirely different.

Attack Surface Map: Data Connectors

Amazon Q Business supports more than 50 enterprise data connectors including Amazon S3, Microsoft SharePoint Online, Salesforce, Confluence, ServiceNow, Jira, Microsoft Exchange, Slack, Box, and GitHub Cloud. Each connector is a potential attack path.

Connector credential exposure: Credentials for each data source are stored in AWS Secrets Manager. IAM roles must be explicitly permitted to access specific secret IDs. If the IAM policy for a Q connector role is scoped too broadly (for example, secretsmanager:GetSecretValue on ), credential theft via privilege escalation in a related role grants access to every connected system simultaneously.

ACL synchronization failures: Connectors crawl ACLs on a schedule. If the crawl fails due to permission changes in the source system or network interruptions, Q's index retains the last-known ACL state. Documents removed from a user's access in SharePoint may remain accessible via Q until the next successful sync. There is no default alert when ACL synchronization fails.

Knowledge base poisoning via connected documents: Research published at USENIX Security 2025 (PoisonedRAG) demonstrated that an attacker with write access to any indexed document can inject malicious instructions into the corpus. Amazon Q retrieves these instructions and incorporates them into responses. In practice, an attacker with Confluence editor access can embed hidden prompt injection payloads that redirect Q's behavior for any user asking related questions. This is an indirect prompt injection attack that bypasses all query-level controls.

Cross-classification contamination: Organizations frequently connect data sources with different classification levels, for example a public S3 bucket alongside a confidential SharePoint document library. If document-level ACLs are not configured independently for each source, Q may surface confidential content in response to queries intended for the public-facing corpus. The default Q configuration does not enforce classification-based response segregation.

Connector IAM role over-scoping: A common misconfiguration is assigning connector roles s3:GetObject on all S3 buckets rather than the specific bucket used for the Q data source. This allows Q's connector role to be abused as a lateral movement path to unrelated S3 buckets if the role is compromised.

For organizations running AI security assessments, data connector configuration review is the highest-priority item in a Q Business engagement.

IAM Identity Center Configuration Hardening

IAM Identity Center is the required identity plane for Amazon Q Business. SCIM synchronizes users and groups from your enterprise directory to IdC. Misconfiguration here directly maps to unauthorized document access at query time.

User store audit cadence: Q resolves user identities against the IdC user store at query time. If a terminated employee's IdC account is not deprovisioned promptly, they retain Q access until deprovisioning occurs. Many organizations rely on IdC's SCIM auto-sync but do not monitor sync failures. A failed SCIM sync means terminations are not reflected in the user store, and recently offboarded employees may retain access to the full indexed corpus.

Cross-environment isolation: In multi-environment deployments (development, staging, production Q applications), IAM IdC organizations can span multiple AWS accounts. Verify that production Q applications are scoped to IAM IdC instances in the production AWS account only. Developer accounts with broader permissions should not share an IdC organization with production Q deployments.

Trusted Identity Propagation: AWS introduced Trusted Identity Propagation in 2024, allowing Q to propagate the user's identity token to downstream data sources for live authorization checks. Without it, Q uses a service role with broader access, and document-level filtering relies entirely on Q's internal ACL copy rather than a live authorization check against the source system. Trusted Identity Propagation is not enabled by default and requires per-connector configuration.

MFA enforcement: IAM Identity Center supports MFA enforcement for web experience login. CISOs should configure MFA via IdC policy rather than relying on the upstream identity provider's MFA enforcement alone. Policy-enforced MFA at the Q layer ensures coverage even when IdP configuration changes are made upstream.

Amazon Q Apps: Permission Inheritance and Data Exposure

Amazon Q Apps are user-created mini-applications built within a Q Business environment. A user can create a Q App that queries specific data sources and share it with colleagues. This creates permission boundary gaps that are not prominently documented.

Creator vs. consumer permissions: When a user shares a Q App, the App queries data sources using the consumer's own permissions, not the creator's. This is the correct security model. However, organizations that deployed Q Apps before the July 2024 IAM policy update may not have IAM policies that properly scope qapps: permissions. Post-update policy requirements for Q Apps include specific permissions for card-level data source specification and approval workflows. Review your current role policies against AWS Q Apps IAM documentation to identify gaps.

Approval workflow bypass: Q Apps support approval workflows for data source access. These are optional and not enabled by default. Without approval workflows, any shared Q App grants consumers access to the data sources configured in the App, subject only to their own ACL permissions. High-risk data sources (HR records, financial data, legal documents) should require approval workflows before App-level access is granted.

Q App data source scope: Post-July 2024, Q Apps support card-level data source specification, allowing an App creator to pin specific connectors to specific App cards. Default behavior scopes Apps to the entire application index. For Apps shared broadly within the organization, explicit data source scoping limits the blast radius of a misconfigured App.

Guardrails Configuration: Coverage and Gaps

Amazon Q Business provides two control tiers: global controls applied at the application level, and topic-level controls that restrict responses on specific subjects.

Effective global controls:

• Enterprise-data-only mode disables LLM fallback responses. Q will decline to answer if the indexed corpus contains no relevant document. This is the single highest-impact control for preventing hallucinated authoritative responses about internal policies.
• Hallucination mitigation evaluates RAG responses in real time and corrects detected hallucinations. When enabled, it increases response latency but reduces the risk of factually incorrect responses that appear authoritative.
• File upload restrictions control whether users can submit documents directly to the chat interface, limiting injection via direct upload.

Topic-level controls let administrators define subjects Q will not respond to, for example "pending litigation matters" or "unreleased product roadmaps." These controls affect response generation, not query submission. Users can still ask restricted questions; Q will decline to answer rather than refuse the query at input.

What guardrails do not cover:

Indirect prompt injection via indexed documents is the most significant gap. Guardrails evaluate Q's output and query handling; they do not evaluate the intent of retrieved document content. A malicious instruction embedded in a Confluence page passes through ACL filtering, retrieval, and response generation without triggering content filters.

Plugin workflows disable hallucination mitigation entirely. Organizations using Q Business with plugins (which enable agentic actions such as creating ServiceNow tickets or sending Slack messages) have no hallucination mitigation active for those workflows. This is documented in AWS documentation but not prominently flagged.

Amazon Bedrock Guardrails integration, announced June 2025, adds PII detection and content filtering across 60+ languages but requires separate configuration and adds measurable response latency. It does not address indirect prompt injection via RAG retrieval.

Auditing Q Conversations with CloudTrail and CloudWatch

CloudTrail captures all Amazon Q API calls: application creation, data source sync operations, user query submissions, and admin configuration changes. CloudTrail logs identify the IAM principal, request parameters, source IP, and response code for every Q API interaction.

CloudWatch conversation logs are required for query-level visibility. Amazon Q Business supports EVENT_LOGS delivery to CloudWatch, capturing user queries, Q responses, response feedback, and hallucination detection signals. This logging is disabled by default. Organizations that have not explicitly enabled EVENT_LOGS delivery have no audit record of what Q has told their employees. For regulated industries, the absence of conversation logs is a compliance gap regardless of other controls in place.

Configuration steps for conversation auditing:

Create a dedicated CloudWatch log group with a retention period matching your compliance requirements.

Enable EVENT_LOGS delivery in the Q Business application settings.

Apply CloudWatch log masking policies to redact PII (names, email addresses, account numbers) before log storage.

Configure CloudTrail alerts for anomalous patterns: bulk BatchDeleteDocument calls, GetApplication requests from unexpected IP ranges, or ListRetrievers calls outside normal business hours.

KMS key auditing: If you use customer-managed KMS keys, CloudTrail captures GenerateDataKey, Decrypt, and DescribeKey operations. Monitoring for unexpected key usage outside Q Business service endpoints can surface potential credential exfiltration attempts before they escalate.

Note: Amazon Q Business does not support asymmetric KMS keys. The Starter index tier does not support customer-managed keys at all. Deployments requiring customer-managed KMS must use Enterprise tier or Kendra-based retrievers.

Compliance Mapping: HIPAA, SOC 2, and Customer Responsibilities

Amazon Q Business is certified for HIPAA, SOC 1/2/3, PCI DSS, and ISO 42001. Certification means AWS's infrastructure controls have been third-party audited. It does not mean a deployment is automatically compliant.

HIPAA: Q Business is HIPAA-eligible but not HIPAA-compliant by default. Customer requirements include: executing a Business Associate Agreement (BAA) with AWS, configuring CloudWatch log masking for Protected Health Information, restricting data connectors to HIPAA-covered data stores, and maintaining audit logs per the HIPAA Audit and Accountability standard (45 CFR 164.312(b)). AWS explicitly states that customers are responsible for ensuring PHI is not entered into Q configuration fields (tags, application names, descriptions).

SOC 2: AWS provides third-party SOC 2 audit reports via AWS Artifact. Customer controls required for Trust Service Criteria include: access control configuration (IAM IdC MFA, least-privilege connector roles), change management (connector configuration tracked in version control), and incident response (documented playbook for Q hallucination and data leakage events).

EU AI Act: Amazon Q Business, deployed to support employee decisions such as HR policy queries or financial guidance, may qualify as a high-risk AI system under EU AI Act Annex III depending on the specific use case. Organizations in EU member states should conduct an AI Act risk classification before deploying Q Business for decision-support workflows. Article 13 transparency obligations require that users are informed they are interacting with an AI system.

The OWASP Top 10 for LLM Applications and the NIST AI Risk Management Framework both provide applicable control frameworks. OWASP LLM01 (Prompt Injection) and LLM06 (Sensitive Information Disclosure) map directly to the connector poisoning and ACL misconfiguration risks described in this guide.

CISO 10-Step Hardening Checklist

Enable enterprise-data-only mode before indexing production data. Disable LLM fallback responses from the start, not after an incident.

Deploy customer-managed KMS keys for all Q applications processing sensitive or regulated data. Use Enterprise tier or Kendra retriever for encryption eligibility.

Configure CloudWatch EVENT_LOGS delivery with PII masking policies before any users access the Q deployment. Absence of logs is a compliance gap, not just an operational gap.

Enforce MFA via IAM Identity Center policy for the Q Business web experience, independent of upstream IdP configuration.

Scope connector IAM roles to specific secret IDs in Secrets Manager. Deny secretsmanager:GetSecretValue on in all Q-related roles.

Run ACL Analyzer monthly for every data source connector, not just at initial deployment. Verify user store mappings match source system group membership, especially after directory changes or acquisitions.

Set connector credential rotation to 90 days or less in Secrets Manager rotation policies. Separate secrets per connector to limit blast radius of a single credential compromise.

Enable Q Apps approval workflows for any App that accesses confidential data sources. Review all existing Q Apps post-July 2024 to confirm IAM policies include updated qapps: permissions.

Conduct a prompt injection exercise against your Q Business deployment. Insert a hidden instruction into a test document in each of your top three connected data sources and verify whether the instruction surfaces in Q responses.

Document a hallucination incident response playbook: define detection criteria (employee reports a factually incorrect Q response used in a decision), escalation path, investigation steps, and communication process for decisions made on hallucinated content.

Conclusion

Amazon Q for Business changes the enterprise security calculus because the attack surface extends through the entire corpus of indexed enterprise data and the identity infrastructure controlling who can access it. ACL misconfiguration, connector credential exposure, and missing conversation audit logs are the issues most likely to surface in a real incident. The hardening steps above address the controls that AWS documentation treats as optional but that security teams should treat as baseline requirements.

If your organization has deployed or is planning to deploy Amazon Q for Business, book an AI security assessment or run a Securetom scan to review your connector configuration, IAM architecture, and guardrails setup before incidents occur. Our assessors have evaluated enterprise AI deployments across SharePoint, Salesforce, and ServiceNow connector configurations and identify ACL misconfiguration patterns that automated tooling consistently misses.