Use a customer-managed policy that allows only the Amazon Bedrock read operations the user or service needs. Scope it to the exact resources and conditions required, rather than granting general read access. That keeps visibility limited while reducing exposure of model configuration, usage data and associated content that read-only permissions may reveal.
Why a customer-managed policy is the safer least-privilege pattern for Amazon Bedrock
A managed policy such as AmazonBedrockReadOnly is broad by design, so it is usually a poor fit when you are trying to minimise what a principal can see. A customer-managed policy lets you define only the read actions actually needed, then narrow them with resource and condition scoping. That matters because even read access can expose model configuration, usage data, and content metadata that should not be broadly visible.
For AWS IAM design, this is the point where AWS IAM Policies and Roles Guide becomes the practical reference: the difference between managed, inline, identity-based, and resource-based policies is not academic when you are trying to reduce blast radius. The narrower the policy surface, the easier it is to reason about what the role can actually enumerate or inspect.
If the same principal only needs one Bedrock workflow, the right pattern is to grant only those read operations that support that workflow and nothing else. In practice, that often means a purpose-built customer-managed policy attached to a role, not a general-purpose read policy reused across teams or environments.
What least privilege should look like in AWS Bedrock access
Least privilege here is not simply “deny write.” It is “permit only the specific read paths the workload or user requires, and only against the intended scope.” That includes limiting access by resource where AWS supports it, and by conditions where the request context should matter, such as environment, source network, or principal attributes.
This is also where Privileged Access Management Guide is relevant, because read-only permissions still become privileged when they reveal sensitive operational detail or can be chained into broader access. A role that can inspect model inventories, usage patterns, or related configuration may not be able to change anything directly, but it can still materially expand an attacker’s or insider’s situational awareness.
The control objective is to keep read access specific enough that the policy is understandable and reviewable. If a role needs only a subset of Bedrock visibility, do not give it the whole read-only catalogue and assume the impact is harmless.
How to build and maintain the replacement policy
Start by identifying the exact actor, the exact Bedrock task, and the exact data surfaces that task requires. Then translate that into a customer-managed policy that grants only the necessary read actions, and verify whether each action really needs broad scope or can be narrowed further. If multiple teams use similar access, prefer separate policies over a shared general one.
That approach aligns with IAM and IGA Basics, because entitlement design and access review are part of the fix, not just policy syntax. Least privilege fails when teams copy a broad pattern into new roles without recertifying whether the original access still makes sense.
For cloud-specific entitlement trimming, Cloud PAM and CIEM Guide is the right companion reference. The practical goal is to right-size effective permissions, not merely to replace one policy name with another.
Risk and Threat Considerations
Broad read-only access is still exposure. In Bedrock-adjacent workflows, read permissions can reveal model inventory, configuration details, operational usage patterns, or content that helps an attacker map the environment or identify higher-value targets. If the same role is reused across environments, that exposure can become cross-environment visibility.
Failure mechanism: A generic read policy grants more resource visibility than the task requires, then gets reused on additional roles, scripts, or automation paths until the principal can enumerate sensitive Bedrock-related information at scale.
Impact: An insider or compromised principal gains unnecessary insight into model and usage data, increasing the chance of reconnaissance, data exposure, and later privilege escalation through adjacent AWS permissions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Bedrock read access should be limited to the minimum needed for the task. |
| AC-3 — Access Enforcement | A customer-managed policy enforces narrower resource and condition scoping than a broad managed policy. | |
| IA-5 — Authenticator Management | If Bedrock access is exposed through credentials or tokens, their lifecycle affects exposure. | |
| Recommendation — Restrict the role to only the Bedrock read permissions the use case requires. Enforce Bedrock access with narrowly scoped policy rules and conditions. Rotate and limit the credentials that can use the Bedrock access path. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Replacing a broad managed policy with a scoped customer policy is an access-control decision. |
| A.8.2 — Privileged access rights | Read-only cloud permissions can still be privileged when they reveal sensitive operational detail. | |
| A.8.5 — Secure authentication | The policy applies to authenticated principals whose access should be constrained. | |
| Recommendation — Define Bedrock access rules in a least-privilege policy. Review and minimise privileged Bedrock read permissions. Bind Bedrock access to authenticated principals with tightly scoped rights. | ||
Practitioner Guidance
What to verify: Confirm which Bedrock read operations the principal genuinely needs, then test the policy against that exact use case rather than against a generic “read-only” expectation. If the role works without a broader permission, remove it.
Common mistake: Treating a managed read-only policy as a safe default because it is not obviously destructive. In AWS, read access can still be too revealing to be considered low risk.
Decision rule: If the principal needs ongoing access, use a tightly scoped customer-managed policy; if access is temporary or high-risk, pair the policy with just-in-time elevation and periodic review.
Practitioner takeaway: Least privilege is achieved by shrinking what the principal can inspect, not just by preventing writes, so use a purpose-built customer-managed policy whenever the managed policy is broader than the actual Bedrock task.