Amazon Bedrock is a serverless API layer for accessing foundation models without managing model hosting infrastructure. It gives AWS customers a managed entry point for inference, but it is not itself a model. The service is typically evaluated for security, latency, quota behavior, and how well it fits enterprise governance requirements.
Expanded Definition
Amazon Bedrock is a managed access layer for foundation models, so the security question is less about model hosting and more about how identities, prompts, data paths, and permissions are governed around the API. In NHI terms, it becomes part of the control plane that service accounts, agents, and automated workflows use to reach model capabilities.
That distinction matters because Bedrock does not eliminate the need to secure NHIs, secrets, or downstream tool access. It changes where the risk concentrates: API credentials, IAM policy scope, network boundaries, logging, and the trust placed in autonomous callers. Industry usage is still evolving, and definitions vary across vendors when they describe “managed model access” or “serverless AI.” For governance purposes, the operative question is whether the calling identity is constrained to the minimum model, region, and action set required. The NIST Cybersecurity Framework 2.0 provides a useful baseline for mapping these access controls to asset and privilege management.
The most common misapplication is treating Bedrock as if the platform boundary replaces identity controls, which occurs when teams grant broad API access to shared automation without isolating secrets or reviewable permissions.
Examples and Use Cases
Implementing Bedrock rigorously often introduces governance overhead, requiring organisations to weigh developer velocity against tighter identity scoping, auditability, and quota control.
- A customer support agent calls a foundation model through Bedrock using a dedicated service account with narrow permissions, rather than a shared account reused across environments.
- An internal retrieval workflow routes approved documents to the model, while blocking direct access to unrelated S3 buckets and production secrets.
- A security team reviews Bedrock access patterns alongside the risks described in the NHIMG AI LLM hijack breach analysis, because prompt injection and overbroad tool use often travel together.
- An enterprise aligns Bedrock usage with NIST Cybersecurity Framework 2.0 to formalise access reviews, logging, and response workflows for model-calling identities.
- A developer platform team separates test and production Bedrock credentials so experimentation cannot silently expand into customer-facing workloads.
These patterns work best when the calling NHI is treated as a governed workload identity, not as a convenience token attached to an application by default.
Why It Matters in NHI Security
Amazon Bedrock becomes a governance issue when NHIs are allowed to invoke powerful model capabilities with excessive privilege, weak segmentation, or poorly rotated secrets. That creates a path from ordinary automation to high-impact misuse, especially when an agent can chain model output into downstream actions. NHIMG research shows that 97% of NHIs carry excessive privileges, and only 5.7% of organisations have full visibility into their service accounts, conditions that make AI access harder to audit once Bedrock is added to the stack. The lesson is not that managed model access is unsafe by default, but that it magnifies pre-existing identity hygiene failures.
Practitioners should also assume that logging, prompt handling, and outbound tool permissions can become sensitive data paths in their own right. If the service account behind Bedrock is over-permissioned, any compromised integration can pivot into broader AWS resources or external systems. Strong governance therefore requires least privilege, secret isolation, scoped IAM policies, and continuous review of who can invoke which models and for what purpose. Organisations typically encounter the operational reality of Bedrock after an agent misfires, leaks data, or triggers an unauthorized action, at which point NHI control becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Bedrock access depends on the security of the non-human identity that invokes it. |
| OWASP Agentic AI Top 10 | A-02 | Agentic workflows using Bedrock must constrain tool use and authorization paths. |
| NIST CSF 2.0 | PR.AC-4 | Bedrock governance maps to access permission management and least privilege. |
| NIST AI RMF | AI risk management requires controlling access, transparency, and misuse around model use. | |
| NIST Zero Trust (SP 800-207) | Zero Trust applies by verifying every Bedrock caller and minimizing implicit trust. |
Scope Bedrock callers to least privilege and review every service account that can reach model APIs.
