Overview
As organizations increasingly leverage generative AI, the security of session data within services like Amazon Bedrock has become a critical governance concern. Bedrock Agents, which execute multi-step tasks, maintain a session history or “memory” that can contain highly sensitive information, from proprietary business data to customer PII.
While AWS provides default encryption for data at rest, this baseline protection is often insufficient for enterprise-grade security and compliance. True data sovereignty requires a more proactive approach: using Customer-Managed Keys (CMKs) through AWS Key Management Service (KMS). This shifts control over the cryptographic keys—and therefore, the ultimate access to the data—from the service provider to your organization, creating a verifiable and auditable security posture.
This article explores the importance of enforcing the use of CMKs for Amazon Bedrock agent session data. It details the business and financial risks of relying on default settings and provides a high-level framework for implementing robust governance and guardrails for your AI workloads on AWS.
Why It Matters for FinOps
From a FinOps perspective, robust security is not just an IT issue; it is a fundamental aspect of financial risk management. Failing to properly secure sensitive AI session data can lead to direct and substantial financial consequences. The business impact extends far beyond a simple security incident.
A data breach resulting from inadequately controlled encryption keys can trigger enormous regulatory fines under frameworks like GDPR, HIPAA, or PCI-DSS. The cost of non-compliance often includes forensic audits, legal fees, and customer notification expenses. Furthermore, the reputational damage can lead to significant customer churn and a loss of market trust, impacting long-term revenue. Protecting intellectual property processed by AI agents is another key concern, as a leak could compromise competitive advantages. Therefore, the minor operational overhead of managing your own keys is a small price to pay to mitigate these potentially catastrophic financial risks.
What Counts as “Idle” in This Article
In the context of this article, we define an “idle” security posture as one that passively relies on default service settings rather than implementing active, customer-driven controls. A security control is considered idle when a more robust, auditable alternative is available but has not been configured.
Specifically, an Amazon Bedrock agent configuration is flagged as a risk if it uses the default AWS-managed key for encrypting session data. This default state leaves critical governance capabilities unused, such as granular access policies, independent auditing, and the ability to perform cryptographic erasure. The goal is to move from this passive, default stance to an active one where your organization owns and manages the lifecycle of the encryption keys that protect your most sensitive AI-driven data.
Common Scenarios
Scenario 1
An internal HR agent is designed to help employees with questions about payroll and health benefits. The agent’s session memory contains sensitive PII, including salary data and medical information. Using a CMK with a key policy restricted to the HR application’s service role ensures this data remains isolated and inaccessible, even to privileged cloud administrators.
Scenario 2
A customer-facing financial services agent provides personalized investment advice. To meet strict regulatory data protection standards, the firm must maintain an immutable audit trail of all data access. By using CMKs, every decryption event is logged in AWS CloudTrail, providing clear evidence of who accessed the data and when, which is crucial for compliance audits.
Scenario 3
A multi-tenant SaaS platform uses a Bedrock-powered feature for its corporate clients. To ensure strict data isolation between tenants, the provider uses a unique CMK for each customer. When a customer ends their subscription, the provider can delete their specific key, performing a “crypto-shred” of all their session data without impacting any other tenants on the platform.
Risks and Trade-offs
The primary risk of not using customer-managed keys is the lack of granular control, which can lead to data exposure or compliance failures. Without CMKs, you cannot perform cryptographic erasure (crypto-shredding), a critical capability for GDPR’s “Right to be Forgotten.” You also lose the ability to create fine-grained access policies, making it harder to enforce the Principle of Least Privilege for sensitive AI session data.
The main trade-off is a minor increase in operational complexity. Managing KMS keys and IAM policies requires careful configuration to avoid service disruptions. A misconfigured key policy could inadvertently lock the Bedrock agent out of its own session memory, causing application failures. However, this manageable operational task is a small price for the significant reduction in security and compliance risk.
Recommended Guardrails
To ensure consistent and scalable security for AI workloads, organizations should establish clear governance and automated guardrails.
Start by creating corporate policies that mandate the use of customer-managed keys for all production Bedrock agents handling sensitive data. Use AWS Service Control Policies (SCPs) to prevent the creation of new agents that are not configured with a specified KMS key.
Implement a strict tagging standard for all KMS keys to identify the data owner, application, and data sensitivity level. This simplifies auditing, cost allocation, and ownership. Furthermore, configure automated alerting using services like Amazon CloudWatch to detect any Bedrock agent configurations that fall out of compliance with your encryption standards, ensuring rapid remediation.
Provider Notes
AWS
In AWS, the primary service for managing cryptographic keys is the AWS Key Management Service (KMS). KMS allows you to create and control Customer-Managed Keys (CMKs), which provide you with full authority over the key’s lifecycle, including its creation, rotation, permissions, and deletion. This stands in contrast to AWS-managed keys, where AWS handles the key lifecycle on your behalf with less granular control.
When configuring an Amazon Bedrock agent, you can specify a CMK to encrypt its session data. This requires configuring an IAM policy for the agent’s service role, granting it explicit permissions to use the designated CMK for cryptographic operations. All key usage is logged in AWS CloudTrail, providing a detailed audit trail for security and compliance teams.
Binadox Operational Playbook
Binadox Insight: Relying on default AWS encryption is a passive security stance. True data sovereignty for AI workloads requires active governance through customer-managed keys, turning a potential liability into a verifiable, auditable asset.
Binadox Checklist:
- Audit all existing Amazon Bedrock agents to identify which are using default encryption.
- Establish a corporate policy for KMS key creation, rotation schedules, and ownership.
- Define and apply strict IAM policies that grant the Bedrock service role least-privilege access to the specified key.
- Implement automated monitoring and alerting for any agent configurations that violate the encryption policy.
- Enforce a tagging strategy for KMS keys to track ownership, cost center, and application context.
Binadox KPIs to Track:
- Percentage of production Bedrock agents using customer-managed keys.
- Mean-Time-To-Remediate (MTTR) for non-compliant agent configurations.
- Number of unauthorized key access attempts detected via CloudTrail alerts.
- Compliance score for AI workloads against internal encryption standards.
Binadox Common Pitfalls:
- Misconfiguring KMS key policies, which can lead to service outages for the Bedrock agent.
- Failing to implement and automate key rotation schedules, creating a potential security vulnerability.
- Forgetting to grant the Bedrock service role the necessary IAM permissions to use the key.
- Using a single, broad CMK for all applications, which violates the principle of least privilege and data isolation.
Conclusion
Moving from default service encryption to customer-managed keys is a critical step in maturing your cloud security posture for generative AI. It elevates your data protection strategy from a baseline offering to an enterprise-grade, auditable framework that you control.
By enforcing the use of customer-managed keys for Amazon Bedrock agents, organizations can effectively mitigate security risks, satisfy stringent compliance requirements, and build a foundation of trust for their AI-driven applications. This proactive governance is essential for protecting sensitive data and unlocking the full business value of AI on AWS.
7-day free trial