Amazon Bedrock data security: what practitioners need to govern

At a glance

What this is: This is a Cyera report on securing data in Amazon Bedrock, with the key finding that GenAI governance depends on data visibility, classification, and compliance across a single API access layer.

Why it matters: It matters because IAM, NHI, and AI governance teams need to treat Bedrock as both an application platform and a data exposure surface, not just a model endpoint.

👉 Read Cyera's report on securing data in Amazon Bedrock

Context

Generative AI changes the security problem because the control point shifts from a fixed application stack to a fast-moving model access layer. In Amazon Bedrock environments, the issue is not simply who can call the API, but what data those calls can expose, move, or retain across downstream workflows.

That makes data security posture, entitlement scope, and auditability part of the same governance problem. For identity teams, Bedrock sits at the intersection of machine-to-machine access, sensitive data discovery, and policy enforcement across AI-enabled workloads.

Key questions

Q: How should security teams govern data exposure in Amazon Bedrock workflows?

A: Treat Bedrock as a governed data path, not just a model endpoint. Security teams should classify data before it enters the workflow, restrict the identities that can reach sensitive sources, and verify where outputs are stored or copied. The control objective is to keep regulated or confidential data from moving through AI pipelines without traceability.

Q: Why do AI application identities create risk in generative AI environments?

A: AI application identities often have broader data reach than the use case requires, especially when they connect storage, retrieval, and model access in one workflow. That overreach turns a useful integration into a wide exposure path if credentials persist after the project changes. The risk is really lifecycle scope, not the model itself.

Q: What breaks when sensitive data is not classified in GenAI pipelines?

A: Without classification, organisations cannot reliably decide what data is allowed into the model, what must be blocked, or what needs special handling after output. That creates compliance gaps and weakens incident response because teams cannot reconstruct what the AI system touched. Classification is the control that makes the rest of the governance stack enforceable.

Q: How do organisations know if Bedrock governance is actually working?

A: They should be able to show which identities can call Bedrock, which data classes they can access, where prompts and outputs are retained, and how often those permissions are reviewed. If those answers are unclear, governance is partial at best. Strong programmes can produce a current access map and an audit trail for the AI data path.

Technical breakdown

Amazon Bedrock as a shared model access layer

Amazon Bedrock provides access to multiple foundation models through one service interface, which simplifies application development but concentrates security decisions. In practice, this means the security boundary is no longer the model alone, but the permissions, data paths, and logging controls around the API call. Data can move into prompts, responses, retrieval layers, and downstream storage, so classification and access policy must follow the data rather than the model brand. The governance challenge is to understand which identities can reach Bedrock, what content they can submit, and where outputs are allowed to persist.

Practical implication: Map Bedrock access paths to data domains and restrict which identities can send sensitive content into the service.

Data visibility, classification, and compliance in GenAI

GenAI security fails when organisations cannot see the data entering or leaving the environment. Data security posture management focuses on discovering sensitive content, classifying it, and enforcing controls based on where it lives and how it moves. For Bedrock, this matters because model usage can blend regulated data, customer information, and internal knowledge in the same request flow. Without classification at ingestion and output review, teams cannot prove compliance or investigate misuse. The problem is less about the model itself and more about unmanaged data flow across AI-enabled systems.

Practical implication: Classify data before it reaches Bedrock and log output handling so compliance evidence exists after the fact.

NHI governance for AI-enabled workloads

Bedrock usage is governed through service identities, tokens, and other non-human identities that operate at machine speed. Those identities often outlive the exact use case they were created for, especially when teams wire AI services into broader cloud workflows. The security issue is not just credential exposure, but overly broad access that lets AI pipelines reach more data than they need. Effective governance requires aligning workload identity scope with the minimum data paths required for the application, then reviewing those paths as the application changes.

Practical implication: Limit Bedrock-connected service identities to the smallest set of data sources and permissions needed for the workload.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• Microsoft Azure OpenAI service breach — stolen Azure API keys used to bypass AI safety controls at scale.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Bedrock changes the governance problem from model access to data control. Once a single API can route many models, the real risk becomes uncontrolled exposure of sensitive data across prompt, retrieval, and response paths. That is why data visibility and entitlement control matter more than model selection alone. Practitioners should treat the AI access layer as a governed data plane, not a convenience feature.

Hidden data paths are the new blind spot in generative AI programmes. The security failure is not just whether a model can be reached, but whether sensitive content can be discovered, classified, and constrained before it enters the workflow. When teams cannot trace what data touched the model, they lose both compliance evidence and breach investigation depth. The implication is that AI governance must include data lineage, not just application approval.

Non-human identity scope is the control that determines whether Bedrock becomes an exposure amplifier. Service identities that connect AI applications to storage, retrieval, and downstream tools often accumulate permissions well beyond the task at hand. That access pattern turns a model integration into a broad data access path. The practical conclusion is that NHI governance for AI workloads must be reviewed as a lifecycle problem, not as a one-time integration choice.

Data security posture management is now a prerequisite for AI governance, not a downstream enhancement. Bedrock environments combine fast-moving applications with sensitive data at rest and in motion, which means teams need discovery, classification, and policy enforcement before they can claim control. This is where NIST CSF and zero trust thinking become operational, because the question is no longer trust in the model. The question is whether the surrounding identity and data controls can keep pace with the workflow.

Amazon Bedrock illustrates a named concept we call model-adjacent data exposure. The issue is that models may be secure as services while the data connected to them is not. That gap appears when identities, prompt content, and output storage are governed separately, even though they operate as one workflow. Practitioners should collapse those silos and evaluate the entire AI request path as a single security domain.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a broader view of how agentic control failures map to identity risk, see OWASP Agentic AI Top 10.

What this signals

Model-adjacent data exposure: the practical security boundary in Amazon Bedrock is the path data takes into and out of the service, not the foundation model itself. As teams add retrieval, memory, and downstream persistence, the number of identities and systems that can mishandle sensitive content grows quickly. Programmes that do not unify data discovery with identity scope will keep finding blind spots after deployment.

The industry is moving from model experimentation to operational governance, which means access reviews must cover service identities, storage paths, and output destinations as one workflow. That shift also raises the value of internal mappings such as the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs, because lifecycle scope is what determines whether an AI integration stays temporary or becomes permanent.

For teams aligning AI controls with external standards, zero trust and cybersecurity framework language are now directly relevant to AI data flow decisions. Use NIST Cybersecurity Framework 2.0 to anchor govern, identify, protect, and detect activities around Bedrock-connected workloads.

For practitioners

• Inventory every Bedrock-connected identity and data path List the service accounts, tokens, and workload identities that can invoke Bedrock, then trace which repositories, buckets, and knowledge sources they can reach. Remove permissions that are not required for the specific AI use case and document the data classes that are allowed to traverse the workflow.
• Classify sensitive data before prompt submission Apply discovery and classification controls at the point where data enters the generative AI workflow, not after the model returns output. This should cover regulated records, customer content, and internal knowledge bases so policy decisions can be enforced before the model processes the request.
• Bind output handling to compliance evidence Log where Bedrock outputs are stored, who can access them, and whether they are retained in downstream systems that expand the exposure surface. Make those logs usable for audit, incident review, and retention enforcement so AI output does not become an unmanaged copy of sensitive source data.
• Review AI workload access as a lifecycle process Re-certify the identities that support Bedrock on the same cadence as the application changes, especially when new data sources, retrieval layers, or model use cases are added. Offboard unused credentials promptly so temporary AI integrations do not become permanent access paths.

Key takeaways

• Amazon Bedrock concentrates generative AI security around data flow, identity scope, and auditability rather than around the model alone.
• The strongest evidence from the report is that AI governance fails when organisations cannot see, classify, and control the data moving through the workflow.
• Practitioners should review Bedrock-connected identities and data paths as a lifecycle problem so temporary AI integrations do not become standing exposure routes.

Key terms

• Generative AI data path: The generative AI data path is the full route sensitive information takes into, through, and out of an AI workflow. It includes prompts, retrieval layers, model responses, logs, and downstream storage, which means security teams must govern the entire path, not just the model endpoint.
• Model-adjacent data exposure: Model-adjacent data exposure happens when the model itself is not the primary weakness, but the surrounding data flow is. Sensitive content becomes exposed through connected identities, storage systems, and output handling, so the security problem sits in the workflow architecture rather than the model brand.
• Bedrock-connected service identity: A Bedrock-connected service identity is a non-human identity used by applications or workloads to invoke Amazon Bedrock and related cloud resources. Its permissions determine which data sources it can reach, which outputs it can store, and how much of the AI workflow it can influence.

Deepen your knowledge

Amazon Bedrock data governance and non-human identity scope are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for AI-enabled workloads, it is worth exploring.

This post draws on content published by Cyera: How Cyera Enhances Data Security for Amazon Bedrock. Read the original.