Amazon Bedrock Security: Beyond the Service Boundary

When designing security controls for generative AI, it is common to focus on model training.

For Amazon Bedrock, the training risk is addressed by default. AWS does not use your prompts and responses to train foundation models, nor does it share them with third-party model providers. Your data remains in the AWS Region where the API call is processed.

However, this does not mean every data risk is removed.

Your application can still send sensitive data to the model. Your retrieval layer can still expose the wrong documents. Your logs can still store prompts and responses. Your IAM policies can still allow too much access.

The practical principle is simple:

1. Bedrock does not use prompts and responses to train models

Amazon Bedrock protects customer data privacy by separating base model storage from inference execution.

When an inference call is made, Bedrock routes the request to a transient, secure runtime context. Base model parameters are read-only during this execution. The model is not updated by the transaction, and the session payload is deleted immediately after the response is returned.

This means you do not need to build custom sanitization logic just to prevent your data from leaking into public model updates. AWS provides this separation at the service boundary.

2. Use PrivateLink for private network access

For production workloads, Bedrock should normally be accessed through VPC interface endpoints using AWS PrivateLink.

AWS supports private connectivity to Bedrock using interface VPC endpoints. This allows workloads in a VPC to access Bedrock without using an internet gateway, NAT gateway, VPN connection, or public IP address.

This should be the default pattern for confidential, regulated, or PII workloads.

3. IAM defines what the workload can invoke

Identity and Access Management (IAM) is the primary authorization control plane for model execution. Without explicit IAM policies, workloads cannot call Bedrock endpoints, invoke inference profiles, or perform cross-Region inference routing.

Cross-Region inference routing operates as a data-residency decision, sending calls from a source Region to a processing Region under geographic or global profiles. To implement least privilege, avoid wildcard policies like bedrock:* and restrict execution roles to specific model IDs and Regions.

• Restrict Model Invocations: List permitted foundation models explicitly instead of granting broad access.
• Govern Regional Routing: Use Service Control Policies (SCPs) and IAM condition keys like aws:RequestedRegion to prevent calls to unapproved Regions.
• Enforce Guardrail Paths: Restrict direct model access to force applications to route requests through approved inference profiles or guardrails.
• Separate Operational Roles: Maintain distinct IAM roles for development, administration, and runtime environments.

4. Logging must provide evidence without creating a new data risk

Security auditing requires logging API activity, but model invocation logging can inadvertently capture prompts and responses containing sensitive data. Capturing full inference payloads creates a high-risk data repository that must be protected with the same rigor as the primary database.

API metadata should always be captured using AWS CloudTrail. If full model invocation logging is enabled for operational or compliance audits, the log destinations must be encrypted using customer-managed KMS keys with restricted access.

• Audit API Activity: Enable CloudTrail to capture management events and API invocation metadata across active accounts.
• Isolate Payload Logs: If invocation logging is enabled, route the raw text payloads to dedicated, encrypted S3 buckets or CloudWatch log groups.
• Enforce Strict Access Controls: Restrict read permissions on log groups and apply lifecycle rules to automatically delete payloads.
• Monitor Anomalous Traffic: Track request volume, token consumption, and denied API calls to detect compromised credentials or misuse.

5. Protect data before, during, and after inference

Transport encryption secures data in transit, but customer-managed encryption keys (KMS) are used based on project risk assessments to secure static assets associated with Bedrock deployments. Protecting sensitive data requires a combination of encryption and client-side minimization before sending payloads to the service.

Data sent over cross-Region inference routes is encrypted in transit using TLS. At rest, customize encryption policies using KMS customer-managed keys for ingestion data, vector store collections, and prompt logs based on compliance requirements.

• Minimise Payload Exposure: Do not include passwords, API keys, or raw customer records in prompts.
• Tokenise or Mask PII: De-identify sensitive data using masking or tokenisation before invoking the API (refer to our guide on PII Tokenization and Redaction patterns for implementation patterns).
• Encrypt Static Assets: Use customer-managed KMS keys for associated S3 buckets, vector indexes, and data ingestion pipelines based on risk classification.
• Enforce Transit Security: Ensure TLS is enforced across all client endpoints and VPC interface endpoints.

6. Knowledge Bases require retrieval authorization

Amazon Bedrock Knowledge Bases enable Retrieval-Augmented Generation (RAG), allowing models to query internal vector indexes. This architecture introduces the risk of privilege escalation if a user receives answers derived from documents they are not authorized to view.

The vector database does not automatically inherit your application’s user permissions. Security teams must implement access control checks before documents are retrieved, ensuring that only metadata and context matching the active user’s permissions are fed into the prompt template.

• Classify Source Documents: Group documents by sensitivity and store them in separate knowledge bases or collections where access controls differ.
• Secure the Vector Index: Restrict OpenSearch Serverless collections or external vector database access to the Bedrock service role.
• Validate User Identity: Perform authorization checks in the application layer before calling the retrieval API.
• Filter Retrieved Context: Use metadata filtering to restrict the retrieval context to documents matching the user’s group memberships.

7. Guardrails help, but the application remains responsible

Bedrock Guardrails help detect or filter unsafe content, masking PII and filtering restricted topics at the model boundary. While guardrails provide useful runtime validation layers, they are not reliable security boundaries and cannot block all malicious inputs.

Attackers can still exploit application-level vulnerabilities or generate costs through rate-limit exhaustion. Developers must implement input validation, rate limiting, and loop protection within the application hosting code rather than relying entirely on model-level safeguards.

• Filter Content Inputs: Use Guardrails to detect prompt injection attempts, harmful language, and forbidden topics.
• Prevent Agent Loops: Implement maximum iteration limits in orchestrators to stop autonomous agents from entering infinite loop states.
• Enforce Rate Limits: Protect API limits and manage costs by rate limiting requests per user or application client.
• Review Output Safety: Configure Guardrails to mask sensitive matching patterns in the final response text before display.

8. Practical Bedrock security baseline

A secure Bedrock deployment should include the following baseline, designed in tandem with a broader, production-ready AI security checklist.

Key Lessons

• Service vs. Workload Boundary: Bedrock provides strong managed security features, but customer-side controls still matter.
• Resilience vs. Compliance: Cross-region inference improves availability, but it must be reviewed for data residency and compliance.
• VPC Limits: PrivateLink reduces network exposure, but it does not replace IAM or application controls.
• Design is King: Guardrails help enforce policy, but they are not a full security boundary.
• Data Context Risks: Knowledge Bases create new data exposure risks if retrieval is not properly authorized.
• Audit Footprint: Logging is essential for audit, but raw prompt and response logs can become a sensitive data store.

Summary: The Secure Deployment Model

The right security model is simple:

Control who can call the model. Minimize what data is sent. Know where inference runs. Govern what the model can return. Log enough evidence without creating unnecessary data risk.

References

• AWS Documentation: Data Protection in Amazon Bedrock
• AWS Documentation: Using AWS PrivateLink with Amazon Bedrock
• AWS Documentation: Cross-Region Inference in Amazon Bedrock
• AWS Documentation: Amazon Bedrock Guardrails
• AWS Documentation: Knowledge Bases for Amazon Bedrock
• AWS Documentation: Monitoring and Logging for Amazon Bedrock