Mastering AWS Bedrock Security: Why Customer-Managed Keys Are Non-Negotiable

Overview

As enterprises adopt Generative AI, services like Amazon Bedrock have become central to innovation, particularly for Retrieval-Augmented Generation (RAG) workloads. When you create a Knowledge Base in Bedrock, it ingests your proprietary data from sources like S3, processes it, and makes it available for AI models. This process creates temporary, or "transient," copies of your data within the AWS infrastructure.

By default, AWS encrypts this transient data using keys that AWS owns and manages. While this provides a baseline level of security, it falls short of the stringent governance and control requirements of most enterprises. The critical best practice is to enforce the use of Customer-Managed Keys (CMKs) through the AWS Key Management Service (KMS).

Using CMKs shifts control of the encryption keys from the cloud provider to you, the customer. This enables granular access control, detailed audit trails, and the ability to revoke access to your data at any time, providing true data sovereignty over your most sensitive information used in AI applications.

Why It Matters for FinOps

From a FinOps perspective, robust security controls are a core component of managing cloud value and mitigating risk. Failing to use customer-managed keys for sensitive AI workloads introduces significant business and financial liabilities. Audit failures related to data handling can result in substantial regulatory fines, particularly under frameworks like PCI DSS or HIPAA.

Beyond direct financial penalties, non-compliance erodes customer trust. If you are building a SaaS product on Bedrock, your enterprise customers will demand proof of data isolation and control. The inability to demonstrate independent control over encryption keys can lead to lost contracts and a damaged reputation. This security posture isn’t just an IT concern; it’s a critical enabler for revenue and a key pillar of a responsible cloud financial management practice.

What Counts as “Idle” in This Article

For the purposes of this article, we define an "at-risk" or non-compliant configuration as any Amazon Bedrock Knowledge Base that relies on the default AWS-owned key for encrypting its transient data. While not "idle" in the traditional sense of an unused resource, this configuration represents a state of passive risk and inadequate governance.

A configuration is considered at-risk if the transient data encryption setting is left at its default. The primary signal of this risk is the absence of a customer-specified KMS key ARN in the Knowledge Base configuration. This indicates a missed opportunity to enforce least-privilege access, cryptographic erasure, and detailed auditing, leaving sensitive data protected by a key outside of your direct control.

Common Scenarios

Scenario 1

A healthcare technology company uses an Amazon Bedrock Knowledge Base to analyze anonymized patient records and clinical trial data. Because this data is subject to HIPAA, relying on default AWS-owned encryption keys is insufficient. The company must use a CMK to provide auditors with detailed logs of data access and to maintain the ability to cryptographically erase the data if required.

Scenario 2

A manufacturing firm ingests proprietary engineering schematics and trade secrets into a Knowledge Base to build an internal expert system. This intellectual property is the company’s most valuable asset. Using a CMK ensures that access to the transient data is strictly limited to the Bedrock service role, preventing even a compromised administrator account from accessing the underlying data without explicit KMS permissions.

Scenario 3

A B2B SaaS provider offers a multi-tenant AI-powered analytics platform built on Bedrock. To ensure cryptographic isolation between its clients, the provider uses CMKs. This allows them to prove to their customers that their data is handled with the highest level of security and that they retain ultimate control over its accessibility, fulfilling key enterprise compliance requirements.

Risks and Trade-offs

Opting for default AWS-owned keys over CMKs introduces several risks. The most significant is the loss of control and visibility. You cannot define granular access policies for an AWS-owned key, nor can you audit its usage with the same level of detail in CloudTrail. This creates a blind spot for security and compliance teams. Furthermore, you lose the ability to perform cryptographic erasure—the power to make data unrecoverable by revoking its key.

The primary trade-off for using CMKs is a minor increase in operational overhead. It requires creating and managing the key, defining its policy, and paying the nominal KMS usage fees. However, this minimal effort is insignificant compared to the immense security, compliance, and governance benefits gained by asserting sovereign control over your organization’s data.

Recommended Guardrails

To ensure consistent data protection, organizations should implement strong governance and guardrails around AI services. Start by establishing a clear policy that mandates the use of CMKs for any AWS Bedrock Knowledge Base that processes sensitive or regulated data.

Use AWS Identity and Access Management (IAM) policies or Service Control Policies (SCPs) to prevent the creation of Knowledge Bases that are not configured with a customer-managed KMS key. Implement a robust tagging strategy to classify data sensitivity, which can drive automated checks and alerts. Finally, integrate automated monitoring to detect non-compliant configurations and trigger remediation workflows, ensuring that your security posture remains strong as your use of AI scales.

Provider Notes

AWS

To implement this control in AWS, you will primarily use two services. Amazon Bedrock is the service for building with foundation models, and its Knowledge Base feature is where the configuration is applied. The encryption key itself is created and managed in AWS Key Management Service (KMS), which allows you to create and control CMKs. Every use of your CMK by Bedrock is logged in AWS CloudTrail, providing an immutable audit trail for compliance and forensic analysis. When configuring the KMS key policy, you must grant the specific Bedrock service role the necessary permissions to use the key for encryption and decryption.

Binadox Operational Playbook

Binadox Insight: Default encryption is a good starting point, but it is not a substitute for true data sovereignty. For enterprise-grade security and compliance in your GenAI workloads, customer-controlled keys are a non-negotiable requirement that places control firmly in your hands.

Binadox Checklist:

• Identify all Amazon Bedrock Knowledge Bases handling sensitive, proprietary, or regulated data.
• Create a dedicated Customer-Managed Key (CMK) in AWS KMS in the same region as your Bedrock resources.
• Define a restrictive key policy that grants usage permissions only to the specific Bedrock service role.
• Configure each Knowledge Base to use your newly created CMK for transient data encryption.
• Verify the configuration by syncing the data source and checking for corresponding KMS events in AWS CloudTrail logs.
• Enable automatic annual rotation for the CMK as a standard security best practice.

Binadox KPIs to Track:

• Percentage of production Bedrock Knowledge Bases configured with CMKs.
• Mean Time to Remediate (MTTR) for any newly detected non-compliant configurations.
• Number of KMS access denial events related to Bedrock, which could indicate misconfigurations.
• Audit pass/fail rate for controls related to customer-managed encryption.

Binadox Common Pitfalls:

• Assuming default AWS encryption is sufficient for all data classifications.
• Misconfiguring the KMS key policy, preventing the Bedrock service from accessing the key and causing ingestion failures.
• Neglecting to monitor CloudTrail logs, thereby missing important security events related to key usage.
• Failing to create separate CMKs for workloads with different security requirements or for isolating tenant data.
• Forgetting to implement preventative guardrails, leading to a continuous cycle of reactive clean-up.

Conclusion

As you integrate powerful AI capabilities using Amazon Bedrock, the security of your underlying data cannot be an afterthought. Shifting from default AWS-owned keys to Customer-Managed Keys is a critical step in hardening your security posture and ensuring you meet enterprise governance standards.

By taking proactive control of your encryption keys, you gain the visibility, auditability, and authority required to protect your most valuable digital assets. Review your current Bedrock configurations and establish guardrails to make customer-managed encryption the standard for all future GenAI deployments.